It's hard to imagine a company these days that isn't using open source software somewhere, whether it's Linux running a company's print and web servers, the Firefox browser on user desktops, or the Android operating system on mobile devices.
In, fact, there are now more than a million different open source projects, according to Black Duck Software, a maker of open source management tools and owner of the Ohloh open source software directory. And open source continues to grow. According to an SAP research report, the number of open source projects roughly doubles every 14 months.
But not all open source projects are created equal. According to Ohloh, for the 100,375 projects for which activity information is available, around 80 percent were listed as having low activity, very low activity or were completely inactive.
That's bad news for companies that bet big on those particular open source projects by using them as part of critical business systems. And that’s pretty much everybody, according to Gartner, which predicts that open source software will be included in mission-critical software portfolios in 99% of Global 2000 enterprises by 2016.
Picking a dead-end project means few or no updates and security patches, and little community support.
+ ALSO ON NETWORK WORLD 25 free open source projects IT pros will love +
And the impact of choosing the wrong open source project extends beyond development. For example, open source code is released under a wide variety of different licenses, some of which may not be compatible with a particular company's plans. Other challenges of unmanaged open source software include possible security risks and audit compliance problems.
Holes in the procurement process
Developers and end users often install open source software because it's free, because it offers the features they need, and because it's easy – no procurement process to follow. As a result, many companies aren't even aware of how much open source software is used by their employees.
Some open source vendors even use this as a sales technique. “We can go around the regular software decision process because open source can go directly to the individuals, and once there's a critical mass, it becomes a de facto standard that becomes adopted by the organization,” says Jean-Luc Solans, chief strategy officer at Bonitasoft, a Paris-based open source business process management software company. “What I've heard often from our customers, often times the CTO will tell me, 'I was not really looking to work with you, but you came in through the window.'”
But what end users and individual developers look for in software isn't always in line with long-term company needs.
According to a 2013 Sonatype survey of over 3,500 respondents on the front lines of IT, 60 percent of developers don't see security as a top priority, mostly because they don't have the resources or because they think it's someone else's responsibility.
Meanwhile, a study by software management vendor White Source found that 23 percent of software projects with open source components had security vulnerabilities – and 85 percent used outdated open source libraries.
In addition, vendor support is a major issue for large enterprises using open source for important functions, since community support can sometimes be problematic. But, according to Black Duck, 45 percent of developers and other IT professionals look at technical capabilities and features when choosing software, while only 12 percent consider commercial vendor support as the most important decision criteria.
An individual user or developer also might not consider whether other parts of the company have chosen a different, incompatible tool, whether it comes with workable license terms, and whether it can scale up if necessary. Finally, if the tool is written in a language that only that one developer is familiar with, and nobody else at the company can work in, then it will cause problems if that developer ever leaves.
Missing management
According to Sonatype, 57 percent of organizations today have no policies about open source usage.
A good open source management policy needs to provide guidance for developers and end users about when and where open source software is acceptable, what licenses to look for, and when management involvement is required.
If the software involved is important enough to go through a formal selection process, choosing open source has a lot in common with choosing proprietary software.
“When we look at picking a larger-scale platform -- lets say the open source phone system – we use the same product selection process as with proprietary software,” says Red Hat CIO Lee Congdon. “Total cost of ownership, features, functions, development roadmap, stability of the vendor, suitability of purpose – same things you'd look for as when evaluating proprietary solutions.”
The two major differences are that open source vendors are different from traditional commercial vendors and open source software selection also requires looking at the community surrounding the project.
This doesn't mean that corporate management has to get involved in every single software decision, says Congdon.
“If you try to over-control and don't allow flowers to bloom in your organization, you would likely stifle innovation or create shadow IT,” he says. “For our business, we tend to default to freedom and flexibility for the individual developer, but the needs of the project and the project engagement with our architecture team will probably drive a standard approach when we need it.”
It's all about the community
The success or failure of any particular open source project depends strongly on the community surrounding it – the developers who contribute code, the testers, the documentation writers, the people who answer questions in support forums, and the end users.
There are a number of ways to gauge the size and activity level of an open source project's community. Ohloh offers one tool. Another approach is to go to the project's home page or the site where it's hosted and check out the history of code commits and the activity on the discussion boards.
“If the project happens to be on GitHub, you can go and look at the activity on the projects,” says Tim Clem, GitHub’s head of business development and strategy. “On jquery, for example, there's a list of open bugs and feature requests and then there's usually quite a bit of conversation around the merits of the change. If the last issue was opened six months ago and nobody responded, there's a good chance that the community isn't very active.”
GitHub, which offers hosting for both private and open-source software projects, uses open source software internally, as well. And when it comes to a project that is core to the company's success – like the Git version control technology – GitHub actually hired some of its core developers. Not only does this give GitHub a great deal of insight into that particular open source project, but “we also get to steer the direction of Git,” says Clem.
Another approach is to contact open source developers directly.
“We've had good luck reaching out to main developers and asking questions,” says Michael LaVista, CEO and founder of web application development firm Caxy. “It's a good sign of a positive open source project if you email someone, and the developer gets back to you in a day. If they never answer, it's a sign that it's not active.”
Having a large number of developers on board is also key, he adds. “If some kid in Germany wrote a content management system in a language that nobody understands -- well if that kid goes away, so does the project.”
I have had some bad experience in the past with open source, where there wasn't a big enough community, and it made things very painful.
— Ross Nunamaker, manager of emarketing strategy and analytics for the Olympus Medical Systems Group
“I have had some bad experience in the past with open source, where there wasn't a big enough community, and it made things very painful,” says Ross Nunamaker, manager of emarketing strategy and analytics for the Olympus Medical Systems Group, a medical device manufacturer in Center Valley, Pa.
The group was looking to update a website that dated back to 1999 and was plagued by navigational dead ends, multiple owners, and other problems. After first considering a proprietary platform, the group eventually decided on Drupal, an open source content management system popular with large enterprises.
“The community around Drupal is growing like crazy,” says Nunamaker. That includes low-cost or free training classes around the region, and a large number of vendors who can work on the platform. But it was the other Drupal users who really sealed the deal.
“The Dot-Gov initiative especially,” he says. “I still had people with the feeling of 'Oh, open source is free so it has to be cheap,' or 'How can it be secure if you have so many people looking at it?' The White House using it makes a strong case for these people. And this year, when we launched, Pfizer and Johnson & Johnson also launched on the Drupal platform. A lot of companies are now moving off of their older platforms in this space to newer ones, and the fact that two bigger ones that went into the same direction, that's another nice one to have.”
And vendor support
Like many other popular open source projects, Drupal also has a single, dominant vendor at its helm, namely Acquia.
Nunamaker says that his group chose a different company to actually build the site, but drew on Acquia to confirm that their vendor was following a best-practices approach. It was also a comfort to know that a large vendor was available 24-7 in case of emergencies, he says.
According to W3Techs, Drupal has a 5.4 percent share of the content management space, putting it third after Wordpress with 60 percent and Joomla with 8.8 percent. However, BuiltWith.com, which focuses on just the million largest sites, puts Drupal in second place at 14.5 percent – a sign that Drupal is more popular with larger deployments.
“Joomla by design, for better or for worse, doesn't have a leading commercial agency that helps drive development,” says Paul Orwig, president of the non-profit Open Source Matters, which provides organizational and legal support to the Joomla project. “Joomla has a community of volunteers around the world -- we love that community -- but it takes away from the confidence level of ongoing commercial support.”
Another example of major open source platforms that have leading vendors is Linux, where in addition to Red Hat, SUSE Linux and Ubuntu's Canonical spearhead their respective distributions.
SUSE, for example, doesn't just provide support for its flavor of Linux. The SUSE Linux Enterprise Server comes with about 2,000 other open source software packages adapted to work with SUSE and supported by the company.
+ ALSO ON NETWORK WORLD 16 of the weirdest places to find Linux +
When selecting which tools to include, SUSE is, in effect, making software decisions on behalf of its customers.
Matthias Eckermann, senior product manager for SUSE Linux Enterprise, says he looks at three main factors when picking projects. “First, is the package we are supporting and giving to customers active, live, and well-maintained?” he says. “The second thing is, is it built with security in mind? Third, is it practical to use, is the documentation good, and is there a common sense outside of SUSE that this is a good tool?”
SUSE has an advantage in selecting projects, he says, because as an open source company itself, it is deeply embedded in the open source community.
For example, along with Red Hat, SUSE employees were active in creating the LibreOffice productivity suite after it branched off from OpenOffice. “Our developers are part of several communities,” he says.
The fine print
One of the thornier issues when selecting open source is choosing the right license. This is where the legal or compliance folks need to step in, because end users and developers might not always be aware of the restrictions surrounding a particular open source project.
Some software, for example, is licensed only for non-commercial use. Many packages are distributed under a license that requires all derivative works to be open source as well. Sometimes, there's no clear license at all.
“There are a lot of open source projects out there that are lifestyle hobby projects, a whole raft of those out there,” says Shaun Connolly, vice president corporate strategy at Hortonworks, which provides support for Hadoop. “And there may or may not be a focused effort on what license they chose.”
This is a significant issue for Woburn, Mass., payment vendor LoopPay. “We want to make sure we can use an open source project in a product environment, that we're not bound by licenses that disallow us from reselling the product or redeploying it somewhere else,” says David Meyer, the company's vice president of software engineering.
The most important thing, he says, is that the person making the final decision has a good technical foundation and has experts to rely on for making a decision, instead of relying on a single developer's recommendation.
“I commonly have junior, less-experienced engineers who find an open source project and they're really excited about wanting to use it, but it's one of those one-man projects that hasn't been active in two years,” he says. “If you buy into that excitement, you bring that open source project in, and you find out that your entire product is dependent on this one component that nobody is maintaining. You might have a legacy project that is doomed to failure until you take that open source piece out.”
Korolov is a freelance writer. She can be reached at maria@tromblyinternational.com.