The old “open vs. proprietary” debate is over and open won. As IT infrastructure moves to the cloud, openness is not just a priority for source code but for standards and APIs as well. Almost every vendor in the IT market now wants to position its products as “open.” Vendors that don’t have an open source product instead emphasize having a product that uses “open standards” or has an “open API.”
“Openwashing” is a term derived from “greenwashing” to refer to dubious vendor claims about openness. Openwashing brings the old “open vs. proprietary” debate back into play – not as “which one is better” but as “which one is which?”
What does it mean to be open? And how can you tell if a product is really “open”?
Sponsor
Why does it matter?
Take NASA’s experience with Eucalyptus Systems as an example. NASA’s Chris Kemp told The Register that the space agency had concerns that Eucalyptus’s open source private cloud computing solution couldn’t scale to meet the agency’s needs. NASA engineers tried to contribute some new code to Eucalyptus to make it more scalable, but Eucalyptus rejected the contributions because they conflicted with code available in a closed source version it sold.
The source code that NASA was using was available, fulfilling at least one definition of the term “open source.” But it wasn’t open for contributions from outside and Eucalyptus served as a gatekeeper for the product. Eucalyptus didn’t mislead customers – it was upfront about the existence of its proprietary offerings – but by some standards its product wasn’t open. Eucalyptus has recently made moves towards being a more open company.
What is “Open”?
Openness can perhaps be best thought of as a scale rather than a binary state. Simon Phipps of the Open Standard Initiative (OSI) has suggested the creation of an Open Source Scorecard. Until such a thing exists, what can you do evaluate the openness of a product or solution?
Michael Coté of the analyst firm Red Monk says that in some cases openwashing is mere ignorance – a company’s decision makers don’t realize what really goes into making something truly open. In others, it’s a matter of opinion. There’s a lot of fine print involved, and not everyone agrees on what “open” is.
Gil Yehuda, the director of open source at Yahoo, says that a lot of companies are willing to release code but are reluctant to take contributions. “That’s not really what open source is all about, but it does accomplish something,” he says. Yehuda cites transparency, trust, motivation to write better code, and recognition for contributors as some of the benefits of such an arrangement.
But Yehuda says accepting contributions has its own benefits, such as “crowdsourcing bug-fixes, evolving the project in novel directions, and building real partnership with the community.”
The first step in evaluating the level of openness of a product or solution is determining your own requirements. You need to decide in what ways you need the product or solution to be open. Then, complete the following steps to determine in which ways a product or solution is open.
1. Check the License
Licensing is the classic open source issue. OSI maintains a large list of accepted open source licenses. If you’re considering purchasing open source software, you should check whether its license is included on OSI’s list. If it isn’t, then it probably doesn’t meet OSI’s Open Source Definition. You should determine why the product’s license doesn’t meet this definition and decide if that reason is important to you.
2. Evaluate the Community and Governance
Being “open” means more than just making source code available. It also means letting the community contribute to a project. In the case of open standards, it’s important that as many stakeholders as possible have a say in the decision-making process. In the case of software, contributions should be judged by the merit of the code, not by whether the contributor works for the right company.
Developer Mikeal Rogers, who works for CouchOne, suggests looking at how decisions are made for a project. Are decisions made in public on a mailing list? Who can participate? Is the decision making process open only to vendors or can individuals join? Are dues involved?
In an interview on the Sun web site Phipps said “meritocracy, transparency of process, and open access for everybody with the necessary skills to participate in a project” are the essential elements of good governance for open source projects. The same elements can also be applied to open standards governance.
Coté adds that roadmaps should be publicly available. “If you open source something, it really should mean more than the source: your community, if you’re lucky enough to have one, wants to know everything, including future directions.”
3. Beware “Open Core” Software
Open core software is proprietary software built on top of open source software. This often means there’s a free, open source (sometimes even with an OSI-approved license) version of a product available, but paid versions with proprietary features are a vendor’s primary product. Eucalyptus is a historical example, though its moving away from that approach.
“This can be just fine, or terrible – it all depends on the communities expectations and how useful the open source software is on its own,” says Coté.
However, Gartner analyst Brian Prentice writes that most of the advantages of open source software is lost when one upgrades to a paid edition of an open core solution. “You’re licensing a proprietary solution from an organization which builds it with free open source components,” he writes. “The direction that happens – either open-to-proprietary or proprietary-to-open – is meaningless to you.”
Again, it comes down to your own requirements. You’re best off considering open core products as proprietary products and making your decisions based on the same assumptions you would make about proprietary software unless you’re sure the open source versions will meet your needs.
4. Read the Terms of Service for “Open” APIs
APIs are increasingly important as organizations rely on cloud services and many vendors claim to have “open” APIs. What should you look for in a vendor API?
Consider who can use the API, what purposes it can be used for and whether data flows both ways. You need to make sure that you won’t be excluded from using the API and that your proposed uses for it aren’t prohibited. You also need to make sure that you can write data to the service through the API and retrieve data from it through the API. For an example of an API that’s free, but not necessarily open, check out our analysis of the Wolfram Alpha API.
Closing Thoughts
Yehuda says one of the best things about the open source community is that it that it’s quite resistant to deception. If that’s true, openwashing might not have a long shelf-life as a marketing tactic. But the debate over what is and isn’t open will probably never die. That’s why it’s important to have a clear idea of what openness means to your organization.
Photo by ollinger
0 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.