Day 3: Stein: "In 5-10 years, most of the software you use will be free"

(Greg Stein, chairman of the Apache Software Foundation, currently with Google, delivered this keynote on Wednesday morning at EclipseCon 2006. It was titled "Comparing Apache and Eclipse". -Ed)

 

Jon Stevens is quoted as saying:

"A license can ruin a perfectly good piece of software"

One of the first license types was the proprietary, closed license. Typical producers included Microsoft, Oracle, and IBM. Today as the web grows, back-end software is following the same pattern: for example, Google, Yahoo, MSN, SalesForce.com. You aren't free to see the software.

In the next less restrictive level, source is available but restricted. For example, Microsoft Shared Source - you can pay to see the source but can't do anything with it. Some community source licenses are a little more open, you don't have to pay but aren't allowed to redistribute (e.g., Sun community source license).

Copyleft

GNU Public License (GPL), Mozilla Public License (MPL), and even the Eclipse Public License (EPL) are examples of copyleft licenses. The most popular is GPL. Even in the Open Source world many people don't understand what restrictions licenses put on people. The GPL is really about: I'm going to give you a bunch of rights to the software, and if you make changes you have to give the next person the same rights. It's a mechanism to ensure everybody has full access, the right to modify, use, and redistribute it. This grew out of a philosophy: take your computer, every piece of software on there, I should be able to see it and do what I want. But most of the stuff in there now I can't see. GPL was conceived to open up the software in proprietary licenses.

MPL and EPL are a weaker version of this. You have to give your changes back, but if you combine with something else then you don't have to give people the source to the parts you combined with. GPL says if you combine it at all you have to give source to everything, that's why it's considered viral because it grows out to the entire package.

Non-copyleft

This is the weakest form, with less restrictions on you, for example, the Apache license, and BSD. The basic philosophy is do what you want, just don't call it your own. Combine with other things, make modifications, whatever. Debate: Which is more free, copyleft vs. non-copyleft, which is more free? Copyleft has restrictions on developer but users have the freedoms. On non-copyleft, developers have freedom, but users don't necessarily have those freedoms. It's freedoms for developer vs. freedoms for the end user.

Licensing pressure

Over time there's a pressure to move licenses on software down this stack. From commercial, to source available (restricted) to copyleft to non-copyleft. One of the reasons is that as you go down the stack there's more freedom. Developers want to take these more free licenses, extend, and provide more functionality to users.

MS does a great job with MSDN with these huge apps, but if you want to change you're out of luck. If you move to something like Linux or GNU libraries and you need to open the cover it's possible. As a development community that's what we want to see.

Examples of pressure

Gnome was created in response to KDE (Qt). Pole wanted to extend Qt and build on it so they built their own. Trolltech eventually loosened the Qt license.

X.org was created in response to XFree86. A minor license change made XFree86 less flexible (back up the stack). XFree86 had always been one of the most free, but change made people cranky so they forked it. Now X.org is growing and XFree86 is getting left behind.

OpenSSH was created in response to SSH. SSH had been developed by a corporation that changed licenses from GPL to proprietary. People wanted those changes, and security fixes they didn't have in the free one. So they took the free one, forked it, and now created OpenSSH.

Apache Geronimo. There was a desire for an apache licensed fully certified J2EE server so developers could build J2EE products without worrying about licensing.

The Growing stack

80's, all commercial.
90's, Perl came out, Linux. Linux started growing in visibility, became larger and more complete.
Mid 90's: Python, PHP, MySQL, Apache (LAMP). At that point people were able to put together all these different people to make interesting applications on the web.
Late 90's: KDE, GNOME, Zope, etc.
Late 2000: OpenOffice goes live. Essentially a full office replacement.
Each of these are an example where the stack is moving down that licensing regimen,

You can look at this as commoditizing software. You don't have to pay for it, it's abundant, and easy to use. There's less money available for people who sell packaged products. How much is a customer willing to pay for that additional functionality? Eventually a free software will overtake you. There are more OSS developers than you can bring to bear in a corporate environment. OSS community always has more and more going so it can overtake you. Your value-add starts being minimized. Depth and breadth are increasing. OSS systems are up to applications, with good tool variety and function.

One of the things about software is complexity. It's growing more and more complex. When you install an application system there may be hundreds of components installed. It's a huge management task to keep this functioning properly. Versioning and dependencies are a problem. Has the interop been maintained between versions? And so forth. It's not getting easier.

As our systems grow more complex, more assistance is necessary. This is a key direction of our business today. A lot of today's organizations are paid to assist in installs, configuration, packaging, testing, etc.. Basic components are free and help is charged.

Example of software assistance. I started with Slackware in 1994, compiled everything. Switched to RedHat in 96, simplified installation. Subscribed to RH Network in 2004 for simplified maintenance. Now all those dependencies are managed. Auto-security updates. Bug fixes are mailed to me. Etc.. This is all about service. I've got my box but there's so much stuff I need services to help.

How does all this impact your business? Over time you're not going to see people paying for software anymore. All your software will be free. Customization, install, config, and maintenance will require expenditures. I predict that in 5-10 years most of the software you use will be free.

So how do you win? The main thing is to track the licensing pressure trend. Everything is going down the stack. There are only a few types of software that can stay up at the top. Serviced based stuff. Software heavy in content, like modern games. Tax software, different in every state (needs a lot of paid people to research it, etc.). But most is going to go down.

Apache is there for the long term

We plan to exist for at least fifty years. How do we do that? What's needed just in the next 10 years?
One of the things around that licensing trend is Apache's licensing philosophy. We want everybody to be able to use our software. No restrictions, and you don't even have to make sure you give it back, that's your choice. We've found over time that people want to give it back because it's much easier to stay in sync with the main Apache stuff so we don't need to force them. Make it available to academia, hobbyists, businesses, etc. We're already starting at the bottom of the license stack so we don't see any problems.

How do we plan to make this survive? A lot of OSS projects are started by one or two people; they bang it out in a weekend and put it out there. Lot of rapid development, more releases, more people, adding patches. Then the initial developer is not paying attention anymore, off doing another project. If the orig developers disappear how do you make sure it carries forward? Concrete example: apache HTTP server, started with 8 guys. Today there's only one, spends part-time on the project. But, what has happened is that there are other developers that have come in. Some come in, some go out; about 4 are working on it at any one time.

The Answer is Community

A community outlives any individual. Apache strongly believes in communities to carry these things forward. In a healthy community you have peer respect, talking, out in the open, inclusive, new people can come along and be incorporated in the community and carry this forward.

What this does is encourage innovation. New people come in with fresh ideas on where to take the project. Then in a healthy community you get a consensus, providing a roadmap. You get people with a broad range of interests. For example some people like coding, documentation, web site, maintenance, release management, or something else. Some people work casually, some more full time.

The model we've found is very reproducible. 6 years ago there were two projects, Apache HTTP server and JServ. Since then, we've got all kinds of new projects, about 30 main projects, from Ant and Maven, Jakarta Commons, to servers, to application servers like Geronimo, to higher level things like Struts, content management, etc.. All these things keep building on the stack.

This model has produced very solid software in the process. Apache HTTP server, Tomcat, Jakarta Commons, Ant, mod_perl, etc. have been around for a long time, are solid and robust, and have had a lot of market success. Apache HTTP server has been number one for ten years. We've encouraged standards conformance. Apache has become the center of open source Java work. Eclipse is also to pick up new projects. They're generally Java focused too so it'll be interesting to see 10 years from now where the focus will be.

Apache's success allows it to have a lot of influence on open standards bodies like JCP and IETF. Apache forced changes in JCP to allow open source implementations of JSRs. This helps developers who could use the Apache software so they could use the standards in their own products. About 4 years ago, the AOL proxy servers had an error where they said "we sent you a response that wasn't allowed" and blocked it. Apache said, look here in the spec, this is the right response change your proxy servers. Finally AOL gave in to change the proxy servers to conform to the spec through Apache pressure.

When Eclipse was being founded, the founders took a look at the Apache model. How do the communities work, how do you maintain an inclusive environment, how do you manage the projects with a nice legal umbrella. Since then it's solidified it's brand and initial project but has begun to broaden offerings. Just like Apache has done. Long term viable model: be able to depend on this stuff, your business 10 years from now can depend on it.

What are some of the long term (ASF) steps: More projects and communities, all kinds of software, natural growth. Long term initiatives such as Geronimo and Harmony (J2EE and J2SE). Geronimo was done in about 2 years but Harmony is more like a 5 year project. We're working with other people in the community so we can provide the system to people right at the bottom of the stack license.

Recently we've been running into infrastructure problems so we've hired a full time system administrator and getting more machines for our communities. Eclipse is a bit different because it has money and support staff and so forth. Apache is all volunteers so everything is outsourced. It's interesting how many people do want to contribute their time. Eclipse has full time people. It'll be interesting to see how those two models develop over time. Mozilla foundation is similar, large paid staff, even have developers on staff. They don't have the same community focus as Apache and Eclipse. In 5 years we'll see.

Apache has a sort of Gravity Well thing about it. Incubator accepts incoming projects like SpamAssasin, XMLBeans, Derby. People arrive at incubator, does Apache want it. They want to live under the legal umbrella, encourage adoption and use, want to become part of the Apache brand. ASF is viewed as "capable" - it can accept a project and make it successful. We ask: Is the software good? Can we build a community?

Eclipse has also set up an incubator, which is one of the ways it will continue to grow - solidified around IDE and expanding out. As software arrives, there's legal and IP checks, then bringing in developers and community so it can continue for next 10 years.

One of the other ways Apache and Eclipse will grow is through Evolution. Apache started with just the web server, then app development platforms (Tomcat, mod_perl, APR, Cocoon, etc.). Over time the stack has evolved to create more capability. This will continue. Enabling technologies (Axis) Filling in holes (Derby, Jakarta Commons) Applications (Lenya).

What's next?

Desktop software? New protocol libs and systems? Calendaring? Who knows. We follow the developers. We want to keep a very open environment. Bring in new ideas, fresh things... this is the primary mechanism for evolving the stack.

Beyond software there are other things Apache wants to get into. For example the EU software patent issue. Open standards (HTTP proxy, anti-spam, keep patents out of patents). Outreach (talk to people about licensing, patents, what community means, how to run a project, share what we've learned). Talk to other Foundations and communities (like Eclipse).

We're starting to see more cooperation between Apache and Eclipse. I met Mike, and recently there was an incubator projects where one piece went to Apache one piece to Eclipse. There's room for coordination.

In closing, Apache and Eclipse are very unique. There are very few organizations working on OSS in this fashion. When you look at the organizations like Gnome or Python, or KDE, or Plone, they haven't taken an approach of community first and code second.

We're tracking the commoditization trend. Will Eclipse get pushed down the stack to a non copy-left license? We have an ever growing collection of useful software. We continue to provide more stuff that people find useful.

Apache is a charity. It provides software to the public at no charge. How can we best do that? With the nice licensing, and long term ability to deliver product. Feeling the undercurrent on what's going on in the industry, i.e., the move to service and assistance based software.

Take-away quote: "Plan your move to Open Source systems."