The Organic Software Trend

No so long ago, software was designed, implemented, tested and delivered on a CD. This cycle could take anywhere between 12 months to 36 months. Some companies like Microsoft make the bulk of their money from Window and Office, products which still follow this model. I think that this cycle is the biggest treat for traditional software companies (bigger than the cost of burning and sending CDs around, bigger than the pain of having to install and maintain the software).

The alternative model, the one used by open source and most software as a service companies, is much more organic, experimental and iterative: you build the minimum functionality to offer some value to the customer (enough for them to exit their existing solution and adopt yours) and then you observe, try to get a better understand of how they use the existing solution (and where the rough edges are) and what additional things they would like to do. This direct link between you and the customer combined with fast iterative cycle is the best weapon to use against more traditional software companies: continuously collect feedback, prioritize it, prototype solutions, do A/B testing, create APIs for others to extend your core offering and watch 100 flowers bloom (some of which will be ugly and die, some of which will be very clever and will add value to you offering). Short iterations not only allow you to be fast but to also be much more darwinian: it is much easier to kill a project/idea/feature when you have only spent 2 developers x 2 months. This more organic behavior results into the addition of 100s of meaningful details and the refactoring of 100s of rough edges and becomes key to the the long term success or the failure of a software development project.

Here is an example: In 2003, we created a blog for Collaxa. I remember that back then, Blogger was hands down the best blogging tool available. A couple of weeks ago when I went through the same decision process for this blog, I tried both Blogger and WordPress. I decided to use WordPress, because of where it is in terms of features (number of themes, number of plugins, add-ons, domain options, etc.) and most importantly, because of how fast it is mutating (something that you can not artificially inject into a product no matter how much money you throw at it).

What are some of the other fast mutating species out there? Here are some of the ones which are close to my heart: Firefox (vs. IE and Safari), Ajax (vs. Silverlight and AIR), Eclipse+Aptana, Facebook and Ning.

There is a lot more that can be said about this topic. I think that the trend around organic software development is here to stay and we will see the tipping point shortly.

Updated on Dec 11th, 2007. Since I initially wrote this article, iphone and android have injected a second life in webkit and it is now evolving at a fast and furious pace. The firefox vs. webkit it going to be fascinating to watch!

Scalling Atlassian

My friend Ludovic pointed me to a post from Mike Cannon-Brooks on their journey scaling Atlassian. The experience is captured in this (great) presentation (1 MB, .pdf). This made me nostalgic about the Collaxa time. It is interesting to bump into this post the same day Jive Software raises $15MB to scale out sales and marketing. Having been on both the Collaxa side and the Oracle side, I think that organic demand driven sales is the only approach for smaller companies to scale and compete against more establis hed vendors. Another justification as to why Joel Spolsky is doing a World Tour to scale out FogBugz.

Barcamp 2007

I have the chance to spend the afternoon at Barcamp 2007 in Palo Alto. It was my first barcamp and a great experience. Kudos to the team who put the time and emergy to organize this event.

Highlight #1. I was very impressed by the open, organic nature of the event. No big banners with marketing messages. Instead a self organizing wall were people could publish and subscribe to talks.

Highlight #2. Tom Conrad, CTO of Pandora, did a 45 min talk on the lessons they learnt while scaling Pandora fro 8 users to 8 millions users. Both from a technology, marketing and support perspective. Tom is a great presenter with a very conversational/engaging style. They have a very open culture centered around listening to customers and focusing on building a great and differentiated product. They took three very important turns in the history of Pandora: 1) focus on internet radio, 2) differentiate by building the first product to allow users to create their own channels in one click and 3) shift from a subscription-based model to a creating ad-based model.

I had the chance to interact with Tom a couple times while he was at Kenamea and I was at Collaxa. I am glad to see that he/Pandora is doing very well.

Assembly, Composition or Orchestration

This podcast from David Chappell tries tries to address a though question: what is SCA? What makes this challenging is that the terms assembly, composition and orchestration are abstract concepts which do not really have clear boundaries in peoples minds.

So what is the difference between orchestration and assembly?!?

Orchestration defines a set of steps/activities which represent a business process (step 1: verify the user account, step 2: verify inventory, step 3: process credit card, step 4: send email to the user). Some of these steps can be performed sequentially, some of them in parallel, exceptions can occur, manual intervention might be required, etc… Some orchestrations can be simple, some can be very sophisticated. Orchestrations are modeled using a standard language called BPEL. [ (Updated based on the comment from Greg Pavlik) Note: Orchestration logic is not usually captured in one monolitic business process. It can include subprocess steps (which can be distributed physically across the enterprise or across enterprises). The process itself or some of it steps can be implemented in Java or C.]

But what is assembly then?

As part of step 1, the BPEL process needs to integrate with an LDAP service. As part of step 2, the BPEL process need to integrate with an SAP system. As part of exception processing, it needs to integrate with a workflow sub-system. These integration points (links between BPEL processes and external systems) are called bindings. Bindings usually include location of the different services, protocols to use, security, logging and reliability requirements. The SCA Assembly spec defines a language for modeling these bindings.

[(Updated based on the comment from Greg Pavlik) Note: In the case where a process include subprocess or other component written in a variety of languages, the binding problem extends beyond linking to external systems to the need for linking to internal parts.]

The benefit of SCA is that is makes bindings much easier to monitor, manage and change – not super sexy but the potential for a significant step forward in terms of deployment and change management.