Open Source
From Codtech
Open Source also know as FOSS, FLOSS or Free/Libre Open Source Software to put in evidence one common confusion that occurs when using the English language where free means no money (free as in beer) or liberty (free as in freedom).
Open Source Is Not a Trend, It's a Paradigm Shift
Contents |
Is Open Source a fad (passing frenzy) ?
What makes free and open source software more than a fad (passing frenzy)?
The notion of free software is nothing new - in fact, it's how software was originally distributed. In the earliest days of computing, you usually got the source code for the operating system at the time you purchased the mainframe.
At that time, of course, there were very few computers - most of which were for use at large companies, government agencies, and universities - so users often shared programs and source code. Since free software has been around for over 40 years, it can hardly be called a fad.
The origins of the Unix operating system, in the late 60's, were also Open Source (see timeline.
Unix were developed by AT&T and distributed to government and academic institutions, including all source code except for the machine-dependent kernel, becoming a synonym of "open system".
The Open Source model
But, what is the actual Open Source model ?
Internet and its pervasiveness have chenged the original model, now almost everybody is only a click away of any Open Source program converting it into a global phenomenon.
Most people like to showcase their accomplishments and share their knowledge (look at the blog phenomenon), and because the development of a piece of software that's useful and well written is something to be proud of, people usually share it. Then, when someone else sees the value of the pet project, he or she is likely to not only use it, but also share improvements that can benefit the original author and the additional contributor.
Clearly, it's a more efficient practice than commercial models. Red Hat, Novell and Oracle for example, fund development of the Linux kernel by paying some developer's salaries.
IBM contributes to the Apache foundation as well as other Open Source projects.
They each focus on adding value in other areas as well, like testing and other quality assurance measures, efficient delivery of a commercial version operating system, and technical support.
The smart ISVs know that innovation comes from the end user.
Is there an Open Source business model ?
Choosing the right business model for an open source company is paramount for success.
Even the largest and most well-known Open Source companies such as Red Hat and MySQL are still atrying to discover the best Open Source business model.
Yes, they have millions of users, and sales in the many millions of dollars. But they face constant threats to their business. What's to prevent another large entity from deciding that since Red Hat's code is open source, it can provide the same services as Red Hat?
Nothing.
And that's was demonstrated in last weeks (October 2006) when Oracle erased Red Hat's trademarks from Unbreakable Linux and now supports it for less than Red Hat was a bolt from the blue. The threat is always there.
What's the guarantee that as MySQL gains even more free users that this will translate into profits?
While there is no doubt that open source is a disruptive force to commercial software companies, open source companies themselves are susceptible to being "disrupted" as others can just take advantage of their openness.
So what business model enables an open source company to achieve this balance?
To start with, I don't believe that the business model behind the Linux operating system or Apache is readily replicable. You cannot just build an open source project, hope it will gain a huge critical mass and expect that users willing to pay magically arrives to your web site and buy your services. This happens once in a lifetime. And perhaps PXES Universal Linux Thin Client project was one exception, being in the right place at the right time.
It's even more difficult to find investors.
For an Open Source company to thrive and succeed, it needs a sustainable model that build a huge community fitst, and then be able to obtain the benefits from its huge community.
Choose the right business model
Open source companies can choose from many different business models and have many different ways to generate income, including charging for:
- Technical support
- Software functionality over and above what's in the open source project
- Training, consulting, professional (implementation) and other services
- Licenses for embedded software (such as DBMSs)
- Media distribution and documentation
- Hardware and appliances
- Legal indemnification, trademark licensing and other types of legal protection
The two predominant commercial open source business models are selling support and a dual license approach of offering a free open source and a commercial version of one's software.
I've always seen the selling support alternative quite contradictory. If ideally, the software tends to the perfection, your support sales tend to zero.
Nevertheless, this model will reward you more your fault than your hits (en espanol es aciertos). You get paid to solve problems you've alredy introduced but nobody pays for all of the good parts.
This is even more evident when the Open Source software is lower in the chain and when it is further from the end user. If the application is complex, like a database engine or an application server your chances of selling support are high, but what if you are developing a WiFi driver or a music player ?
A major balancing act with dual licensing consists of where to draw the line between free and commercial functionality. A guiding principle for our company has always been to "just be honest" with our community. It is based on the concept that if someone changes the code in the project and uses the project with the "public," they need to give the code back to the community or pay so that the money can be plowed back into the project.
Putting this theory into practice, however, requires constant decisions about major new features.
Investors and salespeople want to "close source" important features to make it easier to sell the commercial version, while the community wants everything to be open. This creates tension in the community ("why did you put THAT feature in the commercial version? We need it! We'll build it ourselves").
Further, if you put too much in the open source version, customers will ask why they should pay for software; if you don't put enough in the open source version, you risk alienating the community as they might decide to work on more innovative projects or fork the project.
So, dual licensing with commercial extensions naturally creates tension between the open source and the commercial audiences that manifests in the product roadmap. In the long run, it's not clear that having commercial extensions is a sustainable strategy for many companies (what happens when the software reaches a state of maturity where it is good enough for most users' needs?). Some open source companies have acknowledged this and have switched to a 100% services-based model.
