This is going to be my personal perspective on open source, and hopefully encouragement for you to get involved with Hacktoberfest, a month-long event encouraging participation and coding, which the RSE Team at the University of Sheffield are supporting. I hope to introduce some of the legal, technical, economic and academic aspects of open source – providing context for experts and a gateway for the newly interested. Note: I have no legal training, consult someone who does if you need to! But, my perspective, so we’re going back to when I was first exposed to open source, back around the millennium…
Open source was an ideological battleground. Really. The dotcom bubble had burst. Everyone had a phone, but no-one had a smartphone. If you accessed the internet is was almost certainly via a PC or laptop running Microsoft Windows.
People were beginning to realise that the internet could be used to transfer music, games and videos at scale, but there were few paid ways of doing this, so using a peer file sharing network to illegally download was increasingly commonplace. People felt OK about this, as they saw themselves as were depriving large corporations of small amounts of revenue. Said large corporations took a different stance – peer sharing was going to destroy all music, much as home taping had a generation before. Why am I banging on about this? Copyright. In much of the world, if you produce some music, or some text, or some code, for a period of time no-one is allowed to copy it without your permission. This right is something you can sell. And while copyright was something the peer-sharers ignored, it is a pillar of open source software, as we shall see.
While record labels and movie producers were worried about file sharing, some large software companies were worried about something else: open source software. Their model was to keep the source code to their products secret, to stop people from copying it. They would sell compiled versions of their software in which the source code was effectively hidden. Copyright, secrecy and licensing were what prevented their products being cheaply duplicated. Open source software, chiefly the Linux operating system, was beginning to subvert this model. Without copying the (copyright-protected) source code, software was emerging that had similar features to closed-source products, but licensed differently. Closed-source software is typically sold to you with a license which says you can’t copy it and give it to someone else. Open source software is licensed under a couple of broad categories:
We find that, practically, the former work better where there are lots of volunteer contributors and the latter where there is private sector backing. Another ideological battleground. https://choosealicense.com/ is a good source for more information.
If you make your code open source, you do this using your copyright - code without a copyright notice and / or license does not revert to being free to copy, it just means we don’t know who owns the copyright and what they’ll allow!
So what do you do if you have a monopoly on some software and some undermines this by giving a similar thing away for free? Patents are a legal avenue to stop others from copying an invention. It has been argued that aspects of software are inventions and can thus be patented, or that the law should change such that they could be. We were a bit terrified that every time we wanted to include say, a menu bar, in a GUI, we’d need the permission of whoever held the patent. The rules on this, it turns out, vary around the world, and the stuff we felt threatened by in the U.K. never really came to be.
Software businesses, large and small, are still a huge part of everyone’s lives. However, there is now something of a symbiosis between closed and open, commercial and free. The perspective of a software entrepreneur I spoke to was that open source gives developers all of the core stuff they need (e.g. menu bars, web servers, programming languages) to operate and innovate without a requirement to reinvent the wheel. I get this perspective - it explains a lot of the pro-open source behaviour of big companies.
In research, open source software means that we often get great software pretty much for free and we can fully articulate the steps we take in coming to our conclusions, rendering our research open and reproducible. I was once told by a closed-source software vendor that specifying the version of their product used to process my images was sufficient to make my paper open and reproducible in this regard. Rubbish. We need to be able to point to the source code (and data), and publishers and funders are increasingly demanding this.
So while this is great, in principle, these benefits need to be available to more than just the open source in-crowd. Opening up research software and data can be daunting and time consuming, it requires skills we might not have. I did not do always do an exemplary job of this in my research career! Research Software Engineering seeks to assist with this, as best we can. Events like Hackotberfest and ReproHacks are ways we hope we can do this.
Would you like to be more involved in open source software as a means of helping with your research practise, getting better at coding or just contibuting to a good project?
Hacktoberfest is nearly upon us and is a chance to get involved with contributing to open source. If you’re new to this then it will offer support, if your a gnarly veteran developer, it will create time for you to work on projects that matter. And an opportunity for all to get a free T-shirt - I didn’t get one last year, the regret… If you run an open source project, it’s an opportunity to get some input to help.
We also have a Google chat room open throughout October for peer support.
For queries relating to collaborating with the RSE team on projects: rse@sheffield.ac.uk
Information and access to JADE II and Bede.
Join our mailing list so as to be notified when we advertise talks and workshops by subscribing to this Google Group.
Queries regarding free research computing support/guidance should be raised via our Code clinic or directed to the University IT helpdesk.