Day 3 (Wednesday, March 22, 2006)
Keynote: Comparing Apache and Eclipse (Greg Stein)
Stein started his presentation with a quote by Jon Stevens (another Apache participant):
A license can ruin a perfectly good piece of software
As you can probably guess, Stein’s talk was on the effect of licensing pressures in the software industry. He started by defining the different levels of licensing as:
Commercial, or closed licensing is exactly what one would assume: a license in which a company protects its code by not making it available to anyone in the public. Microsoft and Oracle are examples of this type of licensing.
Source Available allows the source to be seen, but nothing can be done to it or with it. Microsoft Shared Source is a good example in which you must pay to see source code. Sun’s Community License is another example of a restricted license: one for which you do not have to pay to see the code, but you are not allowed to redistribute it either.
Copyleftlicencing is the set of licences that most of us are familiar with in our use of open-source software. GPL (GNU Public License), MPL (Mozilla Public License), and EPL (Eclipse Public License) are all copyleft license examples. GPL is probably the most well-known. Copyleft allows developers to access the source code, and make whatever changes they want, but are obliged to distribute these changes.
Non-copyleft licensing is the least restrictive of all the licensing types. Developers can do whatever they wish with the code, as long as they do not claim ownership of the code. The Apache license, and BSD license are examples of non-copyleft licensing.
In the open-source community, one of the ongoing debates is: which licensing is better: Copyleft or non-copyleft? In copyleft, developers must redistribute their changes; this means that users benefit by having all the most recent changes. In non-copyleft, the developers can do whatever they wish (as long as they do call the code their own), but the users may not get the latest changes which may cause them to avoid the software package.
Stein related the history of XFree86: Originally, XFree86 had the lowest level licensing applied to it. At one point, some changes were made to the license which moved it up the stack, making the license more restrictive. The result: Developers grabbed the source code from before the license change and created X.Org. X.Org has flourished since the split, whereas XFree86 has started to stagnate.
Other similar stories exist as well: Gnome was created in response to KDE (which eventually pushed Qt to loosen their license), OpenSSH was created in response to SSH, and Apache Geronimo was created to give developers an Apache-licensed, fully certified J2EE server to allow them to build J2EE products without worrying about licensing.
There is a lot of pressure to move licenses on software down this stack. One has only to look at the progression of products being used from the open-source community:
- 1980’s: all commercial products
- 1990’s: arrival of Perl, Linux becomes more visible, larger and more complete
- mid-1990’s: LAMP (Linux, Apache, MySQL and PHP/Perl/Python) becomes the de facto standard for web applications, as it gives access to anyone to put their presence online
- late 1990’s: KDE, Gnome
- late 2000: OpenOffice goes live, free replacement for MS Office suite of products
So, in effect, there is already more free software appearing each year. Businesses cannot fight the open-source community: they cannot compete with the size, nor the cost. Eventually, every product can, and most likely will, be replaced by a free alternative.
One issue that does need to be addressed is the complexity of current software systems. They are not getting less complicated, and can wind up requiring several dozen (if not hundreds of) different components that all need to work together.
Stein strongly feels (and I happen to agree with him) that:
- packaged products are going away,
- all software will be free; configuration, customization, installation and integration will drive the market,
- open-source solutions will win, and
- this is going to happen in the 5-10 years.
So, with the doom and gloom stated above for those of us employed by companies who create software for other companies, and who are trying to come up with the “next killer app”, what do we need to do to win?
To win, we must track the licensing pressure trend. Most everything is moving down the licensing stack, not up it. The only real exceptions are content-heavy software (many current games), and service-based software will tend to remain at the top of the stack longer.
We must all realize that a community outlives the individual. A community exists because of communication between its members. The communication fosters respect between peers, which in turn promotes innovation and co-operation. These are the forces which drive the open-source community to continue to give us free replacements to software for which we have paid for years. If we are able to manage the community, then we will see the benefits from it.
The Apache Software Foundation is hoping to be an example of a reproducable model: six years ago, there were only 2 projects – HTTPServer and JServ. Now, there are more than 30 active projects under the ASF umbrella.
Eclipse has looked at and followed the Apache model. The community is what has been driving the project, and so far has been very successful.
By watching the commoditization trend as well as licensing pressures, we will be able to continue to be a viable company within the software industry.
Long Talk: Your Action is My Command
Long Talk: Java Annotation Processing (APT) in the Eclipse JDT
(Gary Horen, Jess Garms, Walter Harley)
Keynote: Software Development Creativity the Wiki Way (Ward Cunningham)
Long Talk: Common Navigator Framework for Platform/UI in 3.2
Panel: Best Practices for Developing Eclipse RCP Applications
(Ed Burnette, Boris Pruessmann,
- Extending Eclipse TPTP using the Generic Recorder