Since the #Heartbleed bug only affected an open source library some pudits are having quite the field day:

You see, Opensource isn’t working! Where were all the eyeballs checking the code?

While this strawman argument is obviously only useful as clickbait, the heartbleed case does show us quite a big problem many opensource projects have: The opensource community focuses too much on coders.

Every project could probably use more contributors working on code, implementing new features, polishing etc. But is code really all that a project needs? Especially when coming from mind-numbing corporate jobs people in the opensource community tend to look down on the idea of project managers: They want their Gantt-Charts and milestones and all just to make people’s lives harder. So projects adopt “no formal management” structures. No managers, no formal responsibilities, no overhead. We know what we are doing here, right?

But when you neglect to define roles in your project, when you neglect to define processes, you don’t abolish those things. You just made them intransparent and implicit (cough meritocracy cough) forfeiting a chance to design and implement processes and roles that actually help your project get its work done.

I believe that this notion has a lot to do with Nerd Pride, the idea that the nerd skills and interests are so much more important and profound than all the other things in the world, the idea that “social”, “management”, “organizational” or even “political” skills are just less valid. How often have you seen people call those areas “not real science” or “no actual work”? And don’t get me started on the whole gender bias thing there devaluing all those perceived “female” skillsets in contrast to the real “male” work.

Heartbleed is a bug. Actually not a terribly complex one (when you know where to look). So how come the project didn’t find it? I think there are two important factors here: Money and project management.

Code audits and review often suck, especially if the codebase has rotted somewhat. It’s nothing you work on for fun. You might touch it with a ten-foot pole if someone pays you to do it though. Opensource has largely failed to create structures allowing that kind of money to be collected and distributed. Sometimes companies such as Google, RedHat or someone similar carry some of the load but that’s not a robust structure, that’s playing the money lottery and hoping some critical infrastructure wins.

OpenSSL, the project that the heartbleed bug came from, has a code base known for its … less than stellar quality. It’s also known for lacking useful documentation so everybody basically copies some code of other projects that seems to work or pokes the OpenSSL library or tools until they seem to give up and release the relevant information. And this is a problem of project management.

If all you want are coders, who is going to write documentation? Who is going to communicate with the people using your library in order to find out what doesn’t work properly? The coders are drowning in coding work and the whole “non-coding stuff” always gets cast aside. In a healthy project that can be fixed by having other people building documentation: If the documentation work is respected, questions emerging from trying to document code and usage will lead to developers explaining (and automatically reviewing and probably fixing) code paths. Cleaning them up so they don’t have to explain so much. A healthy project can build consensus about collaboratively cleaning parts of the code up (something individuals are not easy to motivate for): Sharing the “suffering” can even be a great teambuilding exercise.

Opensource is no silver bullet. That phrase sounds as tautologic as bullshit-bingo-esque but it also happens to be true. Opensource provides the potential for building a robust structure for building better, more secure code. But that doesn’t happen by just throwing stuff up on Github and getting some patches in. You need to establish process, not just for how code gets merged and by whom, but also for how communication is supposed to work, how your plan looks like and how you document your stuff. Fully.

I think we need to learn two things here:

We need to find ways to fund the annoying tasks such as code audits for critical infrastructure. We need to accept that the “non-coding” part of our projects is just as important as the coding part. Code that passes all tests but has no human-oriented documentation is broken. Lack of documentation for features, your own processes and responsibilities is not “some oversight”. It’s a bug, and it’s a critical one at that.

Opensource is still the way to go. While some closed source projects might easier get the funds for audits and code review, we have seen over and over again (see Apple’s recent “Goto Fail” bug for example) how companies do not patch the proprietary stuff. Cause they already sold their product and support is always just annoying extra cost.

But in order to let opensource reach its potential, live up to the promise that open code leads to better code, more robust code, we need to stop ignoring what engineers in other domains have been doing for years and decades: We need to build good transparent processes. We need to document them, share them, adapt them to our needs. Project structures are just like code: They can be forked, copied, merged, fixed and deployed. We just need to start.

Strong structures are better than strong people. It’s awesome to have great, smart, efficient people. But putting the health and future of a project on their shoulders is just a recipe for disaster. Programming skills don’t always come with people skills, with organizational skills, with communication skills. We are weakening our projects by presupposing that the people who came up with the basic idea also magically know how to scale a project up and involve the relevant stakeholders to move it forward.

If your project is used by a handful of people, do your thing and nobody cares. If your project is critical infrastructure, if it has hundreds of not thousands or millions of users, it’s time to grow up. Get new people in, not just coders: Get people to communicate for the project, restructure how things work, create plans and documentation. Don’t forget people who keep a project healthy. People who just gather a feeling for what’s going on, who can moderate conflicts, who find the right picture of sloths when tensions and stress grow. As a bonus, it will be way easier for new coders to get involved.

All those different skills together, with more ways to get money and other resources dispatched, can make the opensource promise actually mean something.

Liked it? Take a second to support tante on Patreon!