I’m serving on the IEEE working group developing a standard for Open Source Project Governance! I’ve learned a few things about the process that might be of interest to others. Standards efforts kick off with what IEEE calls a ‘PAR’ — project authorization request. It’s essentially a scoping document submitted for review for the board, describing what such a standard might include. If the PAR is approved, effort shifts to building out the standard — and that’s where we’re at.

After a 2-hour kickoff in January, we did a two-day work session in February starting to sketch out what the various chapters of the standard will include, essentially expanding the 1-paragraph scope statement into lists of subtopics. Meanwhile, as with any group project, we’re doing a lot of work around tooling, sorting out how we’ll work together, and building our personal connections to one another.

My understanding — not speaking officially of course here — is that IEEE standards come in three essential flavors, which boil down to ‘Shall’, ‘Should’ and ‘May’. That is, does the standard say what a product/entity must do in order to be compliant (shall), does the standard offer specific and direct recommendations (should), or does it offer ideas about how a given entity might behave (may). The Open Source Project Governance Standard is to be in the ‘Should’ category: the intention is generally to offer direct recommendations about how projects are governed, not to create a compliance-oriented prescription or a series of reflections on current practice.

I don’t think any of these models are enacted in a pure way such that a shall document can’t contain a single should, etc., but the basic idea for this project is to navigate a middle ground where we’re not trying to tell everyone exactly what to do, but we are taking a position on what good governance looks like, with some flexibility for innovation and diverse perspectives. We might describe particular topics about which there should be rules (e.g. you should write down things like, how are decisions made? who gets access to what? how are problems resolved? how are security incidents to be handled?) as well as recommended approaches. However, it’s not all ‘should-ing’ — for example, although you must choose an open source license in order to be open source at all (and that’s a ‘shall’), we’re not in the business of saying which one to choose (and here the document could include examples, which turn out to be more like ‘may-s’).

My interest and engagement with the group is oriented toward making sure we’re able to reflect the best quality evidence from the academic community — which has done a great deal of research on the subject of what works and what outcomes look like. The working group includes a lot of people with a strong history working on open source subjects — including folks coming from a big-tech corporate perspective, from a legal perspective, from a community perspective. So far I am anticipating an excellent experience — it’s about an 18-month journey, I’ve been told, but I feel as if we’re (approximately?) the right people to take this journey together. Membership is still open (attend 2 meetings to obtain voting rights), and the still-emerging homepage is at https://sagroups.ieee.org/osspg/.