Open Software is often articulated as software that can be adapted – that is Open Source software. In the world of programming, this often includes some sense of collaboration where someone else, who is able to view and edit your code, is then able to make a suggestion on how to improve your program. Imagine you’re the author of a book, and for each new edition, you crowd sourced edits that your readers think will improve the story; new characters, different timelines, you name it!
We’ll get into the nitty gritty of different interpretations or implementations of open in the context of software shortly, but to start, the following CNBC news story, The Rise Of Open-Source Software (13:50), provides a high level overview of the history and future directions of Open Source Software.
With this underlying understanding of open software as adaptable, open source code, throughout this module we’re going to get more nuanced in exactly how we might interpret open and the impacts this can have on the research life cycle.
But first, in addition to adaptable code, when we talk about software that is open, we often call it free. Free is a very problematic term though. And we’d like to clarify the difference between free software, Free Software (with capitals), and Open Source software.
Although perhaps nothing in life is truly free, free software simply implies no financial transactions being needed in the acquisition of the software. Lots of software is ostensibly free; not all of it has its underlying code available to be adapted by anyone wishing to do so.
When we talk about Open Source software we’re describing the availability of the underlying code for people to edit, modify, and improve. This certainly does not imply that there is no price tag attached to said software. For example, some software is available free of charge for non-commercial use. Alternatively, some companies provide paid support contracts (with the software being free to use for those who do not wish to have access to customer support).
And finally, when we talk about Free Software, we’re describing a specific philosophical approach to the development and distribution of software that goes well beyond simple financial transactions and code adaptability. Free Software, in this latter sense, is defined by the ability of the user (you) to:
- Run the program as they wish;
- View the source code and modify how the program works;
- Redistribute the original program;
- Distribute modified versions of the program.
Differentiating free software and Open Source software from Free Software is often done, per the GNU philosophy, by suggesting that we’re not talking about free in the sense of “free beer”, but “free speech”.
Learn more about the GNU philosophy:
- The GNU articulation of Free Software: What is Free Software?
- The GNU on how Open Source and Free Software differ: Why Open Source misses the point of Free Software
- Founder of the GNU, Richard Stallman discusses the ethos behind and need for Free Software: Free software, free society: Richard Stallman at TEDxGeneva 2014 (13:39)
The Many Facets of Open in Open Software
Just as free can be interpreted differently in different contexts, so can the intent of open.
When we talk about open software supporting the research life cycle, we can think of three tiers of open:
- Software whose code is publicly available — that is, anyone can inspect and verify the code;
- Software that is open source licensed — that is, not only is the code public, it is available for people to edit, modify, reuse and improve; and
- Software that allows for creating human and machine interpretable content.
This last tier can seem like a bit of a leap if you’re used to working in programs like Microsoft Word and Excel, for example, to write and build visualizations like bar charts. We’ll look more in depth – and with examples – at what it means for the underlying structure of a document and its analysis to be both human and machine interpretable shortly. In the meantime, one example that you might already be familiar with, often used in Open Education, are Wikis. It is not uncommon for class research assignments to be built around editing existing pages on Wikipedia or even generating course-specific content on UBC’s Wiki. Wikis employ a flavour of markdown, a key tool in building human and machine readable content. More on this shortly!
Let’s briefly recap
Open software can be interpreted by its price tag, the sharing of its underlying source code, and the philosophy that underpins how it should be used and distributed. In short, open source does not equal free, nor does closed source equal paid. And open source can come with many restrictions that Free Software should not.
In supporting transparency in the research process, a key element of open software includes using tools that enable human and machine interpretable content so that even if a particular piece of software is no longer available, a human should still be able to understand what the intent of the code was.
In the scholarship of teaching and learning, engaging in open platforms is just as important as it is in traditional research.
A note on licensing
The above largely speaks to how software is developed and / or interacted with by the user and developers. If you are creating software and want to make it available for others to use, there are several standard licenses available to choose from. Understanding licensing is crucial if you intend to get into the world of modifying existing open source code yourself, or you wish to use another open source project as part of your work. Unfortunately – or fortunately depending on how you feel about this! – the nuanced details of whether various licenses are compatible with each other is beyond the scope of this module.
If you wish to take a bit of a diversion and learn about software licensing, check out the following:
- Introductory post from Free Code Camp on open source licenses
- A bit more information from Opensource.com
- And a 200 page book on open source and free software licenses for those wanting the full story
- Are you interested in applying an open source license to something you created? If so, explore your workplace’s intellectual property policies. At UBC this LR11