In the last decade or so, Open Source software (besides SaaS) has caused a major upheaval in the world of software, both consumer and enterprise. The main attraction of open source software has been the fact that it provides a choice for organizations free themselves from the clasp of the proprietary software vendors and the control they exert in terms of expensive support contracts. Community based and third party support from organizations has also played a major part in the wider adoption of open source software.

Although the essence of Open Source was to make software available for FREE, each software offering does come with a license. As with any free, open standards process, the flavors of Open Source software licenses are aplenty. Before adoption a Open Source offering and benefit from the value delivered  to their organization, it is critical that companies pay close attention and rationalize the nuances of the type of license that governs it. Pay special attention to the fact that each open source technology might itself be an amalgamation of other open source technologies that come with their own licenses.

Given that they are easily available and free and not requiring you to go through a corporate procurement/budget process does not mean companies can start using them willy-nilly. A well-defined governance process is essential for companies to effectively manage the legal and operational risks they could run into down the road.

As part of working with a startup that built software heavily based on open source, I came up with process (which is still being refined). Depending on what stage you are as a company, a brand new startup or a large global organization, you might want to start with different activity in this process, to quickly get a handle on the process.

Inventory

If you are an organization, that is already using some (or many) open source software in your company, and until now, have not had a defined process, the first thing to do is to get a exhaustive inventory of all the open source technologies that are being used.

As part of compiling the inventory, make it specific to the version of the software. There have been many instances where open source license terms have changed between versions of the software. So it is important to capture that.

Once you have a comprehensive inventory created, classify or tag them with the following factors

• license type (Mozilla, BSD, Apache, GPL2…etc)
• License Agreement language (link or downloaded format)
• # usage – number of projects/products using them in the company
• Form of usage (reference or derivations made)
• packaging & distribution – bundled into the product or referenced as a separate pre-requisite
• platforms – (J2EE, PHP, Ruby-on-Rails, .NET)
• Internal Sponsor/lead (identify one, if the decision was made-by-committee or the lead is no longer with the organization)

Approval Policies

Implement an approval process at the outset for approving the decision to adopt any new open source software. In fact, as part of instituting the process, I would strongly recommend, conducting an quick approval process for software already being used as a means to vet the effectiveness of the policy. This gives you a good understanding of what, if any, corrective actions need to be taken to mitigate risks, for software already in use.

An effective approval policy must include roles for all the constituents that will be impacted by adoption of the open source technology. Legal, IT operations, support, engineering, marketing should all have varying degrees of involvement in the approval.

The approval processes should include approvals from

• Legal – for the specific language in the license agreement. This should take into consideration the pattern of usage – reference v creating derivative work, bundling vs soft pre-requisite. If you are selling your product that includes Open Source software, then reviewing your liability clauses to ensure you are covered might also be required.
• IT Operations – in terms of certification for interoperability with remaining technology infrastructure, scalability, security.
• Support – in terms of capability to support your customers while your product, including the open source software being used. This might also mean that you have upgrade to a enterprise support license from your hitherto used community license of the open source software.
• Intellectual Property – clearance in terms of keeping ownership of your intellectual property. Remember, in the event of any M&A your IP will come under scrutiny so a stitch-in-time saves nine. (Startups need to pay special attention to this).

Provisioning

Once the adoption of a open source technology has been approved (legally and operationally), it is important that provisioning is done through proper channels. Much as people hate going through IT for technology provisioning, this one might come back to bite.  Provisioning should involve

• IT certifying the product you plan to use is certified with your current IT infrastructure
• Certification should also be done in other areas like support for security holes, performance/scalability.
• Clear definition of download/uptake process for patches and software. Better yet, have a internal download site for approved patches that are also certified.

Tracking and Governance

In addition to the pre-approval and provisioning, a continuous oversight is necessary in terms of usage of the technology. During the time of usage of the open source technology any of the following could happen

• With the changing technology landscape, companies getting acquired or going bankrupt, you might have inherited risks that you thought you were clear off.
• A motivated developer, seeing new features in the newer version might have upgraded the open source version and built that fancy feature you are planning for the next release.
• Since it is already an approved product, a new project inside the company might start using it and you might not know about it.
• A project using open source technology gets shelved resulting in non-usage of the open source software you

Managing the inventory of the Open Source software being used through some form of Asset Tracking is critical. This will provide a  good platform for period audits against the Terms of Use of each of those software products along with approved projects/users.

In all these acquisitions, all the focus and noise by press, bloggers have been on the wretched intent of proprietary vendors in acquiring open source projects. “Oracle is acquiring Sun to kill MySQL” – being the classic. As much as I am not a proprietary software person and a self-professed open source evangelist, makes me wonder about those open source companies and their intent.

Open Source represented this sense of anti-establishment, which made people sacrifice their personal time and energy to join the community and contribute to something larger than anything they could have done by themselves. But with increasing number of open source project owners seeking to cash out by selling the project to a commercial vendor I can see things getting a little crazy as we go forward.

1. People who spend a lot of time on open source projects to contribute only to see the project owner cashing out might have second thoughts spending more time.
2. With each of these acquisitions, invariably, we see multiple forks of the open source projects getting spawned. This will just prove to be a distraction to progress of the software. Not to mention the headaches the consumer of that software now has to deal with.

If you look at the open source landscape, there are two key equally opposite trends at play here.

Commercial vendors going Open Source

On the one hand we see increasing number of commercial projects going open source. Let us check some vendors have open sourced their products

• Open Solaris by Sun
• Java from Sun
• Ingres from CA
• OpenFlex from Adobe
• Foxpro from Microsoft (you may question if this noteworthy?)

Open Source vendors getting acquired by Proprietary vendors

Let us look at some of the open source project acquired by proprietary vendors

• Gluecode by IBM
• XenSource by Citrix
• JBoss by Red Hat
• Berkeley DB by Oracle
• MySQL by Sun and now by Oracle
• SuSe linux IP by Microsoft

Look below the hood and you will see two key drivers here

1. All the commercial companies that are open sourcing their products are mostly products that have reached a stage where they are not the dominant force and their existence is in question. Yes, this includes Java. Much as I like Java it has not helped its own cause with the complexity. The balancing of the interests of Sun and other constituents of JCP has not helped either. PHP, Python, Ruby on Rails, CakePHP, Force.com, Google AppEngine and .NET all gaining traction at the expense of java. If you look at the large software vendors – only IBM and Oracle are behind java and IBM is making up its mind to be a full-fledged software company.
2. Companies that have failed in the market not able to support their product with resource and financial commitment, decide to open source it. Ingres is a classic example. It seems nothing but a last ditch attempt to hold onto a product nobody wants and get some marketing mileage.

Now if you look at the open source projects being acquired by commercial vendors they are done by large vendors who are trying to either

1. stop the advances of a vibrant open source project encroaching their customer base.
2. trying to replace their own lousy product with a better open source project.

For example: Oracle after long trying to create its own version of mobile/light weight database without success acquired Berkeley DB. In the process it got a much better product and eliminated the distraction to the team creating the  “Dreamliner” Oracle 10g or 11g.

Going back to my question of what is the real (hidden) business model behind these Open Source companies.

At the outset I am not a big fan of the Open Source business model (while  I continue to love those products). Majority of the open source companies usually play a bait-and-switch game.  They put out a free community edition and then once they hook the customer, charge for the real product – the “enterprise version”. The balance between the two flavors is always in question.

As a company spending the R&D dollars to build a product, there is no way you can support your business by giving away the source code – especially in these times of commodity support (Think Rimini Street supporting SAP). And consider VCs putting money behind a open source company where the only source of revenue is service and the code is open. Does it really work? If you look at the companies that have chosen this route, very few would be counted amongst the companies doing very well, right about now.

Alternatively, if you are going Open Source from the get go, all you are telling me is that you are not willing to put money where your mouth is. You are banking on community as a substitute for a paid R&D organization. Or resorting to cheap gimmick of making a “Going Open Source” announcement.

So given the trend of community owners milking the goodwill of people and eventually cashing out continues, there will be serious questions asked of the open source projects.  If you go by Dana Blankenhorn’s explanation of how to acquire Open Source, we might see expansion of GPL or the other flavors of Open Source license to include the ownership of copyright to the community and not to the individual who might have just started it.

A final thought: I am sure, as you go through the post, I might sound a tad bit against open source movement. I want to clarify, I am not against the open source movement itself. It has great virtues like reducing overall cost of ownership, better interoperability and better quality of code thanks to the community governing itself. I personally use a lot of open source software – Ubuntu, MySQL, WordPress, Drupal. I love all of them. They are better than anything else their proprietary counterparts have to offer. But the general open source business model itself seems to be flawed.