Wednesday, July 27, 2005

Open source solutions will precipitate proprietary opportunity

Open source has changed the game from a cost of software point of view. The traditional model with a split of support over cost/license of 70/30 is changing to a full service model, the 30% has disappeared. This "cost free" element of Free Open Source has launched a bunch of new commodities, for example, LAMP is a serious contender to .NET or J2EE. The fact that it is freely available has been hugely influential here.

But the software bits are not the whole picture, it is the solutions that are build on them that are important. I think we will find that the Open Source commodities will precipitate the commoditisation of traditional closed source or proprietary components through complete integrated solutions. The proprietary modules that are really good at what they do and that play well with Open Source will be successful. That is, they are easily integrated with existing open source components and platforms, are well supported, reasonably priced and reasonable open (from a standards and extensibility point of view).
The proprietary components that work well with open source will become commodities on the back of the open source wave, the customers/market will decide what works well and what does not; essentially the overall integrated solution will be open, the proprietary bits that integrated easily will form an integral part of that solution.
Other uses with the same itch will try the same solution, to facilitate the proven complete solution they will pay for a suitable proprietary component.

One problem with this model is that a real open source alternative commodity will eventually get created by the community, unless of course there are large barriers to entry like huge complexity or the need for a mainframe to test it or something. It may simply mean that traditional proprietary source has a very short life span, build it, charge for it, then give it away once the 'critical mass' of use can provide a support revenue stream.

Hybrid open solutions that combine mostly FOSS with proprietary modules are inevitable, I think a software company can find a niche with a traditional business model applied in 'internet time'.

Services companies will find a niche in customization, and the commonality their-in will be the genesis for a traditional product.

Monday, July 04, 2005

Branded Open Source

Falling for a brand, Lajos Moczar describes how it can happen:
"The most important point I can make here is this: if you cannot articulate your business needs and identify IT products that can help you fulfill those needs, you end up thinking in terms of concepts. When you think in terms of concepts, whether feature buzzwords or more general buzzwords like 'mission critical' or 'enterprise interoperability', your thinking is divorced from your needs. And when that happens, the marketing departments have got you. No matter how objective you think you are, you will inevitably find yourself choosing a brand name."

This comment is in the context of Commercial Open Source(COS) organisation that are using branding to make money out of the open source movement. He talks of new monopolies, controlling the innovation. I think there is lots of value in the alternative openstructure approach, where the customer/market determines the best fit for a problem based on the context and prevailing community view.
COS may lead to unnecessary duplication and bias. The duplication comes from competing with other branded open source, we will see this with JBoss and Gluecode now that IBM has taken an interest in Gluecode. The bias will come from following a brand rather than from following a technology or implementation choice. The meritocracy of open source will be lost to the power of marketing.

But maybe the savior is the brand, with IBM using the open source stick to beat off JBoss, it will be a brand war between IBM and JBoss. It will be hard for JBoss to win.
The trump card for open source is the community, while customers may flock to the brand, the community should target the most interesting and appropriate technology. The community should be (and I think are) brand agnostic, the code is the reference.

The only problem is that at the moment the community does not have the buying power, there are no community solutions, so brand still dominates in the procurement process. Open solutions are the way forward.

Friday, July 01, 2005

Google's view of the world is just opinion

The Google-opoly of page rank is just their opinion, nothing more, they can change it at any time, it came up in court and looks likely to remain that way. From slate:
A terrific analysis of the case from James Grimmelmann on LawMeme suggests that Google is more than just sorting Internet content: It's a "gatekeeper" that effectively bars access to anything ranked lower than 200 by its ranking system. Massa seems to commit legal hara-kiri on his Web site by conceding that Google's opinions are protected by the First Amendment.
If your page rank changes over night, and the gatekeeper decides to close the gate for what ever reason, there is nothing you can do, in Google we trust, but I guess they know that.

The Open Source Interest Horizon

Clay Shirky writes about the Open Source interest horizon (one of the limiting factors) and the future of open source, providing the building blocks from which customised systems are built.
"This is the future of Open Source. As the edges of the interest horizon become clear, the market for products will shrink and the market for customization will grow: Expect the Computer Associates of the world to begin training their employees in the use and customization of Open Source products. With Open Source software putting core set of functions in place, software companies will become more like consulting firms and consulting firms will become more like software companies, not duplicating the same basic functions over and over, but concentrating their efforts on the work that lies over the interest horizon."
I agree, using the analogy of the architect from civil engineering. Consider building a new bridge, three architects will produce three different designs, but each will be proven to satisfy the requirements because the underlying core components are well understood. For civil engineering this comes from standards, professional indemnification, laws of physics etc. The chosen design could well be the most aesthetically pleasing design or the one considered the best fit with the environment. The point being that the decision can be based on intangibles, qualitative variables, because the core functionality is a given.
With dependable open source components or building blocks, the software architects of the future will be able to produce alternative designs that meet the same underlying need or set of requirements. They can concentrate on the customization, on demonstrating that they best understand the customers wants and needs. The customers get the real benefit because they will be able to choose a customized system that they really want from a valid set of competing and mostly equal options.
In the absence of hard and fast rules and standards for software components, open source commodity components can provide defacto standards.
The crucial element, is that these components grow out of a need to solve a real problem in context; the problem is at the heart of the solution.

Clay cites the interest horizon as one of the limiting factors of open source. I am no sure I agree, interest is one of the key motivators, but as the value of the model becomes apparent to more stake holders, interest will grow in all sorts of small groups and niche markets. I think open source will become a core activity of most professional software developers, it will be their day job rather than a hobby. Their interest will be maintained by a salary at the end of the week.
Like the architect, the software engineers real skill will be in integration and customisation. Understand the real requirements of the system, providing domain knowledge and finally bridging the casm between customer needs and service deliverables. The fact that new code artifacts are added to the public domain as a result will just be a nice side effect.
The future with open source building blocks is bright.