Over the last 10 years I've been working for the large company, which was influencing the direction the industry was heading. I did various projects there, but some of the most gratifying were those which served a purpose of developing or enabling a technology.
Product vs technology
There is a difference, that one of my more experienced coworker made me aware of, between building a product and building a technology. In the first case you are limited to the existing specification, which is both good and bad. Known limitations lets you make sane decisions about the product requirements. On the other hand, your implementation depends on how good the specification is, if your product needs to be backward compatible, how it needs to fit into existing ecosystem and finally how to make your product different from others.
What about creating new technology? The problems are at a different level of abstraction: is it possible to implement this, does it cover all possible flows, does it give possibility to provide custom implementations, is it possible to do interoperability testing, etc. It is often impossible, to answer these questions by a single person (or even a single team). The specifications are coined in the long process of reaching consensus between competing companies. Sometimes the process fails, and the final document gives so many implementations options, that two products adhering to the same specification are incompatible.
Ways to become a contributor
Once the specification is published in a form of pre-release draft, usually there is still a lot of room for improvement. Although, at that point, the early adopters are finalizing their products, there are multiple flows and corner cases, which yet have to be discovered. Even when the specification is released in v1.0, I can assure you there are things there which are missing, unclear or simply wrong.
The best way to find them is to start working on the implementation. In case of the HW interface specification, it may be too expensive for a single person, home project to do the implementation. Depending on the technology, but the most successful ones, are driven by corporations (e.g. see list of contributors to USB specifications). If your goal is to contribute to wildly adopted technology, the easiest path is to find a corporation and a team inside, that is implementing the specification. Of course, this may also be a matter of luck - being in the right team at the right time.
What if you are not willing to work in corporation? Well, I have seen contributions from start-ups, and smaller companies, but I do not know how they gain access to early version of specification. I would guess that this is a part of membership agreement.
There is also w third way - working for a large company, but remaining independent. This is the way for the OS community member, usually Linux kernel developers.
How to contribute
Assuming that you are implementing a technology, and found an issue with a specification. First thing to do, is to try understanding the intent behind the concept. There may be deeper sense why something is designed in a specific way.
You may also need to ask about your finding on the forum. If possible use diagrams, it will significantly improve the communication. Writing a 100 pages of e-mail instead of single drawing is a straight way to get hardly any responses.
Be patient, even the brightest idea will need to be reviewed by multiple peers. Providing clean description of the issue and proposal of the solution will speed up the process.
If you are implementing a product based on a standard technology, try to attend interoperability testing event. You will find out about the scenarios you did not take into consideration and it is great place for networking.
Have you contributed to the industry specification? What is your experience?
Top comments (3)
hmm, I've never thought about attempting to contribute to a spec, but now that I've read this it's made me wonder what's involved in contributing to technology specs like HTML or JS's ES6 standard...
Anyone have any experience in this they could share?
That's an interesting way to put this. I've, for the most part, had my interest strictly on the product side, but I could see myself venturing into the technology realm in the future. This was a very enlightening post, thanks.
Thanks!
The distinction between product and technology, was an eye opener for me.
However, I must stress, that I am rather technology (very) early adopter than inventor.
It would be very interesting to see the perspective of the original inventor, and trace how ideas are created and forged into draft of the specification.