Fast Takes

Home page of John McDowall

My Photo
Name:John McDowall
Location:Redwood City, California, United States

Saturday, May 21, 2005

Open Source - Software or Services

The acceleration of adoption and acceptance of open source by the mainstream is accelerating see: Investors to commercialize open source and IBM buys open-source Java outfit Gluecode. These are major chasm crossing events and should be celebrated, and congratulations to all involved. However I question that this is the best model economic model for all open source projects. In fact I will argue that if an open source application project is a technical success it inherently will undermine the current economic model, based around paying for support.

The current thesis is that users of open source software will pay for support, bug fixes, training, consulting and other soft services. The fallacy of this model is that open source software has moved into the mainstream because a vacuum exists. Existing software is not meeting the needs of the users of software. I am not an economist but my instincts tell me that the need for open source software such as Linux, Apache, mySQL. JBoss, etc is caused by economic forces not by any altruism within corporations. Successful open source projects succeed because they meet the market needs, have higher quality and are easier to use and maintain than closed solutions.

I would argue strongly that the most efficient companies in the next decade are those that minimize internal resources IT by maximizing the use of external services. This is a demonstrative trend - we have moved from internal data centers to shared data centers to managed applications within the last 8 years. The economics of shared resources are just too powerful to ignore except for the largest companies. Why does anyone want to hire a set of DBAs to manage a customer database when they can get it done for a few hundred dollars a month - and scales linearly by usage. Why does anyone want to buy install and manage a set of servers when they can have someone do it for a monthly fee - add, change, delete based on need not educated guesses but on actual usage. In other words the utility model is here and it is the economic model for the future enterprise - the most efficient enterprises are the ones that will manage it best.

The key differentiation that I make is between open source solutions and infrastructure. Infrastructure is operating systems and web servers etc. Solutions can be anything from an SFA application to an XSLT transformation engine. The model for the two is orthogonal - infra-structure has to be everywhere to power the grid ( like redhat and Apache) but applications like openCRX or XOOPS to pick a couple from SourceForge should not require deployment - they should just be usable. A recent posting from Tim Bray points out that half of IBM's income comes from consulting - the rest is from sales of hardware and software, with software being only about 1/6 of the total. To put it another way 25% of the cost is license fees the bulk of the costs 75% is from installing and getting it to work. No wonder there is so much shelfware around - a lot cheaper to leave it on the shelf. (Note: this is a somewhat simplistic argument but experience has shown me it is essentially correct).

Returning to open source - the drive for open source projects (IMHO) is to create software solutions that due to its open nature, benefits from continuous peer review and a Darwinian evolutionary process. The current approach to deriving economic benefit is inherently the antithesis of open source. The drive in an open source project is to make it more accessible and through peer review high quality - when these goals are achieved it becomes widely adopted. This inherently(and correctly) diminishes the value and need for support services. Putting it another way the most successful open source projects are those that are most accessible and have the fewest bugs and hence the least need for support. The current support model means for open source application projects to succeed economically they must deliver and continue to deliver software that requires support.

There is another way however that actually combines the best of both worlds and provides companies with a clear economic model for paying for services and enhances the ability of the open source community to deliver high quality software and if appropriate reap an economic benefit from their labors. For the majority of open source projects the model should be services not software. By services I mean applications that run on a managed grid that can be accessed by anyone. The applications are accessible as individual services or collections of services this attacks the largest area of costs that enterprises face.

This approach provides a few interesting benefits:
  1. Drives developers to solve business problems rather than point solutions (how many POP services are listed in SourceForge?, why do we need so many - some is the Darwinian process at work. However the accessibility of all these projects is an issue.
  2. Provides an economic model for developers (and potentially investors) to share in the benefits the work is delivering and motives the correct model - easily accessible bug free software has higher value for both the consumer i.e. I will pay higher for an easy to use robust service and open source developers want to deliver accessible highly secure and robust services.
  3. The open source model still works - I can look at the code and submit fixes and accelerate the development as needed.
  4. There is a reason to pay on going fees for the same high quality solution - the model is now about usage and the service level agreement (SLA). The higher the demands on the SLA the higher the potential fee. I believe this aligns the development and user community better than any other model.
  5. The development effort is now focused on a single platform and not on how many platforms can I make it work on. It is focused on the solution not on how to deliver the solution onto multiple platforms.
This alignment of the economic model and the drives of the open source community is critical for the long term success of this model. Improving the quality and accessibility of applications while removing costs from the IT infrastructure is going to make enterprises more efficient and hence more profitable. Without this alignment the current wave of investments in open source projects will just be more VC roadkill as they are attacking small (25%) problem not the big (75%) problem. Instead of changing the model they are thinly disguised System Integrators that have experience in a specific set of technologies.

Friday, May 20, 2005

Dynamic Languages

In Phil Windley's Technometria | The Continuing March of Dynamic Languages Phil suggests that Scheme is a great dynamic web systems. I have a fond spot for scheme as way back I worked on a system that used scheme as a dataflow language for creating analysis tools. It was based on some cool research a bunch of guys at MIT had done. It was extremely flexible and we could do anything with it. Coupled with XML I think it is a very interesting avenue to explore. I look forward to hearing more about Phil's adventures.

Thursday, May 19, 2005

A small understatement from Stefan

I just LOL when I read footnote [5] in Stefan's posting RPC-style Web Services. The only thing that compares to (and exceeds) the complexity of Corba is OLE2.

Wednesday, May 18, 2005

WSDL 2.0 - First impressions

After reading Dave Orchard's Blog: WITW WSDL 2.0 HTTP Binding I downloaded some of the WSDL 2.0 specs to read on the train. I am pleasantly surprised as compared to WSDL 1.1 it appears much more accessible. Whether my positive impressions are due to too much reading of WSDL 1.1 not sure. Mark Baker as always has a very pithy comment that aside all the people involved should be congratulated for their hard work.
Congratulations aside, I question the idea of a "single SDL to bind them all". So I ask the question, why do we need a single SDL, when would I need to use both? It is certainly a nice idea but as technology evolves, different areas typical move at different rates and evolve in different ways. Linking them usually tends to be a bad idea.

Monday, May 16, 2005

Simplicity - Just ask why

One of the most powerful questions I ask myself (especially) and others in reviews is why is something in a project. As engineers we have a tendency to like shiny new things, elegant abstraction etc.

As is pointed out in Quoderat » Blog Archive » Burden of Proof injecting simplicity is sometimes about just asking why something should be added or why is there a need for a layer of abstraction or why is there a need to make the solution completely generic. In many cases there are very good reasons to add abstraction etc.

We need to always challenge ourselves to see if we are solving a real problem - so just ask why.