I wrote a blog post about looking back, and I have a bit of snark in there where I talk about slowing down the future. I wanted to explain this a bit more and give everyone some food for thought around how we used to do things and how we should do them moving forward. There are groups and people that exist to slow things down. Sometimes that’s on purpose for good reasons, sometimes it’s on purpose for bad reasons, sometimes it’s not on purpose at all.
I want to start with the idea that a lot of standards are there to slow us down on purpose. This isn’t meant to be a hot take, this is the actual truth and it’s a good thing. Standards exist to help everyone work together. If standards change too quickly it creates barriers instead of opportunities. Imagine if HTTP or TCP/IP changed drastically every year. It would be horrible, the internet wouldn’t look anything like it does today.
Now, there are times when slow change is the opposite of what we want to do. Emerging technologies are a great example of this. Imagine if the Linux Kernel API changes had to pass a standards committee. There would be no progress, development would grind to a halt and nobody would want to contribute to such a project. The project wouldn’t be the success it is today.
There are some standards groups where being slow actually helps progress, and there are some groups that hurt progress by moving slowly. For the purpose of this blog post, let’s focus on new technologies. New technology needs to move fast and iterate without a committee telling them what to do. New technologies should work more like an open source project to move forward. In the world of open source it’s easier to build an example then talk about what the example does. The work is fast and the work itself is the discussion. This model has mostly taken over the world. It is fast, open, and makes it easy to help.
What does this have to do with standards?
Every now and then I get invited to a meeting for a standards group, usually having something to do with open source security, and ever time it ends the same. It’s the same people saying the same things they’ve been saying for decades, and most of those ideas didn’t work back then either. There is little progress because the solution to most problems seems to “committee harder”. I have a suspicion two hours of building a prototype is worth two months of these meetings.
There are problems can’t be solved by a committee when the committee moves slower than reality. You’re actually moving backwards in relation to the world around you. Consider the case where you’re rowing a boat against the current in a river. If you’re rowing slower than the river is flowing, you’re not making progress. You’re moving backwards, just slightly less slowly than not rowing at all.
How does progress work in the open source world? Progress in the open source world gets done because someone does it. It doesn’t get done because a committee talks about the problem and solution for months. There are things that move forward because someone does the work. You try a solution, if it doesn’t work you iterate on it a bit and try again. Eventually something that works emerges. I am aware there are counter examples to this, by all means, Tweet them at me.
BUT NO CIVILIZED SOCIETY CAN WORK THIS WAY! You shout. Sometimes it shouldn’t (mentioned that above). But there are many many examples against this today. Successful open source isn’t built on top of committees. Successful open source is built on top of community.
I have two example that show off both sides of this universe.
First if we look at all the source composition scanners that exist, we can see a lot of progress. I’ve written at length about the quality of these scanners (spoiler: it’s not good), but fundamentally they are getting better and will keep getting better. There is no standardization at the moment which does create some challenges as a user, but given how new this technology is nobody really knows what it will look like in a year, I’d rather see them move fast and get better. Trying to standardize this would stifle progress at a time when progress is hugely important.
But as a related counterexample I want to pick on security vulnerability identifiers. CWE is very much a committee driven, boat. Anyone who knows how CWE works understands it’s not moving fast enough in the modern world. CWE is paddling against the current, but it’s not paddling fast enough. I have a previous post where I look at some CWE details, it’s pretty clear it needs some updating.
I think a huge reason we don’t see much progress in this space is because there is more talking than work. It’s possible nobody will ever do the work because it’s not very exciting. There are just certain things that struggle to exist as open source projects.
The next obvious question is how do we decide if our project should be a committee or a community? I think if you have to ask the question you should start with a community. It’s probably going to be a lot easier to transition from a community to a committee than the other way around. I also have a suspicion the future will be communities, even for slow moving things. It takes reality time to catch up sometimes.
So how do you start a community instead of a committee? Committees are mostly driven from meetings, communities are not. If your group has a lot of meetings and not a lot of work (meetings are not work), then you have a committee. If you have almost no meetings, many public discussions, and a lot of git commits - you have a community.
The purpose of this post is really about setting expectations for the future. If you’re looking to change the future, a committee isn’t going to do it. What will change the future is something that looks like an open source project driven by community collaboration. Open source won for a reason. It doesn’t just work better, it is better.