‘Go for it,’ says Julian Kunkel, Committee Member at Large for the Open Source specialist group, as he discusses why we should all think about contributing to a collaborative project. ‘Just get engaged with the people on the team. It could be just writing and saying “this project is great… it’s wonderful,” or you can contact the team and ask about adding a new feature. Just get involved. Communicate.’
Beyond a clear passion for open source, Kunkel gives another reason why developers should think about getting involved in a project. ‘Think about employability,’ he says. ‘A lot of employers look at open platforms like GitHub and see, maybe, you’ve contributed to ten projects. They see you can collaborate. This is a key attribute for a productive programmer. For developers, it’s a real benefit. Be open about your contributions to open source.’
No longer the underground
By day, Kunkel is a lecturer at the University of Reading and worked previously at the German Climate Centre. He started using Linux and open source software nearly 20 years ago.
‘I came to the UK about a year ago and contacted the Open Source SG,’ he recalls. ‘I was really enthusiastic. We have about 1,450 members and have monthly meetings in London and at remote locations. It’s the biggest open source group in the UK.’
The SG’s size and vibrancy, in many ways, reflects open source’s growth, scale and prominence on the tech stage. Gone are the days, for example, when Microsoft’s Steve Ballmer infamously called open source a cancer.
At the turn of the century, Linux was viewed, by some, as merely the idealistic product of a global ragtag programming collective. Open source was from - and for - the underground. It was counterculture, whereas Microsoft was mainstream and serious.
Behind the big names
Today, if you peel back the layers of almost any technology or tool – the internet and cloud included – you won’t have to look hard or far to find code that is open and was created collaboratively. Android, for example, is the world’s most popular mobile operating system and it’s open source – you can download the code, update it and make it your own. You can contribute to its evolution.
Indeed, at the time of writing, Microsoft – once the doyen of closed source software – announced that it would be including a Linux kernel in Windows 10. Thanks to a tectonic shift in software development, culture and attitudes, you’ll soon be able to run Linux binaries on a Windows machine. 20 years ago, this would have been as unthinkable and unimaginable as the rise of the iPhone.
‘As a consumer, you see a lot of benefits when you’re offered open source,’ Kunkel says. ‘There are lots of reasons why open source has become so prominent. Jim Zemlin, the Linux Foundation’s executive director, said “shared development is enabling faster development with higher quality and lower costs.” With open source, you share the cost of developing software - why have three competing proprietary versions? Why not just have one?’
Open source works really well when software isn’t a key differentiator – if it’s something you must have but it’s not really the product your customer wants. Compilers illustrate this point well: ‘a chip vendor must have a good compiler, or they can’t sell at all,’ Kunkel explains. ‘But they don’t sell more chips because they have a slightly better compiler.’
Many advantages
Because of its open nature and collaborative creation, open source projects and products also offer more longevity and dependability than closed source software. In the closed source world, if a vendor sees a product isn’t generating revenue or has become unfashionable, they’ll stop developing it. They may even stop selling it. If it’s essential to your business, this could be a real problem. In the open source world however, you could take the source code and carry on improving the product yourself, or maybe another team will ‘fork’ the code and it’ll live on.
There’s also a very strong link with agile. ‘Assume you have a new idea,’ Kunkel says. ‘In open source, you’ll find most of the algorithms. So, rather than building everything from scratch, you can take the existing libraries and the existing expertise; you’ll find 90 percent of what you need and then only need to create that final 10 percent. That makes product development much quicker. You’ll also probably find there are lots of different open source products that tackle your problem in a slightly different way. Maybe you could take one of those and contribute to it.’
Considering a bug or a limitation in a closed source piece of software further explains how open source can speed up delivery and the creation of a minimum viable product. ‘Imagine you’re making software for an ATM,’ Kunkel says, ‘and your closed source software won’t let you do something. You can’t change the software. You’ve got to spend time convincing the vendor to make a change. It’s slow. You could write everything yourself, but you’d have to invest so much, you’d never make any profit. If you take open source software, you can make the changes; you submit those changes and if everybody does the same, the product gets better over time.’
This, of course, begs a question: what would happen to open source if people just took code and libraries and didn’t give anything back? ‘Sure, this is a problem,’ Kunkel admits, ‘but the worry about people leaching from you and your work shouldn’t deter contributors.’
The contribution model
Kunkel points to Wikipedia as a means of understanding the dynamics of contributing. Before Wikipedia existed, encyclopaedias were either shelf-long leather-bound tomes or, later on, Encarta CDs from Microsoft. The point is, encyclopaedias were closed source. Wikipedia allowed everybody to contribute information and the online open source knowledge repository became one of the internet’s biggest sites.
Part of Wikipedia’s success can be attributed to how easy it made contributing. The barriers preventing you from adding your voice were, and still are, low. In the world of software development, they are, of course, set much higher. You need to able to code, for example. But open source project owners can encourage collaboration like Wikipedia, by lowering the barriers to collaboration. They can make their code easy to understand and ensure it’s well documented.
‘This means people, if you find a bug, you can look at the code, understand it and in, say, an hour, commit a fix to GitHub. If you have a product that is very crudely coded, people will turn away,’ Kunkel explains.
In a way, vibrant and lively open source software compels people to contribute, too. Over time, a product naturally gets better as people contribute code and ideas. And naturally, you’ll want to use the latest codebase. If you don’t submit your improvements – if you keep them to yourself – you’ll have to make the same amendments every time you draw new code from a repository. ‘This is very inefficient,’ he says. ‘Why not just commit your changes to the main project and save yourself – and others - some time? And, of course, your changes and improvements are maintained and potentially improved further by other contributors.’
Generating revenue
Continuing to discuss the idea of taking but not giving, Kunkel says: ‘It’s when you give back that you start to reap the benefits. Others become willing to contribute to your areas of interest, you get support in the community, which are typically your customers. That sort of market credibility is hard to buy. IBM used to reckon for every $1 of software they contributed, they got it back.’
But what about money? How do open source projects generate revenue? To explain, Kunkel points to the art software project Gimp: ‘It’s run for 20 years and more,’ he says. ‘I’m not aware of anybody who makes money directly from it, but people do make money by selling the images they create using it. So, by using the software I, as an artist, make money. At some point I might say: “I need a feature. I need a feature to make even more money. How do I get it?” I could become a developer and support the product directly, or I can buy my support. The software is valuable because it creates value.’
To generate revenue, some projects carry advertising, while other open source teams build additional features which users are asked to pay for. ‘You start with an open source version, but if you want to use the license commercially, you may have to pay for it,’ he says. ‘Or if you want certain features, you pay for it. Technical support is another means of generating revenue. You get the software for free but buy your support.’
Finally, Kunkel returns to his opening call to action – contributing is much easier than you think. ‘Projects need people who test,’ he says. ‘They need people who give feedback. If you find a bug in an open source project, go to GitHub or wherever its source is hosted and report it. That’s the first step of contributing. Or you can say something is wrong with the documentation. You don’t have to be a programmer. You can add something to the documentation. If you find something, give it back to the community.’
