The Future Of Open Source
Sun purchasing by Oracle has worried many people about the future of Sun’s open source products, one of the most important stack of open source software in the world. This purchasing has promoted speculations about the future of open source software as a whole because Oracle, in spite of is an open source supporter too, for instance with ADF Faces, the core software owned by Oracle like Oracle DB and Bea products remain closed, including entry level products like Oracle Express.
Another source of concern about the future of open source is the failure of Sun in making money with an aggressive open source strategy. To add even more concerns, cloud computing trend is tightly aligned with the Software As Service business model, and this model usually is not open source friendly.
In a previous article, Rod Johnson, CEO of SpringSource, the company which holds the Spring based portfolio, claims that Oracle, in spite of Sun purchasing, is not going to rule the innovation of enterprise Java because most of this innovation have taken place outside Sun and driven by the open source community.
I don't know whether Oracle is going to keep on the recent good work of Sun in the open source space, may be the path will be a mixed strategy of "free" software as an entry to the non-free, non-open stuff of Oracle, because now Oracle has many options to do this: MySQL-OracleDB, GlassFish-WebLogic, Sun JVM-JRockit, NetBeans-JDeveloper etc.
In a comment to this article Jacob Jenkov makes public his concerns about the future of open source as a business, he claims two downsides of open source:
1) Doing business with open source is difficult and it shouldn’t because usually open source adds value and this added value is worth to pay something.
2) As most of the open source projects are not driven by profit, the barriers to publish anything are very low and compromise with the future cannot be enforced. This generates tons of options to do the same, hard to pick the tool which fits in your need and very much uncertainty in the (short) future.
First of all, nobody can say Jacob’s reflections are anti-open source, because as the author of Butterfly DI Container, he has supported the open source movement more than the average software developer. The same cannot be said to this article, because myself I am the author of an open source product with many hours and lines of code behind (ItsNat).
Is open source a viable business model?
SpringSource is in this path, Sun tried this path too, we cannot say Sun failed in making revenue from open source because there was not very much time to explore and exploit a new world of services based on MySQL, GlassFish and so on. May be without this terrible crisis Sun would be profitable soon again (StorageTek and MySQL recent acquisitions implied "obvious" losses)...
I think the future of open source as a business is dual licensing, a mix of a non-liberal license and a commercial license, dual licensing does not exclude other "peripheral" revenue models like consulting, training, support and book selling, but dual licensing is a return to the product as the focus, a return to a revenue model based on *affordable* licenses with all of the goodness of open source.
The objective of dual licensing is to align user revenues with commercial licensing. As an analogy dual licensing is similar to the model used by PayPal, PayPal is FREE for vendors, there is no maintenance fee, but when you make money PayPal receives a small fee, this model works, scales and benefits both sides.
The open source product should not be a simple excuse to other kind of business. There is no "ethic" problem (for me) for these "excuses", if they work... fine! The problem is they have problems to scale because "almost anyone" can acquire "for free" the expertise of an open source product including in-depth knowledge.
The solution should not be a return to closed source software, giving for free a cut down open source community version is actually a return to this model. Even worst, a Software As Service in the cloud is even more closed.
IMHO the problem is not the number of options of one concrete technology, because many options (for instance in web development) are redundant, very similar approach. The problem is the number of “supported” options, or options with a compromise with the future... The open source world would benefit of dual licensing improving quality, support and ensuring a long term future if the product is successful.
An example, JACE, JACE was a very popular product to code “in Java” but in C++ to avoid JNI, JACE has been useful to many developers when Java was too poor and native code was necessary. These days almost no one needs this kind product, in fact the last version of JACE is dated in 2003 and based on JVM 1.3 and the web site is down… But what if I need this kind of software? There are two options, try to use JACE if you can in a modern JVM (generics may be a problem) or buy JunC++ion the alternative closed source product.
Why am I using this example? Because I have an alternative to JACE and JunC++ion, is used internally in JNIEasy (yes a closed source product) to check the license in C++ code using Java APIs. It is very similar to JACE and JunC++ion but it uses the C++ “new” keyword to create “Java” objects in C++ (the new keyword makes more comfortable writing “Java” in C++ for a Java programmer) and Java arrays in C++ are more powerful sacrificing C++ templates.
I could publish this internal tool as open source, but when I think about the time needed to bring some decent to the public (polish some things, add more features, javadocs, web, tutorials, new releases, maintenance and so on) for free… then I change my mind. Paradoxically sometimes the fully free open source way may hurt the innovation. This is one reason why dual licensing can benefit open source.
What do you think?
What is the future of Open Source?
Is open source a viable business model?
Is dual licensing a viable business model?
How is going to affect the cloud computing to the software products and business?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)