Checkpoint 1.4.1. Exercise: List of software.
Create a list of all the software that you use on a regular basis. Which software is OSS? Which applications have OSS equivalents? What are those equivalents?
Section 1.4 On Sharing Source Code
Obviously, not all software is OSS.
Subsection 1.4.1 Source Code: To Share, or Not To Share?
Most software developers do not share their source code — especially companies that produce software with the intention of selling software to their customers. Microsoft, for example, does not share the source code for the Windows operating system.
Even freeware — programs that are downloadable for free from the internet — may not share their source code with the world. You can get the program for free, but if it breaks, or if you think of a way to make it better, there’s no good way to fix it if you don’t have the source code. For example, you can get the Flash Player from Adobe for free, but if you find a bug that crashes Firefox, you’re stuck with that bug until Adobe fixes it.
There are definite advantages to keeping source code hidden, especially if your goal is to sell the software itself. It’s harder to sell a software program when anyone is free to take the source code and use it for any purpose. If Microsoft were to release the Windows source code under an open source software license, anyone would then be able to take that source code, build “Bob’s Own Operating System,” maybe make a few changes, and then re-sell that product as a competitor to Microsoft Windows. Obviously, most companies who are selling commercial software don’t want that to happen.
Subsection 1.4.2 The value of sharing
That’s not to say that programmers who write open source software never make money. Some of the most successful companies in the world use open source software to power their businesses. Google, Amazon, Wall Street, the US Department of Defense — some of the world’s largest and most innovative companies, government agencies, and industries are writing software using OSS every day. They don’t sell that code; they share it, and by sharing, create more value for their organizations.
The amazing thing about contributing to OSS software is that you don’t have to work for a large company to see the benefits of working in a free and open manner. As a developer, you might write a utility that solves a particular problem. By sharing it, others might discover the utility of your tool. Others might extend it and help see it grow. At this point, what started as a hack has become something valuable for many. At this point, we begin to see how OSS development practices can provide demonstrable advantages over proprietary software development practices. Among them:
- Shared development cost. Writing software can be expensive, at least in terms of time. Good software takes time to develop, and time is money. And if writing software is expensive, then maintaining it is even more expensive. In the OSS model, the cost of the writing and maintaining the software can be spread out over several individuals and/or companies.
- Users can fix their own bugs. This is not a freedom that is obviously useful to everybody. Not every software user is knowledgeable enough to fix a bug when they find it. That’s fine; OSS also means that users can find other people to fix their bugs for them. Not everybody who owns a car is competent to change their own oil, but the freedom to change your oil, or fix a flat tire, or rebuild your own brakes — or the freedom to be able to go to any mechanic or any mechanically inclined friend and ask them to do it for you — is a crucial freedom to car owners. OSS extends that freedom to software.
- (Arguably) better and (potentially) more secure software. Allowing users to fix bugs can often lead to better and potentially more secure software. One of the problems with proprietary software is that there’s a limit to the number of people companies can pay to fix code — that limit is usually directly proportional to how many software licenses the company can sell. OSS projects have the potential to build a huge base of participants, far greater than the number of developers that any one company could pay. The Apache HTTP server project is a great example of an OSS project with many developers, both commercial and independent — that has created demonstrably popular 1 and arguably better and more secure software than any of its proprietary counterparts.
- Software that outlives its creator. There are literally thousands and thousands of pieces of software, written for outdated computers, that are no longer useful for any purpose. If we had source code for these pieces of software, we might be able to extend them to new computers, making them continually more useful and more interesting — but because we don’t have the source code for these programs, we have very little use for them anymore. There’s a word for this kind of software: abandonware. In OSS, there’s no such thing as abandonware. Sure, people may stop working on a piece of software, but the source is always there, ready to be picked up and carried forward by anyone who has the time and interest to do so. Every dead OSS project has a chance to be reborn.
- The freedom to fork. Sometimes software projects go wrong. If a project is proprietary, no one has any recourse if they don’t like the direction of the project: the owner of the project decides the direction of the project, period. But because OSS guarantees everybody the right to redistribute and modify the source code, developers can always take a OSS project and move it in a new direction, without anybody’s permission. This process is called forking. Forks are usually regarded as last resorts, since contentious forks can divide scarce developer resources and confuse users. However, a number of OSS projects have benefited greatly from forks; the X.org server 2 and Inkscape 3 are notable successful forks.
Checkpoint 1.4.2. Exercise: Compare and contrast similar proprietary and OSS software.
Choose one piece of proprietary software that you use regularly and find its OSS equivalent if it has one. (If not, pick another program.) Write a blog post comparing the two. Don’t just look at the code; look at the entire experience. How are the user interfaces different or similar? What about the user’s experience overall? Is the quality of the documentation comparable? Is one buggier than the other? (This may take some spelunking in forums, looking for bug reports, etc?)
What, in your estimation, would it take for a new user to switch from the proprietary, closed-source software to the OSS equivalent?
Checkpoint 1.4.3. Exercise: Install a new OSS tool and blog about it.
Go find a new piece of open source software that interests you. Install it, and blog about any problems that you have. Bear in mind that your notes may come in handy during later exercises.
Checkpoint 1.4.4.
- Shared development costs
- The cost of writing and maintaining the software can be spread out over several individuals and/or companies.
- Sharing source code prevents stakeholders from ethical benefits
- Sharing source code embraces the open-source community’s value of sharing. It benefits individuals in terms of making meaningful collaboration and building a better community for everyone.
- Users can fix their bugs.
- OSS allows users to find and fix their own software issues but it also means that users can find other people to fix their bugs for them
- Potentially better and more secure software.
- Allowing users to fix bugs can often lead to better and potentially more secure software because there is no limit to the number of people who could participate in OSS projects, compared to the proprietary software.
- Software that is built on top of open-source software cannot be sold as proprietary software.
- Open source software can be sold as proprietary as long as it follows the licenses approved by the Open Source initiative. Some open-source licenses allow combining open-source code with proprietary code, allowing commercial use and distribution under certain conditions.
- Software that outlives its creator
- People could stop working on an open-source project but as long as the source code is available to the public, the software still has a chance to be rebuilt.
- Users could distribute the source code free of cost.
- Although the source code is free to be viewed by the public, not all open-source software is free of cost. Authorized people could still charge you if you want to make a copy or modify their source code.
- Freedom to fork and take a project in a new direction.
- Although proprietary software cannot be forked, OSS guarantees everybody the right to redistribute and modify the source code, developers can always take an OSS project and move it into a new direction, without anybody’s permission.
What are some of the advantages of sharing source code in the context of open-source software (OSS) development? CHECK ALL THAT APPLY
You have attempted of activities on this page.
