Standardization is essential for certain parts of the stack, those items that change least frequently i.e lower in the stack. Higher in the stack needs to change frequently and here standardization kills innovation. We need to remember it take a lot of time to get to a standard and also Open Source will always be easier to engage with as a develop than a standard.
Open standards can also help open source, as many companies are not interested in using an open source project unless it has a sponsor or is part of a well know organization i.e Apache. However, it really needs to start open source and move to open standards, just trying to become a standard often leads to the wrong group of people getting involved in the standards process; it all gets a bit political and horse trading occurs over functionality. But moving toward a standard can also be impossible for small companies and individuals to get involved in a standard, whereas it is easy for Oracle and others (who have staff with this as there sole responsibility). Also standards can feel like they are dictating how we should be working and this can grate a little when we are already working well ; Is the JPA better than hibernate – No.
Standards should consolidate the gains made in an area of technology – in effect locking in the gains made and stabilizing prior to further innovation. The value in standardization in that it can facilitate multiple versions of the technology that can inter operate; innovation.
Ruby has now figured that without some form of standards and specification it is not possible to have multiple implementations that can interact and is now looking at moving in the standards direction. Without a standard interoperability between systems becomes very difficult.
For smaller projects i think it’s more about blessing by association with the standard(s). This allowing the potential user to have some confidence in the implementation they are about to try out.
2 responses to “When is open source and standardization right?”
Standards should follow practice. EJB is the perfect example of defining standards for things like object persistence before the industry had actually worked out the best ways to do it. So the pre-maturely standardized persistence beans were a disaster, and Hibernate emerged as a decent model.
There is a great story (I can’t find via Google) about two different approaches to design. Imagine you have a corporate campus, and are trying to decide where to put paved footpaths between buildings. The normal approach is to do this before you build the campus. You can tell when a campus has been designed this way, because nobody uses the footpaths and you can see dirt paths people have worn into the grass.
The second approach is to build the campus, but don’t put the paths in at first. Wait until dirt paths emerge in the grass as people walk between buildings over the first few weeks, then pave those paths.
[…] http://markedgington.com/2009/03/12/the-evolving-guardiancouk-architecture/ http://markedgington.com/2009/03/12/when-is-open-source-and-standardization-right/ http://markedgington.com/2009/03/13/a-story-about-a-technical-architect-pimp-my-architecture/ […]