Week 1
Defining Open Source. What Exactly Is It?
I remember hearing throughout my undergraduate computer science degree that there are certain things all students should do if they want a cushy job as a software engineer right out of school.
Get good grades. Learn data structures and algorithms. Get an internship. Go to hackathons. Have nice projects on Github. Contribute to open source.
All seemed very straightforward, except, of course, for the last one. That seemed scary. I remember thinking of ways to get around it. Maybe I could start my OWN open source project, I thought. Isn’t that better than contributing to an existing one?
This line of reasoning would lead to a very similar very sad cycle: I would put up a small app on my github, decree it to be open source in the readme, only to take it down a day later, hoping nobody saw it. So embarrassing.
Now looking back on it, I was definitely scared to be a part of the open source community. I do now realize, of course, it is not scary at all.
What alleviated that fear was just understanding what open source is (and is not). I think more students would feel brave enough to contribute to open source if they understood what exactly it is.
That is what motivated this article to hopefully shed some light on that confusion.
So what is open source after all? It is actually very simple. The Open Source Initiative defines it as software that has ‘ [a license] that complies with the Open Source Definition — in brief, [it allows] software to be freely used, modified, and shared.’
So what is this ‘Open Source Definition?’ As I was reading it, it sounded very technical. I admittedly had to re-read each bullet point multiple times before I fully grasped what each meant. I summarized them so you wouldn’t have to. However, if you are curious (or rightfully skeptical of my legal skills), feel free to take a look yourself here:
To fit the definition, software must contain a license that meets these requirements:
-
Free Redistribution. If software is open source, it can’t receive money if someone uses it in a larger commercial system. An example of this is using Python, an open source programming language, in a business application. The community that owns the license for Python cannot charge royalties to the enterprise, regardless of how much money they make using their open source software.
-
Source Code. The source code must be readily available for open source software. It also must be compilable (buildable and runnable) by the person who downloads the source code. It also can’t cost the user lots of money to receive the source code. An example of this is that I can easily download the source code for Audacity (an open source music application), and run it in any system that can compile/ run C++
-
Derived Works. Developers can modify the software and then redistribute it under the same license. An example of this is someone modifying the Linux operating system to make a new Linux flavor.
-
Integrity of The Author’s Source Code. Developers can restrict modification of their software. This restriction must be explicit in the license. It could require, perhaps, modifications with different version numbers or names. However, build time patches to add user defined functionality need to be allowed for this software to remain open source.
-
No Discrimination Against Persons or Groups. Pretty self explanatory. Open source software can not be available to certain groups and not available to others.
-
No Discrimination Against Fields Of Endeavor. Open source software can’t discriminate from a particular use of the software. This use could be in a certain industry or sector of the economy. As in the agriculture sector can not use this software.
-
Distribution of License. The rights attached to the open source software don’t have to be re-added after re-distribution. For example, if someone re-distributes NodeJs within an enterprise application, the old license for NodeJs doesn’t have to be re-added by the enterprise. It must be there by default.
-
License Must Not Be Specific to a Product.Open source software can’t be tied to whatever was in the original package. For example, if a particular component of Python is usable in some other competing open source programming language, the rights to that particular area of Python can’t be any different from the entire Python codebase.
-
License Must Not Restrict Other Software. The software can’t ask anything of the other software it is packaged with. For example, Python can’t say that if you use Python the entire app must also be open source.
-
License Must be Technology Neutral. Open source software can’t say, for example, this can only be run on embedded systems. It must be able to be run on any interface without discrimination.
I found these set of guidelines very clear in what open source software is. It is software that contains a very specific license. This license allows for distributed collaboration in a safe and controlled way. What surprised me more was discovering what it is not.
To understand that, a brief history from gnu.org (advocated of the ‘free software’ movement) about how open source development began:
“In 1998, a part of the free software community splintered off and began campaigning in the name of “open source.” The term was originally proposed to avoid a possible misunderstanding of the term “free software,” but it soon became associated with philosophical views quite different from those of the free software movement. Some of the supporters of open source considered the term a “marketing campaign for free software,” which would appeal to business executives by highlighting the software’s practical benefits, while not raising issues of right and wrong that they might not like to hear. Other supporters flatly rejected the free software movement’s ethical and social values. Whichever their views, when campaigning for open source, they neither cited nor advocated those values. The term “open source” quickly became associated with ideas and arguments based only on practical values, such as making or having powerful, reliable software. Most of the supporters of open source have come to it since then, and they make the same association.”
Open source, surprisingly, had its root in practicality and not in ethical reasoning. In fact, the main reason it splintered off from it’s parent movement was because of the emphasis on development rather then ethics.
This surprised me because I always associated the collaborative spirit of open source as helping the world by contributing your skills to make things easier for others. I always thought it was rooted in ethics, and not practicality.
So what are these ethics? They are comprised of four essential freedoms:
- The freedom to run the program as you wish, for any purpose (freedom 0).
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help others (freedom 2).
- The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
But wait! Doesn’t that sound a lot like open source? Yes, all free software is open source but open source has a looser criteria. The real difference is the philosophical standpoint between the two. Free software (as in free speech, not free beer) is focused on the freedom of users to do as they wish with the software. People who want software to be free (once again, not zero dollars, but in conjecture with human rights) believe not having these four freedoms places users in a powerless position to developers, which is a violation of their rights. They believe that developers are causing harm to us in the form of proprietary software.
An advocate of free software might give an example, that a car company that cheated on emission tests (like Volkswaggen’s emission scandle ) is violating our rights by not letting us see their source code. If we could see the source code, they argue, that scandal couldn’t have happened.
An advocate of open source may instead argue that it is a more efficient development methodology (Linux is better than Windows, they may say) and that it allows people or companies to show off their skills for a better reputation.
As you can see, although most open source projects are also free (by the definition given by gnu.org) they have very different ways of looking at software development. So if you are not interested in community service for the sake of it, remember open source is nothing more or less then another way to write software, collaborate, and learn. Or if you are into community service, and agree with gnu’s definition of freedom, contributing to open source is usually a means to improving free software. Either way, knowing that what open source software is helped me be brave enough to contribute, and I hope it has the same effect on you.
Weekly contributions
This being my first contribution, I wanted to ease in slowly. Contributing a bunch of code to some huge open source project seemed a little extreme, with a high likelihood of discouragement. That is why I decided to contribute data to OpenStreetMap. Contributions don’t always have to be code, they can be documentation, testing, ideas, and even data.
OpenStreetMap is similar to Google Maps, but it is both free (as in speech not beer) and open source. Having an open source map is fantastic because proprietary maps usually don’t have an incentive to update data for communities with low populations. OpenStreetMap allows users to update the map themselves, and then their community can use it for various uses.
I contributed two chinese restaurant locations, the hours for a very tasty bbq place, a description for a famous pizzeria, and the location of a new university building. All of them were in my neighborhood in Manhattan, New York. It felt great to contribute data about my community and made me more confident for my next open source contribution.