Editor's Note: The following is a guest post by Jason van Zyl. van Zyl is the founder of the Apache Maven project, the Plexus IoC framework and the Apache Velocity project and helped establish Codehaus, a well-respected incubation facility for open-source community projects. He currently serves on the board of the Eclipse Foundation and is CTO of Sonatype.
Jason can be reached on Twitter @jvanzyl
It's no secret that today's software is very different than it used to be. It's often cloud-based, includes social functions, and is available to anyone, anywhere, using any type of device. What most of us don't see is that it's not just different on the surface – it's also created and delivered in a very different way.
Today's software applications are largely built by assembling software components, most of which are open source and come from outside the organization building the final application. More than 80 percent of a typical Java application is now assembled from publicly available open-source components and frameworks. This is a dramatic departure from the past, when software was coded, line-by-line, by engineers working inside an organization. This new process for software creation allows developers to move much more quickly, deliver continuously, and only write code from scratch when absolutely necessary. For businesses, this means faster time-to-market and lower costs.
We saw just how popular collaborative, open-source development has become with the historic $100 million investment by Andreessen-Horowitz in GitHub, the code sharing and social networking site for programmers. GitHub, and other repositories like it, democratize open-source development, help young projects grow, and have fostered a vibrant, collaborative, and decentralized community that produces new software at an unprecedented rate.
So GitHub helps software producers, the developers who create components. But what about the consumers of those components – the end-user developers and organizations that build their applications using open-source components? Once code is complete and ready for mass adoption, project teams distribute their finished products via the Central Repository – a free, openly available, cloud-based repository where developers distribute their software to millions of users globally. The Central Repository has rapidly become the go-to source for open source components and today it serves more than 7.5 billion requests per year to 60,000 organizations and is home to more than 400,000 components. Sonatype (my company) operates the Central Repository for the community, building products and information services to help software developers make better use the components they're consuming.
Why software is like a car, and what does that mean to you?
Today's software is assembled rapidly, but it has a very complex "supply chain" like that of a car manufacturer. Like a car, the final product (an application) may contain hundreds or thousands of externally sourced components from dozens or hundreds of original suppliers. Each of these components has its own lifecycle, its own bug-fixes and feature enhancements, and its own potential risks.
Like a car, a single flawed component could cause significant problems for the user. In the worst case, these problems could lead to security breaches, data leaks, stability and performance issues, or legal actions related to intellectual property.
That's right, believe it or not, most of the applications you use on a daily basis, and most of the applications that are the foundation of your business operations, are built using components that could put your organization at risk.
An easy example of a potential problem is in the area of security. Recent analysis by Aspect Security, using data from the Central Repository, uncovered widespread security vulnerabilities among the most commonly used open-source components.
The unfortunate irony about component defects is that even when they're fixed, most organizations are unaware that they have a potential problem or that a fix is available. Because the components in any given application can originate from so many different projects, and new versions are released many times a year, it's very hard for the end user to keep up.
How can all this be avoided?
Components need to be "managed" just like any other enterprise asset. They need to be analyzed, monitored and evaluated to ensure that only the highest quality, least risky components are powering your application. Today this can be achieved, and achieved easily, through Component Lifecycle Management (CLM) an approach which helps developers choose, use and monitor the components that have become the backbone of their apps.
CLM sheds much needed light on the process of component usage by helping developers choose the best components from the beginning, keep tabs on them as they flow through the development process, and become aware of new versions, bug fixes, or security defects.
Properly managing the use of open-source components throughout the software development lifecycle lets you and your organization focus on building and delivering the best applications possible, with components that are robust, safe and up-to-date. All this leads to peace of mind and more innovation. And, that's why it matters more than ever to you, today.
No hay comentarios:
Publicar un comentario