Reflections on iGEM 2016

This year was my third year to go to iGEM, the genetic engineering jamboree, and while my big news was the interlab study, in fact we had done most of the work on that in advance and as a result that occupied a relatively small portion of my weekend. Much more of my time was spent fulfilling my responsibilities as a judge, as well as parenting: this year I brought my daughter Harriet along, which was both awesome and challenging.

Harriet at the iGEM jamboree opening session

I also couldn't stay until the end, which I did on both of the previous occasions: the last day of the jamboree was Halloween, and at this age that's very important for me to be at home for. So I left Boston before dawn, and was lucky that my flight got in early enough for me to catch the awards ceremony on a cell-phone broadcast from one of the teams.

Reflecting back, this year was very different for me from my previous two experiences. The first time I went, in 2014, was the first interlab study, my first experience as an iGEM judge, and my first time speaking in front of an audience of thousands. Last year, in 2015, I spent much of my time in an electrifying deep partnership of data analysis with my colleague Markus, as we sorted out bit by bit what the interlab study was telling us, along with the drama of having one of the teams that I had judged becoming a winner of the contest as a whole.

This year was... unexceptional, and I should not complain.

iGEM is a beautiful and unique event, and I'm glad to support and be a part of it.  But I'm also a little bit sad to have experienced the expected regression to the mean.

Maturity, availability, pacing: the standards release process

The SBOL 2.1 update that I discussed recently had been in the works for nearly a year, practically since we released version 2.0.  Today I want to talk about why we released SBOL 2.0 at that time, when we already knew we'd be updating a bunch of things in SBOL 2.1.

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.

The Living Computing Project

Yesterday, I spent the whole day immersed in the engineering challenges of computing with living organisms. The occasion was an internal team workshop on the Living Computing Project, a really cool NSF-funded project involving a whole bunch of synthetic biologists at MIT and BU.

What makes this particular project so unique is that it's not tied to particular applications, but instead lets us really focus on the foundational questions of how to store, process, and communicate information inside of living cells. In this project, we get to build the engineering models and tools that will enable all sorts of different applications, and I get to play a sort of "metrics czar" role, integrating lots of different elements across the project as a whole, as well as connecting our work on the project with work being performed in other organizations.

We've been working on this project for nearly a year now, and in our meeting yesterday, I saw a number of places where things are really starting to gel intellectually. I'm excited to have people interested in getting their units right, and about getting precise and predictive models that can let us know right away whether something that we want to build is likely to be feasible and to go right to the designs we want. I'm also very excited about the potential in some of the biological devices that we are working on and with.

I like to have my research be applicable and have a clear use story. But sometimes, it's also nice to just be a engineering scientist and work on the tools we get to use in building those applications too. I'm happy that we're working with folks at NSF who share that vision and understanding, and have been willing to give us some rope to go and work on the foundations of the field.

iGEM 2016 Interlab Presentation Posted

For those who may be interested in more details about our highly successful fluorescent measurement experiment at this year's iGEM: I have now posted the slides that we presented at iGEM in the interlab workshop. These slides contain:

• details on the setup of the experiment
• a discussion of the problems that we encountered and lessons learned
• a sampler of the data and key results

The slides can be accessed at the top of the 2016 iGEM interlab page or via this direct link.

Complete details and raw data will be presented in the paper, once that is available. As of now, it still only just beginning to be written, but I will post news as it becomes available.

A few words on the election, as an American scientist

Although I usually stay strictly away from politics in my online (and thus professional) presence, there is an elephant in the room, and I need to address it before this blog goes back to my regular programming.

On the morning after the election, I had email from my European colleagues expressing sympathy and concern. Others wondered whether the declared plans of our incoming administration meant that organizing and attending conferences in the US was going to become problematic. To them I sent the reply that I feel best describes our situation in general at the moment:

Donald Trump has made a lot of promises, many of them frightening to many people, many of them contradictory, and some of them almost certainly impossible. The presumptive Republican leadership in Congress has done the same. What happens when they actually attempt to govern could go in a lot of different directions, some of them reasonable (even if likely to be things that I disagree with), some of them extremely dangerous and damaging to a large number of people, and some of them potentially existentially threatening to our civilization and possibly even our species. Whether you agreed or disagreed with Hillary Clinton's promises and plans, they certainly offered a much more predictable course than I see playing out before us now, and high degrees of uncertainty have serious dangers of their own, given our species' current technological capabilities.

As a citizen, I intend to take actions to try to ensure that my government effectively supports myself, my family, and every other person in our nation and on our planet, to grow and thrive and live long and stable lives in an environment of sympathy and positively chosen peace.  I also intend to make reasonable contingency plans in case some of the bad scenarios that I now see as more likely come to pass.

As a scientist and a professional, my intention is to continue to do my best to contribute in the areas where I have unique or rare skills, abilities, and insights. I will do my best to advise my government and will continue to choose subjects for research and development that I think are likely to have more benefit than not for humanity. Even as people were voting, I was submitting a proposal addressing a subject of potential great concern, and I hope that I will have a chance to execute on that and help to reduce some of the risks that I see out there.

The future is highly uncertain to me right now, and one of the truths that my scientific honesty impels me to acknowledge is that my personal choices and actions are unlikely to make a significant difference to our future, just the same as it was a week ago. Yesterday afternoon, my father and I walked together on a bed of fossils from and ancient sea floor, laid down 375 million years ago, talking about our lives and finding ancient corals, brachiopods, and sponges. Experiences like that are a valuable reminder to me that I am very small and have been here only a very short time. At the same time, as a student of complex and self-organizing systems, I know that individual choices do matter, and that the actions of individual people in networks can indeed have a major impact on the world in which we live.

My dear readers, I urge you to think carefully about your choices and actions, and to act with as much empathy and care for your fellow humans as you can, no matter who you supported, where you live, or what your political inclinations. I urge you this now, as I would have urged this before as well and will continue to do so no matter what may happen. It is only that now, in this time of great chance and uncertainty, that I feel impelled to do so publicly as well as personally.

SBOL version 2.1

Version 2.1 of the Synthetic Biology Open Language (SBOL version 2.1) has now been officially released, improving our means of representing biological designs. In addition to a bunch of little technical changes useful for implementation, the key changes with this release are:

• You can describe how the nature of a biological component changes when it's used as part of a larger design.
• It's simpler to mark up features of a design.
• We filled in a bunch of missing terms for describing interactions between components.
• You can describe the topology of components (e.g., circular vs. linear DNA)

I have some musings on the standards release process that I'd like to share later, but for now I just want to cheer and encourage people to update if they're using SBOL and consider adopting if they aren't yet.