Should small ISVs be involved with the standards process?

    This week I asked my employer to fund a trip to a standards meeting. The meeting is in the US, so it's a little expensive to attend, but it's an important meeting. The meeting is important because:

    • The standard in question has just had it's first version accepted by ISO
    • There are clear problems with that first version
    • I have a lot of expertise in the subject area (not to beat my own drum or anything, but I really do)
    • The standard has a lot of potential, if pushed in the right direction
    • The meeting is to discuss the future development of the standard, so this is the right time to do that pushing


    Update: I forgot to mention that the standard is also directly related to what we do.

    The proposal was met with sarcasm in the office. This raises an interesting question that I've been pondering overnight. I've been working on the assumption that small software companies should be part of the standards process, both because standards compliance is important, and because being an early implementor of these standards can make a big difference to the acceptance of your software.

    Then again, perhaps I've been wrong all this time. Should standards development be left to the customers, Microsoft, Adobe and so forth? Should a standard be about what the customer and large vendors want, not what is possible?

    I suspect that large vendors certainly use the standards process to produce standards they know are hard for their competitors to implement -- the ODMA specification is certainly an example of one specification written by a large vendor, which is fairly closely tailored to how their code internally works, and is therefore harder for everyone else to implement.

    So, are standards about the customer? Should they be used as a competitive tool? Whatcha think?

    Tags for this post: work(S)

posted at: 16:58 | path: /work | permanent link to this entry