With few changes to your company's existing software procurement policies, your business can access the myriad of open source software offerings with no more risk than using any other kind of software.
The benefits of open source software are very well known, so this article won't waste your time explaining why you should bother. Rather, let's assume you or someone in your organization is ready to deploy a worthy software application (which happens to be open source). The question then becomes: What policies should be in place to properly deploy and manage open source software?
Begin by mitigating the operational risks of using open source software. According to Greg Olson, senior director of open source software management with strategic consulting firm Olliance Group, licensing is not the biggest challenge of dealing with open source software. Most IT departments need to pay attention to how the software is developed so they can establish a comfortable relationship with the developers of the software.
That's because, even though licenses for open source software are indeed different, end users don’t usually have to be concerned about license compliance. Most open source and free software licenses are aimed at managing how the source code for software is distributed, not how it is used. If your company is just using the software, or modifying it for the company’s own use, then many compliance issues are simply non-existent.
Instead of worry about distribution licenses, Olson believes it's the operational aspects of software use that must be monitored. "You have to think of open source as outsourcing software, just as you might outsource staff," Olson explained. "If it's not properly monitored and evaluated, you can run into problems." Whenever you acquire open source software, evaluate it and test it like any other software to ensure it is appropriate for use in your organization.
Creating an open source policy, therefore, must include elements from any of your organization’s other software policies: evaluation guidelines, vendor relations, code testing, and security requirements. These are very important, because knowing what code is being used in your organization is always paramount for operational and security requirements, whether the software is open or proprietary.
Olson's comments were echoed by Paula Hunter, executive director of the Outercurve Foundation, a non-profit that manages open source projects within the Microsoft Windows ecosystem Hunter sees code provenance as one of the biggest priorities an organization must pin down.
"Most IT shops already have open source software in their environments," Hunter explained. "That's why it's critical to know your own code, see what you may have already in your company. Then you can evaluate the code properly."
It's also important to know your vendor. Again, this is standard software procurement, but in open source, a "vendor" may mean an actual commercial vendor that works with an open source product (such as Red Hat, Canonical, or SugarCRM) or a community of distributed developers (such as Apache Hadoop or Drupal). Most end users know how to deal with actual vendors; but it might be a bit daunting to work with a community for support, training, and so on.
This is where a new operational wrinkle can be found with open source software. No matter who made the software, end users will want to know who developed the code, how to get updates (and how often), and who can provide help when something might go wrong.
Olson recommended tools like Koders and Ohloh to research the general health of a given open source project. This is hardly unexpected, since these sites are managed by Black Duck Software, Olliance's parent company. Still, checking with tools of this nature is more important than ever, since open source development, which once could mostly be found on huge sites like SourceForge, is now scattered across dozens of forges and repositories, and thus is much harder to find.
Olson also recommended that you evaluate software with the National Vulnerability Database to make sure the most secure versions of any software are being used.
Naturally, the evaluation and procurement process needs to be adjusted based on the application’s use and criticality. An internal application that performs simple functions needs far less oversight and support than a customer-facing, mission-critical application. The latter, Olson said, definitely needs some sort of service level agreement (SLA) support in place with a commercial vendor, a third-party aggregate support vendor, or a consultant (perhaps one of the software's key contributors).
If using open source software sounds a lot like using proprietary software, that's because it is. Software must be evaluated for its capabilities and the levels of support that can be provided, just like any other piece of code. But it is here that one of open source's hidden benefits lies.
"With commercial software, you will deal with one vendor or a licensed consultant and that's it," Olson said as an aside. "With open source, you've got a whole range of support possibilities, including self-support, if you want."
One of those possibilities, Hunter added, would be working with a non-profit foundation—another unique open source feature. Companies, particularly internal lawyers, are quite comfortable working with commercial vendors, but are less sanguine about working with communities. A neutral foundation, said Hunter, can act as go-between with which many organizations would be more familiar.
Both Olson and Hunter agree that licensing is a low priority — at least, no more so than license compliance for any other type of software. If the end user does not distribute the code, compliance is relatively simple. Where things get interesting is if distribution comes into play, or the company’s own developers contribute back to the software project.
If any contribution occurs (which is good for your karma and leads to faster improvements in the overall application), then you must have rules for community engagement somewhere in your policies. "This is an absolute requirement," Olson emphasized.
Community engagement guidelines can range from not participating in any open source project to full-on sponsorship and management of the project in question, which some companies who rely heavily on a particular application may do. In between lies a range of options that your organization may want to use, such as participation only through a commercial intermediary, participation from personal accounts only with no organizational attribution, or full organizational participation. When contributions happen, they can be varied as well. Your company can contribute bug fixes back to the open source project in question, or it can get more involved: provide documentation, introduce new functionality, or create a completely new project based on internal work.
That is a lot of choices to make up front, but it is critical that you define the company’s planned level of participation. Somewhere in those rules of engagement should be a broad corporate statement on expectations. Is the software to be used as a tactical tool, or a strategic value-add? How the use is planned is a major factor in how the organization as a whole will approach working with open source vendors and communities; otherwise you may run into confusion and missteps in your dealings with the vendor or community behind the project, which nobody wants.
Hunter concurred with this advice, emphasizing that a broader approach to code contribution is better for most end users. With some caveats, however.
"There are cases where companies have to be very careful on what and how they contribute back," Hunter explained. "These companies will have to have a more rigorous review of what gets contributed." Examples of such end users would be companies like Amazon, eBay, or AOL, where technology is not their product per se, but is definitely the platform upon which their product is delivered.
While Olson and Hunter have many similarities in their approaches, there are important differences as well. Olson and his colleagues at the Olliance Group are very keen on creating a process-driven set of policies that leave little room for error. Hunter and the Outercurve Foundation take a more adaptive approach.
"Policy doesn't need to be onerous," Hunter explained. "As long as you focus on three main areas: licensing, code provenance, and contributing code."
When Olson works with clients to implement policies, there is usually a moment when all of the policy discussion pays off.
"It's when they realize that open source is just software like they've been dealing with for so many years," Olson said. "It's only the details that are different. That's the Aha! moment."
See also:
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
