One of things that I've observed happens with standards, like any big project, is that there's always a lot of different changes in progress at different levels of maturity. This isn't a problem, but rather a sign of a healthy and growing area of work, where there are a lot of participants with different and evolving needs. This puts a three-way tension into development, between maturity, availability, and pacing:
- Maturity: the more polished and well-featured a standard, the better that it will serve its users.
- Availability: something that isn't approved and released doesn't actually serve anybody.
- Pacing: unlike a phone app or a web service, which can resolve maturity vs. availability with constant updates, a standard's users are tool developers, and every time we make a new release, we make new work for them.
Given this three-way dilemma, the best thing for us to do seems to be to set some sort of relatively regular schedule on which we plan our releases. We've got something of a natural pacing for this as a community, since there are SBOL workshops twice a year. There are always discussions going on in the community, on its mailing lists, between individual developers, amongst the leadership, etc. At the workshops, the issues raised and the details of proposed solutions get hammered out in more detail, and it there's clear progression toward consensus, these new steps forward can be formally adopted and written into the standard.
About once every six months, then, we're in a good position to assess whether there has been significant enough progress to plan for a new release. Then, when we've decided we need to make a release, every one of those changes-in-progress ends up going through a triage process, where we try to figure out if it's mature enough to actually get put into this particular release or if it needs to get deferred to the next one. Again, maturity versus availability: we end up with a push and pull back and forth between the desire to get more of these corrections and improvements in versus the need to actually make a release so that people can start officially using the things that are already finished.
So when we released SBOL 2.0, back in the summer of 2015, we weren't saying "the standard is done," but "the standard is good enough that we think it will be valuable for a lot of people." And part of making it valuable is actually deciding what to exclude, because including something that's not well developed is inviting problems, incompatibilities, and frustration in developers and users.
Instead, all of that stuff that we know we need to finish, or argue about, or even just plain contemplate, has ended up as issues in our online tracker. Over the next year, members of the community worked on some, argued about some, and ignored others, and over the course of a couple of workshops, we got to the point where SBOL 2.1 made sense---and found a nice external deadline as a forcing function too, which was also useful.
Now SBOL 2.1 is out, and after a short refractory period, the process has continued. People need to talk about permutations and combinations of DNA, circular pieces of DNA raise new and different ambiguities to resolve, nobody's really quite comfortable with certain things about proteins, and so on and on and on and on. Step by grinding little step, we'll work our way to SBOL 2.2, helping to work out these problems of description and communication that people from all around the synthetic biology community are dealing with. Maturity, availability, pacing, and an open invitation for more to join us in the work.