Agile Standards
With rapid development and deployment cycles, software developers cannot wait on the long cycles needed for most standards bodies. In the case of internationally recognized standards bodies such as IETF, W3C, and ISO, the time need to take a standard from proposal to adoption is measured in years!
With many high profile projects and Linux distributions relying on a more agile, rolling release model, there is simply not the time to wait on standards to be finalized to release updates to customers.
This is the basis for a growing need for more agile standarization frameworks that allow for organizations to rapidly innovate while still recognizing the benefits of international standards.
The solution to this need will come from agile standards — the combination of open source software to rapidly develop and drive standards.
Open Source & Standards
The synthesis of open source with standards is obvious. Both rely on open development models that require transparency and encourage community participation.
In his article, Impact Imminent: Open Source and Standards, Adobe’s Dave McAllister reaches a similar conclusion. He notes that the development of many web standards including HTML5, CSS, and ECMAscript are all driven by open source projects.
However, open source does not a standard make. Based on my experience with standards and standards organizations, there are several recommendations for agile standard development:
- 1. Identify the What, How and Who
- Define the standard space. The more specific the more likely it is you will succeed
- 2. Build the Minimal Viable Framework
- Focus on developing the minimal viable requirements for the standard
- 3. Open Source the Development
- Do the development in the open and under commercial-friendly license
- 4. Do Not Get Ahead of Yourself
- Do not allow yourself or the standard to get sidetracked too early
1. Identify the What, How and Who
The main goal for any standard must be adoption. In order to get adoption, you must have a clear understanding of the “what, how and who” for your standard:
- What are you trying to standardize?
- How will you standardize it and evaluate compliance?
- Who is the target community that will use the standard?
When answering these questions, be as specific and constraining as possible. The more restricted your answers, the more aware you are about your potential adopters and the more likely you are to succeed.
2. Build the Minimal Viable Framework
Do not get wrapped up in the details and possibilities. First flush out the minimal set of requirements necessary for your standard to be successful. In HTML, this was the need for a communication protocol (HTTP) and some markup language that could be rendered to the user.
This framework should be flexible enough to handle your problem space but flexible enough to allow vendors to experiment with your standard without breaking other implementations.
One example is CSS. While CSS defines the format of CSS rules and provides some attributes, it still allows for vendors to implement their own formatting extensions as long as the name begins with a - hyphen. To allow for compatibility without breakage, when interpretting CSS rules, implementations are permitted to ignore any attribute starting with a -.
3. Open Source the Development
Open source all of your standard development. This not only allows for potential users to see the code and how the standard might function, it allows for people to start actively experimenting with implementation options and provide feedback.
To allow for maximal user traction and allow for this standard baselining code to be used in products, be sure to license the code under a commercial-friendly open source license, such as Apache License, Version 2.0.
4. Do Not Get Ahead of Yourself
Do not be afraid to say “no”.
Focus on getting the foundation correct. Do not worry about what could be done and never let the standard or community get distracted with feature creep. If it is not covered by a “what, how and who” answer, it is out of scope. Ignore suggestions and comments that do not help with implementing the minimal viable implementation of the standard.
Too many standards never become standards because they get bogged down with being everything to everyone instead of meeting their initial needs first; you will never be able to make everyone happy. Once you have a standard, you can always add features.
I know this one from first hand experience trying to get the log standard CEE off of the ground. There is too much focus on solving all of the logging problems instead of first focusing on a standardized log record format and implementation thereof.
Discussion