The more interesting question for developers has to do with infrastructure software. In my mind LAMP is really a proxy for “infrastructure software” If you’ve been paying any attention at all to the development of web application software, you know that there is a lot happening with various kinds of infrastructure software.

is understandable. Almost all the current PaaS vendors have developed mechanisms to harvest commons based peer production. Ultimately all of this ends up in some server of a vendor locked away in a data center somewhere. Most of the vendors use open source software heavily for their PaaS offerings and some have open sourced bits and pieces of their platform. While I’m certainly not the overzealous freedom fighter I was, this awfully sounds like writing open source applications for a proprietary platform. Not that it’s necessarily a bad thing. Unlike developing software on a proprietary operating system, developing on a proprietary platform as a service offering is limited in various aspects which are unique to its usecase.

So, IMHO, a more interesting problem to tackle in an environment like this is open source platform as a service. You still have a hosted service where people can just develop applications and forget about underlying technical details of the platform, where your data is residing and so on. At the same time this entire platform is open source! Sounds like a pipe dream but it’s a reality. I hope this will set a trend that other vendors follow, eventually.

The open source platform as a service is Stratos. The hosted platform reside in cloud.wso2.com where anyone can register for free (during the alpha and beta stages) and get an entire middleware platform at your fingertips with a few clicks. Another bold move is that the code base of the downloadable version and the hosted version are exactly the same! So, the platform itself and hosted applications behave in a predictable manner where ever they’re deployed. Also, it should be mentioned here that most of the services provided by Stratos started their life as standalone programs (like Tomcat). This also, provide invaluable repository of information if anyone wants to study how their should architect their applications to make them cloud native. Source code for the entire platform available here.

So is open source the miracle cure for every proprietary solutions that cost a fortune on an yearly basis? Although some people talk like it is, reality is much different. A typical CTO will be reluctant to give up an existing deployed solution and go for an open source alternative. This might be for couple of reasons,

• The system works and it’s operational going offline is going to cost a considerable amount of money and business disruption.
• There’s no open source alternative out there that is a drop in replacement for any given large proprietary deployment of an ERP, CRM etc…
• What would happen to existing data? Will they be migrated? Can they be migrated seamlessly?
• If it’s a large enterprise operating in many industry verticals, does the alternative ERP system have modules working on those industry verticals?

There might be much more reasons, and many more specific to a given organizational setup, I’m just trying to list some general barriers off the top of my head. Most of all a formal TCO study might have to be carried out in order to justify the decision to upper management.

This is one area where a proprietary vendor, take SAP for example, thrive. They have a single solution where you deploy, tweak some parameters, do a BPR and everything starts to just work. Looking back at open source software vendors, I’m not aware of a solution like what SAP has to offer. Although SAP is ridiculously expensive a lot of companies are willing to pay money to them. They do have one heck of a product that works for many different businesses. I’m not sure how Compiere is doing compared to SAP. Looks like they’re doing quite ok. But the 3rd party vendors developing extensions and modules for SAP are several times bigger than for Compiere (if anyone is aware of a quotable statistic please do holler).

Let’s take another example. If your company intranet is running on Microsoft Sharepoint and you want to ditch that and go for an open source solution what would you be looking at? There is no single open source solution that you can compare with Sharepoint. Sure you can get a set of open source projects, put them together and make it your infrastructure. People who have done this knows how hard it is. Getting two separate projects to work with each other can often be described with the word nightmare. They’re not built to integrate. Most of them does not expose their data as Web services so you don’t have an effective method of accessing those. IMO, it’s another area where commercial offerings of open source projects can partner with each other and provide more integrated solutions rather than single products.

If you’re a tech startup you could probably put up with 5 different passwords for 5 different systems that you have to use. Wiki, CMS, bug tracker, forums and webmail. Giving single sign on between the applications is an important factor from an end users point of view. It certainly make the system easy to use and accessible. True, you get software like CAS but a couple of years back when I took it for a spin getting it to work with different apps turned out to be a colossal pain in the arse (it might have become more developed with great many plugins for different systems now, I haven’t looked at CAS recently). Doesn’t have to be that way. For solutions like this, built with open source, people are willing to pay money yet nobody is doing it.

So, I believe it’s a great time to think in terms of integrated solutions rather than individual projects and take those open source projects, make them easier to adopt and integrate into a wider enterprise environment.

Compare this with a more traditional method of maintaining an open source project. Alan mentions SourceForce as an example. It’s not the only one. You have a central repository where a few people act as committers who can control what changes can go into its repo. GitHub on the other hand provides a new perspective. See the graph for Ruby on Rails for example. With a decentralized view like that you can quickly find out who meddles with the code and who are the people having a keen interest to contribute.

Amount of politics that’s going to be generated around the project is very limited compared with a centralized cvs/svn repo project. You can get rid of all those private mailing lists and just carry on with what matters most, after all code speaks on everyone’s behalf