Friday, June 22, 2007

Standards in Software – The Ugly Truth

I want to take a few moments to deal with the ugly truth about software standards. “Standards” have become the hip thing in the GIS world, especially among the open source Java GIS commuity, since the OGC gained momentum. Here is an example of what I am talking about:

Deegree Project: “deegree is a Java Framework offering the main building blocks for Spatial Data Infrastructures. Its entire architecture is developed using standards of the
Open Geospatial Consortium (OGC) and ISO/TC 211 (ISO Technical Committee 211 -- Geographic Information/Geomatics).”

GeoTools Project: “standards compliant methods for the manipulation of geospatial data, for example to implement
Geographic Information Systems (GIS). The GeoTools library implements Open Geospatial Consortium (OGC) specifications as they are developed…”

GeoAPI: “The GeoAPI project aims to reduce duplication and increase interoperability by providing neutral, interface-only APIs derived from OGC/ISO Standards.”

What do all of the projects have in common? They are all written in Java, and they all implement one or more OGC standards.

I don’t want this to be a rant about the OGC and my problems with how they operate. (I’ll save that for another post.) I want to try to obtain some level of objectivity, so lets just examine software standards on their face irregardless of whether they are produced by the OGC or not.

Here are a couple of problems caused by software standards that are not properly designed and executed:

[1] They create obstacles to collaboration.
[2] They can stifle innovation.

I know those sound like some pretty controversial statements. “What is this guy talking about?” you might ask. “I thought software standards were supposed to foster collaboration and innovation.” Software standards are meant to do that. Boats are meant to float. A lot of them end up at the bottom of the ocean too. (Remember the Titanic?) Why does this happen? Because these boats weren’t designed correctly or built properly. That doesn’t mean you can’t achieve your goal of floating with a boat, it just means that you have to go about it in the right manner.

Let’s examine the two problems I mentioned with software standards one at a time.

Poorly Designed and Executed Software Standards Create Obstacles To Collaboration

Poorly designed standards fall victim to the trap of “standard euphoria”. People become so excited about standards, they become so focused on implementing these standards, that they forget to question the technical merit and practicality of the standard they are trying to use and implement. That can lead to a situation where a lot of different software projects are implementing the same poorly designed software standard. Or you get a situation where programmers are throwing a lot of time at implementing a confusing and complex software standard because “everyone else is doing it”. They would be better of spending that time on other functionality for their software or on improving software quality.

Most people would assert that this is an easy problem to overcome. “Just design better standards.” That is often easier said than done. For one thing, with the design of software standards often involves meeting the needs of a number of very different interested parties. That is an admirable goal, but is no easy task.

What if the process of designing the standard is an exclusive one, given to only a few privileged members of a software development community? That can lead to poor design as well. You could be excluding the one programmer that sees the problem in your standard and knows how to fix it. Or you could be ignoring the one programmer that will be deals with the very real world issues you are trying to address with your standard. In some sense software standards developed in this way go contrary to the very core concepts of open source software: Mutual benefit by shared knowledge.

Return to my example of boat design. Imagine that you are design a standard for the design of boats but you decide to only allow companies that design million dollar yaughts or container ships to participate. You exclude all the people that build and work on smaller vessels. How good will your standard be? What price will you pay for excluding that pool of valuable boat building and boating experience?

Why would anyone close of the process of designing a software standard like this? Control, control, control.

Make no mistake about that. (If you were a proprietary software company working to design a software standard that would dominate your particular industry, would you tweak it to your competitive advantage, or to someone else’s competitive advantage? Come on now, be honest with me…)

The execution and delivery of a standard can become an obstacle to collaboration as well. Even after a standard is complete the manner in which it is delivered to the community can be important. Will you require people to pay a fee to access your standard? Will you limit the way it is used or implemented? These aspects of standard execution and delivery can also stifle collaboration if not handled properly.

Poorly Designed and Executed Software Standards Create Obstacles To Innovation

In this situation we find that “standard euphoria” is the main culprit. People become so focused on implementing some software standard that they divert time and energy from other areas. That wouldn’t be a problem, unless the standard is poorly designed in the first place.

Another obstacle to innovation comes when members of the community are unwilling to work together on some area of software design because it isn’t going to become adopted as an “official” standard of a particular organization, or because it is still in the process of becoming a standard.

Let me give you one example of this. I have been working towards the goal of increasing collaboration between OpenJUMP and other members of the open source Java GIS community. As part of this goal I identified some functionality that I would like to add to OpenJUMP at some point in the future. I decided to approach a project whose stated goal is to encourage collaboration between Java programmers working on GIS. Although members of the project were very friendly, I was basically told that the project was only concerned with code that implemented OGC/ISO software standards. I didn’t let this slow me down, so I started looking around for an organization or group that would be interested in hosting code that explored some new aspect of GIS not covered by an OGC/ISO standard. I couldn’t find this organization, and I’m not sure that it exists. What does that mean? It means if you really want to work together on some particularly innovative area of GIS software development you’d better be involved in the OGC/ISO standards process. If you don’t want to do that, or if you are excluded from doing that, you had better be prepared to work on your own.

What type of software standards really work?

Does all of the above commentary mean that I think software standards are no good? On the contrary, I think they are one of the best things for software development, if they are properly designed and executed.

What does a software standard need in order to “float” or to meet its goals of encouraging collaboration and innovation?

[1] Software standards need to be designed in a process that is not exclusive or where membership is not based on financial contributions and/or fees. Membership in the process of designing a standard should be based on an individual’s or organization’s technical skill, capacity for innovation, ability to work with others, knowledge or expertise in the area addressed by the standard, and ability to think critically and objectively.

[2] Software standards need to be executed and delivered in a way that promotes use and adoption by all members of the software industry addressed by the standard, not by only a few members of the community. This means that people should not have to pay for a copy of the standard itself or supporting documentation. This should be made available in a free and open format. (For example, release this documentation under one of the Creative Commons licenses.) The authors of the standard or the organization maintaining the standard should avoid putting unnecessary restrictions on how the standard is used and distributed. Individuals and organizations should not have to pay a fee to verify compliance with a standard.

[3] Software standards should be accepted on the grounds of technical merit and the ability to be practically implemented and used, not because they are rubber-stamped by some multi-company conglomerate.

Of these three (3) elements, I believe that last two (2) are most important. (Note, however, that it is a lot easier to get #3 if you have #1.) Consider just three common examples of this:

What file format do you use if you want to exchange CAD data between different software programs? (Let’s pretend you don’t want to cough up a bunch of doe for Autodesk’s DWG libraries.)

You use DXF. Why? You use DXF because it works well and it has a freely available specification.

What file format do you use if you want to exchange digital documents and you have no guarantee of the operating system or software platform that they are using?

You use PDF. Why? You use PDF because it works well and it has a feely available specification.

What file format do you use if want to share simple vector data between GIS programs?
You use ESRI’s Shapefile Format. Why? You use Shapefiles because they work well and the Shapefile format is defined in a freely available specification.


The open source Java GIS community needs to overcome its “standard euphoria”. This is especially important if this euphoria is for standards that are poorly designed and executed, and that don’t meet the three (3) requirements above. Let’s evaluate each software standard for our area of expertise on its technical merit, and not race to implement it because it isn’t rubber-stamped by an organization that doesn’t follow a design process open to our input. Let’s not dismiss the possibility of working together on a certain aspect of GIS software because it might not be covered by a standard from the same organization.

The Sunburned Surveyor


Bill said...

I agree on the criticism, but suggest an alternative approach to address your issue.

A standard is just an interface contract. Interface contracts allows you to build loosely-coupled software. You don't need anyone's permission to work together with them: just grab a copy of their interface contract.

As for everybody doing the OGC thing, thats one hell of a reason not to do it. They're doing it for you. Please don't write Yet Another OGC Thing. Use their OGC Thing -- use the best one -- Java or not.

Say they've got a yacht standard, you've got a dingy company. If you design a dingy that fits on the back of their yachts, you're in business.

Andrew Bolt said...

> but suggest an alternative approach to address your issue.

Many of our favourite standards started out in life as point solutions in proprietary applications. They only become standards after they have proven their worth.

Prematurely designing an open standard creates pressure on designers to adopt that standard rather than work on their own point solutions -- even if the standard doesn't tackle their specific problem in a flexible manner.

It is very hard to create a good standard, especially in an emerging design space. A committe staffed with clever people (and with no ulterior motives) might tend to do a better job than a single developer creating a point solution. But, given an ecosystem with enough point solutions, some of them are going to be better than the committee's solution.

So, the best approach to creating a standard is to let people create proprietary solutions, wait a while, and then ratify the best solution. (Or create a new standard by cherry picking the best of the proven ideas).

Addison said...

Hi, Added a new value add to my blog this weekend - a news widget from I always wanted to show latest news for my keywords in my sidebar. It was very easy with this widget. Just a small copy paste and it was done. Great indeed.