Confirmed: Too Many Open Source Projects Remain Arbitrary Mashups
Published: April 27, 2012 11:02
One benefit many developers perceive from working with a proprietary platform is that its components are generally updated and deployed according to a single agenda. (Sometimes that agenda is so slow that this fact becomes undeniable.) By contrast, the tremendous pace of open source development can be overwhelming for some. Back in 2007 the Open Source Census noted one big problem, especially among enterprises: Development teams have continually demonstrated an inability to manage the multitude of dependencies that OSS components have upon one another, and to use the proper or most secure components for their projects. A new Sonatype survey confirms that things haven't really changed that much since then.
Sonatype, producers of an open source repository manager called Nexus, surveyed some 2,550 information technology workers. Among those surveyed (52% software developers or engineers, 22% software architects, and 13% team leads or project managers), 52% say their organizations are standardizing on some form of open source development infrastructure stack - a 3% gain over last year's survey (which had about half as many participants).
Drilling down, however, only 20% of respondents say their organizations’ standards have evolved to the point where developers use only approved OSS components in their projects. The remainder either work with standards that aren’t actually enforced, or work in environments where developers choose whatever components they feel are best at the time.
The split last year was 13:87, indicating an improvement among at least 7% of respondents. But that uptick pales in comparison to the embrace of Twitter or of RESTful APIs.
So how are developers finding the components they use? Among the developers surveyed, some 74% pretty much type something into Google and see what pops up. Approximately 42% ask their colleagues for advice, knowing that they probably do a Google search, as well. About two-thirds read the websites for prospective components to help them make their decision, although - as Sonatype points out - such sites often don’t help developers iron out dependency issues.
“Open source has become the backbone of custom application development. Yet it brings with it a complex environment ecosystem with no notification infrastructure in place,” reads a statement from Sonatype CMO Charles Gold. “The compounding reality is that when issues do arise, the effects are viral when the fixes are not.”
Five years ago, OpenLogic released a free tool called Discovery, hoping that developers integrating OSS components would use it to inventory what’s installed in their systems. That tool helped compile the first comprehensive data about open source components in use and how they’re being managed. Since that time, with the almost total shift to cloud-based development, OpenLogic moved the tool into the cloud, deploying it as OpenLogic Exchange (OLEX).
Now Sonatype has picked up the mantle of surveying enterprises, offering a bit more insight into the structure of organizations that are responding. The larger the organization, the more likely it is to use a repository manager, with 75% of respondents from organizations with more than 500 employees saying they have installed such a device (whether or not they make good use of it).
But who makes sure these repositories are being used properly? According to Sonatype’s survey, perhaps it’s the wrong people: Only 28% of respondents say that application development managers are responsible for application development - just greater than one-fourth managing governance of OSS component deployment by the people who actually do the job. The remainder say governance may be handled by a vast array of other departments, as depicted in the chart above.
While Sonatype (as might be expected) states the survey reflects the desire for a tighter notification infrastructure, that’s the same message that the Open Census sent back in 2007. If it’s a desire, it’s not a strong enough one to produce the needed changes in behavior.