Investing and Being Invested in Standards

Posted by halindrome at 12:00 PM on Mar 31, 2016

Share:

Earlier today there was a discussion about an (embryonic) standard, and whether the people who were proposing it were properly invested in it. Did they really have a commitment to the work? Were they going to dedicate staff to getting it done? Obviously, this strikes close to home for us at Spec-Ops. And it raises a critical point about what it means to commit to participating in a working group. After 30+ years of doing this, I have enough empirical data that I can offer some insight.

There are a number of things you need to have success when creating a standard:

  • Extant industry experience - standards are (usually and most easily) defined when a problem and its solution space are relatively well understood.
  • Involvement of the constituents - designing a standard when the consumers of that standard are not in the room is doomed.
  • Productive involvement of the vendors - participation of the people who are expected to deliver standards-based solutions helps speed adoption.

In addition to these, there are things that you need whilst developing a standard:

  • Horizontal coordination among related work / disciplines.
  • Marketing / socialization work to help ensure that everyone who needs to be involved has the opportunity to do so.
  • Dedicated editing resources.
  • Dedicated testing resources.
  • Dedicated implementation resources.

In professional standard development organizations (SDOs) the first 2 items above are (and should be) provided by staff resources. They understand the process and they know the players. They have access to the members. They are also rather thin on the ground. Most SDOs are involved in a lot of different activities, and their staff are pulled in a ton of directions. And not just on current work. Staff end up maintaining the existing, stable work long after the original group has disbanded.

The other items are typically NOT provided by SDO staff. Sometimes a staff person will assist with editing, but rarely implementation or testing. In general all of these tasks rightly fall to the members. Unfortunately, all too often the member companies assign staff to working groups who are experts and can represent the member's positions, but do not have the available hours to dedicate to doing much more than the weekly meetings and keeping up with emails. Editing is hard. So is writing tests. It takes lots of time. It also requires some domain expertise that is not always in the bailiwick of the member-provided people. Just because you are an expert on protocols doesn't mean you know how to write automated protocol tests, for example.

Moreover, and this is an ugly reality, when it comes to dedicating the required resources to an activity, only the members with really, really deep pockets can do so. A company with 20 employees is going to have a hard time allocating 50% of a person to an SDO for 2 years while a standard matures. A company with 20,000? Less of a hardship. This has the unfortunate effect that the larger member companies end up 1) shouldering the bulk of the burden, and 2) with significantly more influence than smaller companies. It can also have a couple of unintended consequences:

  • Organizations and individuals become bottlenecks for progress of a standard because they are the primary mover and get distracted,
  • Standards that don't necessarily require and therefore attract members with lots of available staff progress more slowly because they are resource starved,
  • Smaller members are discouraged because of their perceived lack of influence,
  • and/or countless hours are supplied by volunteers who are in it because they believe.

So, getting to the point. Obviously I disagree with the contention that an organization has to have experts they can basically assign to an SDO in order to really be committed to a standard and its development. Smaller organizations cannot spare the staff. Consumers of a standard might be invested, but don't have implementation or testing experience. Please don't write off new (or existing) work because the participants are exploring different ways to get that work done *within* the framework of an SDO. There are different ways to demonstrate committment. And there are different sorts of experts that are required for these efforts. Pooling resources to help fund a part-time SDO staff person, or an editor, or test authors, is an additional way to put skin in the game. It's a different model than we are used to. It's obviously a model that we at Spec-Ops are excited to implement. Moreover, it is what I and countless others have been doing for decades. Helping find and/or act as the resources that are needed to progress critical standards. Making sure the little guy has a voice. Ensuring that independent implementations are not precluded by the standard, that no one is disenfranchised, and that the tests are extensive enough that independent implementations are more likely to be interoperable. That's good for everyone.

- Shane McCarron

Projects Manager, Spec-Ops