Glass Cathedrals and Community versus Code

Collaboration

From the proverbial "Day One" of thinking about OFBiz it was clear to me that I couldn't do it alone, and in the financial environment of the day (early 2001) it was also clear that there was no way I could raise the money necessary to make the dream a reality. That was especially true for me because I had nothing in my background other than a couple of years of research and failed commercial attempts to set me apart and make me of interest to prospective investors and partners.

Enterprise systems in general are large, complex things and require hundreds of thousands of man-hours to implement. On top of that with such a wide variety of businesses and real-world requirements designing something that would be flexible enough to be a good starting point and that would not require rewriting significant parts of the software would require a body of knowledge and experience that would be almost impossible to pay for. To start from scratch and build such a system would require a lot of collaboration.

The traditional means of collaboration in the commercial software world is to pay for a license and hopefully influence the vendor to add or fix things. There is little influence in this. Some vendors will accept payment for development of specific features, but for the most part customizations and specific features are built outside of the core product and never shared. This is a very limiting form of collaboration.

I worked with open source software before getting into all of this enterprise systems stuff as part of a company called Lineo that was creating products for embedded systems based on Linux, and in college as well. While doing R&D for an ecommerce startup I also ran into a number of open source alternatives, but mostly in infrastructure software, there just wasn't anything real happening in enterprise automation at the time.

The collaboration problem and the open source solution seemed the perfect match. Collaboration through a non-profit, open source effort seemed like a significantly more efficient way to go about things that collaboration through commercial licensing and the often disposable results of consulting engagements. With no financial entanglements collaboration can focus on solving problems and creating solutions with a long life span. Speaking of life span, the likelihood of survival for a piece of software is much greater when no one company can fall and take the software with it.

And there was more. I saw quickly that in addition to making the development of such a system from scratch possible, it also made the results of the development effort far better than any individual or static team working in isolation ever could. I started to see the lack of funding and the necessity of working on contracts to survive as a great benefit to the effort rather than a distraction from it. In short if I had personally had all the time and money I needed to site in a room and build this system, or even just the framework part of the system, it would not be anything like the real world need driven framework and application set that it is today.

The collaboration was just amazing. So many people suggested things over time and even though the majority of the suggestion never yielded anything immediately fruitful, there were so many that were critical and that pushed us in the direction we wanted to go by paths we hadn't even considered. I'm comfortable admitting that there is no way I could have built OFBiz the way it is now on my own. Over time I have also learned to accept that in many cases things I built and thought were great were inferior to existing alternatives or ideas about better ways of doing things. In the first 2-3 years of OFBiz we threw out as many lines of code as we kept. There was continual housekeeping and refinement, and there still is today even though these days the patterns and practices are more established and tried and proven, so the need for this is less frequent (on a large scale at least...).

After running OFBiz this way for years there were various people and organizations involved and this means of collaboration was proving to be very successful and stable. We were certainly not the only ones to run a software project this way and in 2006 some people from the Apache Software Foundation approached us, recognizing the similarities in philosophy, and inviting us to join the ASF. The more I read about Apache the more I came to see things this way as well, and the more I could see that they had the same emphasis on how to structure an open source project that I had come to. The great thing was that they had a much better organization and much better legal infrastructure (including the Apache License 2.0).

One of the main tenets of the Apache Software Foundation is that the community is the most important thing, and if you get that right then good code and other things naturally follow. In other words, if people are brought together in a way that enables minimally encumbered collaboration they will create something good, and something far better than if that collaboration had not been present.

Code

This may seem obvious to many people these days. These sorts of concepts have come a long way in recent years, even outside of the once fairly limited open source development circles. So why am I bringing this up now, and writing about all of this nearly 7 years after the inception of OFBiz?

The answer is that the principles and efforts of community driven open source projects have as much impact today as ever, and are a key to distinguishing efforts in the so called "open source" world.

There are some in the real open source world that don't focus on community and collaboration, and suffer because of it. One big potential problem for open source projects is a forked code base, or more importantly: a forked community. Sometimes a community degenerates or there never really was a strong community at all and a fork is appropriate.

In many cases though people fail to recognize the importance and value of the community and collaboration within it. For whatever reason they decide that they can do better on their own (often along with select others). They decide that the code is more important than the community.

In the OFBiz world there are various examples this failure to collaborate resulting in projects largely based on OFBiz but that have chosen to go in different directions. Many of these are open source projects, but organized and licensed in a way that fails to enable the collaboration necessary for success.

Glass Cathedrals

That's the main point of this blog entry, but I have a little more on my mind related to this and commercial dual licensing and the GPL license, and of course the dozens of variations on the license.

In general I agree with the ideals behind the GPL and the philosophy of Richard Stallman and others he works with on this. The idea of making software free and keeping it free is great, especially for certain types of software like infrastructure software that is used en-masse but not frequently customized (ie the improvements are nearly always generic enough to be shared). The reason that I originally pushed for the MIT license, and later the Apache License 2.0, is that these are more commercial and proprietary derivative work friendly licenses. When creating software that is meant to be customized it wouldn't be wise to legally or technically encumber those efforts.

What I really wonder is what Richard Stallman thinks about the practice of dual-licensing using the GPL and a commercial license. For these sorts of so called "open source" projects the only reason they want to use the GPL is its terms are the most onerous and are most likely to lead people to pay for a commercial license. In my opinion this is a deceitful corruption of valuable open source principles.

The development on these products (not really open source projects...) is generally done by a small group of paid designers and developers and there is little community interaction. Many choose to collaborate only financially instead of bringing their unique requirements and ideas to the table to enhance the core project. There isn't a lot of incentive to try to contribute back or collaborate when it is made clear from the beginning that there is one player who wants to own everything and that you don't really have a chance of being that player or competing with them in their own game.

The code becomes more important than the community. It's a bit like putting the cart before the horse in that there is a failure to realize the cause and effect and an attempt to get the affect (the code) with the cause (the collaboration in the community).

This is a major case where the use of the GPL breaks down collaboration instead of enabling it. This does happen in purely open source projects as well though, with GPL and other licenses too. Eric Raymond wrote a lot about this with his parables of cathedrals and bazaars. With cathedrals collaboration is limited and that is the biggest problem, whereas the collaboration possible in the bazaar is the real power in the model.

I would argue that this happens even with publicly developed open source projects if there is no incentive for or focus on enablement of collaboration, ie no real community that one can become a part of and influence and improve by just being positively involved. Some purely open source projects are this way, but most open/commercial dual-licensed products are this way. Even the "open source" parts are developed in a sort of "glass cathedral". People can see what is going on, and if they really want to they can walk in and participate, but most choose to stand outside and watch and in fact pay to not get too involved.

So, in closing, here's to Glass Cathedrals and the opportunity they give to community driven open source projects to differentiate ourselves. It also brings to mind that old saying... something about stones and those who live in Glass Cathedrals....