An open source key value: Standards over Products

What values does an organisation require to enable the use of open source software? A utopian view of the world. A board of ex-communists? I have been thinking about this recently in the context of the company I work for. We have great open source skills. We are looking for the subtle cultural things that will complete our open source orientation.

Though it does not mention open source, I think a key enabling value is Standards over Products.

When you have a standard, such as a published protocol or specification, the way is open to have multiple implementations. Often you will have
commercial implementations (products) and open source implementations. When there is no standard, it is often very difficult to do an open source
implementation. By supporting standards over products, it enables a competitive software selection environment. The implementation chosen
can then rest on the quality and features of each.

An example is Rules Engines. In August 2004, JSR-94 was finalised. There are several implementations available. ILOG JRules is a high quality commercial product. drools and JESS are open source implementations. Lets say you propose an architecture which includes a JSR-94 compliant rules engine. You then enable the open source implementations to compete with the commercial products.

The value provides a level playing field and engenders fierce competition between all implementations, open source or commercial products. The decision to use open source or not, is then taken on merit.

By Greg Luck

As Terracotta’s CTO, Greg (@gregrluck) is entrusted with understanding market and technology forces and the business drivers that impact Terracotta’s product innovation and customer success. He helps shape company and technology strategy and designs many of the features in Terracotta’s products. Greg came to Terracotta on the acquisition of the popular caching project Ehcache which he founded in 2003. Prior to joining Terracotta, Greg served as Chief Architect at Australian online travel giant Wotif.com. He also served as a lead consultant for ThoughtWorks on accounts in the United States and Australia, was CIO at Virgin Blue, Tempo Services, Stamford Hotels and Resorts and Australian Resorts and spent seven years as a Chartered Accountant in KPMG’s small business and insolvency divisions. He is a regular speaker at conferences and contributor of articles to the technical press.

3 comments

  1. Unfortunately your example doesn’t do your otherwise probably solid argument, justice.
    JSR-94 is pretty much a complete waste of time. It’s a self-fullfilling prophecy. JSR-94 only succeeds because it’s a “standard” for standards sake. People don’t understand what it actually privides for (or rather lacks) but because it’s a “standard” it MUST be good. So they insist on it. Because they insist on it, open source software, such as drools, is forced to support a worthless standard. Because everyone supports the standard, it is hailed as successfull and a testiment to the idea that standards are ALWAYS a good thing over products.
    Rule Engines should be chosen on the basis of functionality and suitability to task, NOT whether they are JSR-94 compliant or not. With or whithout JSR-94, you will spend Unfortunately your example doesn’t do your otherwise probably solid argument, justice.
    JSR-94 is pretty much a complete waste of time. It’s a self-fullfilling prophecy. JSR-94 only succeeds because it’s a “standard” for standards sake. People don’t understand what it actually privides for (or rather lacks) but because it’s a “standard” it MUST be good. So they insist on it. Because they insist on it, open source software, such as drools, is forced to support a worthless standard. Because everyone supports the standard, it is hailed as successfull and a testiment to the idea that standards are ALWAYS a good thing over products.
    Rule Engines should be chosen on the basis of functionality and suitability to task, NOT whether they are JSR-94 compliant or not. With or whithout JSR-94, you will spend <1% of your development effort integrating with the rules engine with the bulk of time spent actually designing and implementing the rules themselves. Therefore, the underlying language, tools and features such as backwards/forwards chaining, logical assertions, conflict resolution, etc. should form the core criteria for your decision.
    JSR-94, like many standards, becomes just another tick-in-the-box.
    I'm not knocking the original argument, just the example 🙂
    My 2 cents worth.

  2. P.S. Whilst JESS is a fantastic piece of software, it is in no way Open Source. In fact, it has a particularly restrictive licensing model and costs $$$.

Comments are closed.