The making of open-source software

Open-source software is used by millions, but many surfing with Firefox, typing into LibreOffice or loading Ubuntu onto their PCs have no idea how those programs were created.

It’s ironic, given open-source development is entirely transparent: every change is discussed in public, every commitment documented for posterity, and future plans laid out for all to see.

However, to those outside the community of contributors, the gauntlet of mailing lists, project-specific jargon and organised chaos that marks open-source projects can make the entire process rather mysterious.

The notion of a software program undergoing phases, like a car in a car factory, is from earlier centuries

How does an army of volunteers combine to create a fully functioning product, and who are all these contributors?

We spoke to experts from Mozilla, Red Hat, Canonical and The Document Foundation to find out how their projects work – and how anyone can get involved, even if you don’t know how to code.

The open idea

While it may seem that way to outsiders, open source isn’t about taking advantage of people’s passion to get free labour.

The community-run system is different to traditional proprietary models, with a more collaborative, iterative approach to writing code, with everyone discussing what to do next and working on their own passion.

“The notion of a software program undergoing phases, like a car in a car factory, is from earlier centuries,” says Thorsten Behrens, who helped co-found The Document Foundation, which develops OpenOffice fork LibreOffice.

“Especially for free software projects with strong volunteer participation, all of this happens pretty much concurrently – some people write code, some produce binaries, some test, and some apply finishing touches, such as updating artwork or writing help text.

“While this may appear chaotic, in practice it works well, and it caters for the contribution patterns common around volunteer work – people invest time quasi-randomly, and asynchronously,” he says. “Successful free software projects therefore enable people to work at anytime, anywhere – not only when a project plan says ‘now is testing’.

“Typically, projects aren’t centrally managed, but driven by a multitude of interests. In general, though, the broad vision is shared. Individual contributors work on their individual problems – and since they share a vision, the emergent behaviour is that the project evolves into a certain direction.”

Buggy beginnings

In practice, that leads to a decentralised development model requiring incredible amounts of collaboration, communication and organisation. The one aspect all projects have in common is discussion, be it over IRC, mailing lists, social media or at conferences, as code is tweaked, checked and rechecked.

For some, the work starts via a bug reporting system. Making a change in Ubuntu or Firefox begins in the same place: finding a flaw. That might be a bug, a missing feature or a UI irritation.

“If somebody is annoyed with the interface of a browser – for example, they think the URL bar is too long – they go to the help section,” says Chris Heilmann, principal developer evangelist at Mozilla.

From there, someone from the team will say: “why don’t you make a screenshot of what you think it should be, and then we’ll send it through the team and discuss it on the mailing lists that we have, and we’ll see if it can be done?”