Open Source Mindset and Community
We have been talking a lot about open source technologies in this book so far and have shown you a lot of examples. But what does open source really mean? Why does Rich believe in it so strongly? What technologies have enabled open source development and/or benefited from it? This chapter takes you through Rich’s point of view on the open source movement in general and how it applies to the technologies we are discussing in this book in particular. A lot of software you use at home or work – say, to do your taxes or play computer games – is typically not open source. It is software one company owns. You pay to use it and the company does not let you look under the hood. Free and open source is becoming more common, though, and we will describe both what it is and the benefits in what follows.
What Is Open Source?
When programmers work on a program, what they write is called code. Code is a set of instructions for the machine, and can refer to either machine code or source code. Machine code is an impenetrable string of binary ones and zeroes that make up a list of low-level instructions that tell a processor to do simple things like compare or add one number to another, or store a value at a certain location in memory. Source code does the same thing, but uses human-readable names for variables, functions (pieces of code that may be used repeatedly), and more complicated data structures like lists of numbers or letters. Source code also usually has comments that explain why the code is doing what it is doing. A compiler uses these names and then throws them away, along with the comments, to turn source code into machine code, so it is a one-way process.
Most software, especially commercial software, is distributed only as a binary file of machine code, along with any images and other data used by that code. If you just want to run the program, this is fine, but if you want to modify the way it works, it is virtually impossible to do so without the source code. Some developers make the source code of their programs available for free, and this sharing ethose is called open source.
Many modern computer programs are too big and complicated for one person to write alone. In a software company, a number of developers will share source code among themselves to work together to build a program that they can sell. In an open source project, one or several developers will share the source code publicly so that anyone with the knowledge and the interest can help develop it, submitting their changes back to the maintainer of the project for inclusion in it. Anyone can start an open source project, although you do have to know what you are doing if you expect people to join you.
The Early Days of Open Source
Open source software has existed in some form since the early days of computing, when source code had to be printed out and re-typed by the user. (Joan notes that when she started using computers in the mid-1970s, she used paper tape, which could be loaned to others and laboriously copied by a machine, as long as you didn’t drop the spool.) In those days, computers tended to be centered at large national laboratories and universities, and so a lot of software was open source because most of it was academic (solving large scientific problems, for example) to start with. Cheaper storage (8-inch floppy disks giving way to 5.25-inch and then to 3.5-inch) and faster connections started to make collaboration possible for people who were not at major research centers. Easy collaboration became really plausible when the Internet came along and increasing connection speeds enabled sharing files without prohibitive wait times.
Tip If you are interested in the early days of open source development, Walter Isaacson’s book The Innovators (Simon and Schuster, 2014) is a great overview of the personalities and technologies of that early era of software and hardware development, and how the two alternately pushed each other forward and sometimes held one another back.
Perspectives on Collaboration
Developing sophisticated software or hardware collaboratively isn’t easy. It requires a shared attention to detail and in many ways a group agreement about how to think about a problem. Joan was around for some of the earlier attempts at this, some of it literally before Rich was born.
Joan’s perspective I first used a computer in about 1975 to learn to program in the BASIC computer language. There was a Teletype machine at my high school—considered very advanced at the time—that used paper tape or a keyboard as input and communicated over a phone line with a central computer who-knows-where. (If you want to see what they looked like, an example can be found at: www.quickiwiki.com/en/Teletype_Corporation). The big project to do if you were really cool was to get something to print out in banner letters on the paper scrolling out of the machine.
Looking back on the 40 years of development since, how we collaborate to build software has changed in many ways. It really does not feel like there were any real inflection points. Hardware, software, and connectivity all became incrementally better, with the occasional jump. In the process of writing this chapter, we have been comparing perspectives on how change occurred.
To me, it feels like software development morphed from something that only scientists and engineers did to something that a hobbyist could do. The earliest hobbyist computers did very little, and from my perspective the single biggest innovation was probably the 1984 introduction of the Macintosh, because interacting with it was so profoundly different than the one-command-at-time green text on a black screen that preceded the Mac. (Ironically, though, the Mac was set up so that you really could not program it.) But it took a long time for connectivity and software-development tools to catch up so that people who were not in the same building (or at least connected by dedicated lines between their big institutions) could work seamlessly.
In some ways, the current open source movement feels like a return to the early days of computing, when most of it was academic and developed for scientific purposes or just to see what would work. Hackerspaces I have visited feel a lot like the MIT student computer lab in the late 1970s and early 1980s.
The Internet and the Open Source Hacker Learning Style
Joan experienced the evolution of online networks from its early beginnings as a primarily academic and national laboratory resource to something any consumer could use. By the time the consumer Internet came along, she was already used to using early versions of some of the tools, although many innovations (such as easy-to-read web pages and search engines) came later. Her experience does not reflect the democratizing effect that the Internet represented for people like me. When I hear stories of what it was like in those days, all the things that my generation takes for granted sound almost insurmountably difficult, even for those with the most access.
Joan says that she learned about things being done at a distance by reading journal articles and ordering reports through a major university library. The time one had to wait to receive these orders would have been measured in days or weeks. You would have had to plan ahead of time to figure out what information you wanted and what was essential, since you could not order absolutely everything. Once something did show up, Joan or her secretary would have had to copy the important bits and put them in a file or three-ring binder for future reference.
When I learned, the wait time was measured in milliseconds, and I didn’t need to be a part of a prestigious organization to get that access. These changes didn’t happen overnight, but I think they do constitute a qualitative difference in how I was able to learn versus the options available before about 1990. I could not learn the way I do with a latency of days. My learning style has been enabled by the existence of the Internet. When I'm researching a topic, I can (and frequently do) spawn dozens, sometimes more than a hundred browser tabs in a matter of minutes, each prompted by what I read in the previous ones. Doing the same with the methods Joan describes would take months or years. This low-latency access to information is part of the reason I often see it as no longer necessary or useful to learn a subject (as someone else has chosen to define it) thoroughly, all at once, and in a linear fashion.
My ability to learn and think this way builds on many open source innovations (beginning with the Internet itself) and is at the core of why I feel it is so crucial to keep building open tools so that progress can keep getting faster and faster.
Open Hardware
Source code for software is all digital information, and the only thing you need in order to use it, aside from the computer, is more software. Figuring out how to create open source hardware, such as an Arduino board (Chapter 2) or a 3D printer (Chapter 3), posed more difficult problems because you could not turn digital zeroes and ones into physical objects—at least, not until recently.
Digital manufacturing devices such as 3D printers, laser cutters, and CNC mills use files similar to a program’s source code to create physical things. This means that people can share designs for physical things that don’t take a master craftsman to reproduce on the other end. It’s still not as easy as just pushing a button (see Chapter 3 on 3D printing), but it’s accessible enough for a global open source community of hardware developers to have formed.
Another crucial innovation was software for designing physical objects. Computer-aided design (CAD) software has been around since the 70s and has been used for virtually all mechanical, product, and architectural design for years, but these programs traditionally cost hundreds or thousands of dollars. In recent years, a plethora of free CAD programs have become available, many of them open source software. My personal favorite is OpenSCAD (www.openscad.org), which actually uses source code that looks very much like software code to describe objects.
Recently, the design of open source physical objects has become popular in two major categories. First, there is the design of Arduinos, 3D printers, and the other platforms we have talked about in this book already. Secondly, there are the designs of things meant to be made by using 3D printers and other digitally controlled manufacturing machines. But figuring out who has the right to make what can get pretty complicated, as I will get into next.
Free Speech vs. Free Beer
The term free is used a lot with open source software. This leads to some uncertainty, because free has multiple meanings in English. Sometimes, the Spanish gratis (no cost) and libre (referring to freedom) are used to distinguish between these meanings. Other times, the distinction is explained by referring to the difference between free speech and free beer. A lot of software is free as in beer, meaning that users can download and use it without paying money, but the source code is not available. Other software is free as in speech, meaning that the source code is available and users are free to use it as they want.
Sometimes source code is released under license terms that restrict what you are allowed to do with it. The software may be free, with source available, but the license may disallow commercial uses of the code. This type of license is often criticized as not being truly free (libre), and not in the spirit of open source.
Hardware works a little differently. Information can be copied freely, but physical things cannot. For this reason, open source hardware is frequently free as in speech, with the design files available and unrestricted, but not free as in beer because the parts, materials, and time needed to produce them are expensive. If you have the tools and materials, you can produce your own copy, but it still (usually) costs something to acquire them if you don’t.
The first RepRap (self-REPlicating RAPid prototyper) 3D printer was built using plastic parts that cost thousands of dollars to produce on a commercial 3D printer. Once it was built, it was able to reproduce those parts much less expensively. Probably inspired by the free beer concept, in the early days, these sets of printed parts were often described as costing “about the price of a case of beer,” and some early sets were either traded for a case of beer or sold for an equivalent price to cover the cost of materials.
The intention of the RepRap project, started by Professor Adrian Bowyer at the University of Bath in the U.K., was to distribute these parts virtually for free, with each new “child” printer becoming the “parent” of several more printers, resulting in exponential growth. Instead, capitalism reared its ugly head, and by the time I started trying to acquire a set of these plastic parts, they were selling on Internet auction sites for around $1000—for just the printed plastic components. At the time, it often cost this much again for all of the electronics (which were also open source), motors, linear motion components. Some printers now ship assembled for less than $500, and “print-it-forward” programs have started popping up again, with kits being sent out for free on the condition that the machine must be used to produce one or more kits to be sent out under the same terms.
I developed one of the early RepRap printers, the Wallace (shown in Figure 9-1), described at www.reprap.org/wiki/Wallace. It was tradition in the RepRap community to name printer designs after biologists, starting with Darwin, since the printers were seen as evolving themselves from one model to the next (with a little human help, of course). You can find an attempt at an evolutionary tree at http://reprap.org/wiki/RepRap_Family_Tree, but the number of designs quickly outstripped the ability to maintain such a list.
Figure 9-1. The Wallace, an early RepRap printer
The Wallace’s place in the evolutionary line went like this:
- The original RepRap printer was built in England in 2006 (Darwin).
- The Mendel became the new standard in 2009, with a simpler and more reliable design.
- In 2010, the Prusa Mendel was produced as essentially the same design, but with massively simplified components.
- The Printrbot (late 2011) was derived indirectly from the Prusa Mendel.
- Reprap Wallace (also late 2011) was inspired by early pre-release pictures of the Printrbot.
- The Printrbot evolved into the printers now sold by Printrbot, Inc.
- The Wallace had as a direct descendant the Alu RepRap (early 2012) and indirectly affected the Deezmaker Bukobot (2013) and Bukito (2014).
An even more extreme case is the various RepStrap (combining “Reprap” and “bootstrap”) printers. In these cases, builders do not have access to some of the materials needed to make a RepRap printer and instead cobble together a first printer from what they can get their hands on. This limited printer is used to make parts that are a bit closer to the mark, and this process is used until the result is adequate for the purpose. Developing-world 3D printers can come about in this way.
Share Alike
A variety of existing licenses are available to use to release an open source project. These licenses tell users what they have permission to do with the files you have shared. Commercial use is one thing that authors may or may not allow. Authors may also place restrictions on how their works may be redistributed. Open source software sometimes uses GNU licenses. (GNU is a recursive acronym that stands for GNU’s Not Unix.) On the other hand, hardware and designs for printable objects are sometimes released under a Creative Commons license, though the Creative Commons organization discourages using its licenses for software rather than licenses like GNU’s that are specifically written for that purpose.
Most licenses require attribution to the original author, so you’re not allowed to distribute something that someone else wrote or designed and call it your own. This includes derivative works— when you have modified or used parts of something that someone else has written, you need to give them fair credit for what they did. Some licenses even disallow derivative works. Such a restriction is not really compatible with the idea of open source but is more common when these licenses are used for things like books or music that are released for free distribution but the author wants to maintain control. An open source license is more likely to have a “share-alike” clause that allows derivative works to be distributed but requires them to be distributed using the same license terms as the original. This prevents someone from, for instance, taking a work that allows derivatives and commercial use and making a derivative with a non-commercial, no-derivatives license.
Note If you would like to see some sample open source licenses, you can check out some that have been community developed and posted for shared use. GNU licenses and samples are available from www.gnu.org/licenses/license-recommendations.html. Creative Commons license samples are available at http://creativecommons.org/licenses/. As always, you should consult a legal professional for the implications of using a particular licensing strategy, especially for commercial projects.
You’ve probably noticed the use of the term author in this section. This is because these licenses deal with copyright. Copyright can be applied to code just as it can to music or a novel, but the situation is less clear for hardware. Open source hardware is often released using the same licenses used for open source software, but for functional hardware, copyright is almost certainly not applicable. These devices are covered instead by patent law, and patents are much harder to get and shorter-lived than copyrights. There are just beginning to be efforts to develop “open source hardware licenses” per se, but the Creative Commons and GNU ones discussed to this point can be useful for the designers of mechanisms and machines to express how they want their work to be used, and these license terms are generally respected in the open source community even if they are not enforceable.
Outside the open source community, these licenses may not be respected. The open source community develops new technologies, usually with no expectation of financial benefit. When I invent something, I do it because I want to advance the state of the technology. Making a technology better creates the proverbial rising tide that lifts all boats, but a patent can lock up a particular advancement for nearly two decades, preventing others from building upon it. I like to say that every new patent issued extends the Dark Ages by 20 years. By contrast, open source development allows for the most rapid development. People around the world can collaborate and build upon each other’s work, sharing both the burden and the benefit.
Obtaining a patent also costs time and money. A patent prevents others from using a technology, but often a more important function is to prevent another from patenting the same invention and keeping it from you. Open source may achieve this goal too, because public disclosure of an invention can also be used to block anyone else from obtaining a patent on it. In this way, releasing a new innovation as open source can be a more economical way for a small company to avoid being blocked by a larger one. (Joan notes here, though, that this area can be complex, and if you are living it you should obtain some actual legal advice. There are some notable cases of a company apparently trying to patent something put out open source, and how that sort of case will play out is uncertain.)
What Does a Beginning Open Source User Need to Know?
It can be intimidating to jump in to an ongoing open source community and try to figure out how everything works. If you use open source hardware or software, you are not under any obligation to modify it or contribute to its development. (If it’s a non-commercial license, you may not be able to use it to make money though—be sure to check that and see the discussion about types of licenses in the previous section.) If you do want to contribute, this section will give you some suggestions.
Joan’s perspective It can also be hard to get going in an open source environment if you do not actually want to know how everything works in detail, since that is an underlying assumption. If you are like me and want to read a high-level overview first to see how things work, then you might first check to see whether anyone has written a book or, failing that, a web page discussing at least the high-level philosophy about how the system works. In this book, we have tried to give references like that for the technologies we have discussed. (In part, this book is intended to provide some of that big picture, too.) Failing all that, open source communities are usually good about giving a starting point if you can find a forum or wiki related to what you are doing.
Contributing to Open Source Yourself
Most open source projects use revision control systems to allow people to participate. These systems allow users to create a local copy of the code, modify it, run the code to test their changes, and then make those changes available to other users. The procedure for this varies with different revision control systems. Older programs like Concurrent Versions System (CVS) and Subversion (SVN) use a client/server model in which a user must check out the code (or some subset of it). As with a book from a library, a checked-out piece of code is not available for someone else to check out at the same time, which prevents conflicts but can limit the rate of development.
Distributed systems like Git are becoming more common. In Git, every user has a complete copy not only of the code, but of the entire revision history, while another master copy usually sits on a central server. Each user can make their own changes and then copy only the changes back to the central repository or directly to one another. Git has sophisticated utilities for merging changes made concurrently by different people, so even if the central version has changed in the time you were working on your modifications, it’s likely to be able to integrate your changes automatically.
It is possible to break things with incompatible changes, or just through insufficient testing of your changes. A project generally has one or more maintainers who control which changes are and are not allowed into the central repository. On github.com, a popular website for storing online Git repositories, users generally submit a pull request when they have changes that they want to submit for inclusion in the repository. A pull request consists of one or more commits, which are changes to the code with a title and description so that the history of changes can be tracked and specific changes can be located later. A pull request should always leave the code in a working state (it shouldn’t break existing functionality without fixing it, and should not introduce new code that does not yet work). Each individual commit should preferably do the same, though it is not uncommon to see one commit that is simply a fix for a bug introduced by another.
When something does break, the commit history makes it possible to look back and find where the code was broken, undo those changes (even if more changes have been made to other parts of the code since then), and to blame the person who introduced the error and discuss with them how to fix it. Github also includes an issue tracker that can be used to discuss possible changes, or for non-coders to report bugs so that those participating in the development can try to fix them.
For users of these open source projects, there are usually no requirements to contribute, though contribution is encouraged. If you have the skills, submitting improvements and bug fixes is almost always welcome. Just be sure to check coding standards or style guides (for instance, there are strong, differing opinions about the formatting of some types of code, particularly the use of brackets in C-like languages) and make sure that your commit message and comments are helpful. If you’re not a coder, that’s OK too.
If you encounter a bug in the program, be sure to check the issue tracker to see if it has been reported yet. If the issue has been reported, look at the report and see if you can add any helpful information, but don’t make a new one. Redundant bug reports waste time, and developers who get a lot of them have the understandable tendency to get crabby about it. If the issue hasn’t been reported, check for any guidelines for bug reporting and try to give as much information as possible about how to reproduce the problem. A bug report that includes whatever settings and files you were using (or better yet, the simplest version that still causes the error to occur) and a description of what you were trying to do when you encountered the problem is much more useful and will be better received than one that simply states that a problem occurred. Basically, the more you do to help the developer find and fix the problem more quickly and easily, the more it will be appreciated.
If the program works, but lacks an ability you would like to have, you can submit a feature request. Some projects are more amenable to feature requests than others, and, as with bug reports, redundant requests are never good. If you have a simple fix that will significantly improve things, some developers will be grateful for the idea, but keep in mind that what seems simple to the user may not be simple for the developer. Offer your idea clearly and don’t be demanding or make it difficult to understand what you’re suggesting. Remember, also, that very often the person maintaining an open source project may be a volunteer or merely doing the work as a small part of a larger academic job.
Hackathons
Software is becoming more of a service than something you buy in a box, and perhaps given that, joining a hackathon to develop some open source code to solve a problem is the newest way to volunteer for your community. The big difference now is that you do not need to happen to live in Cambridge, Pasadena, or Palo Alto to be able to contribute. You can search for a combination of your city name and a phrase like “civic hacks” or “civic hackathon” to see what is going on, or look at the national site http://hackforchange.org.
The Challenges of Open Source
To this point, we have heard mostly from Rich about the benefits of open source and a bit of history. Now to close with a bit of a counterpoint, we will hear from Joan about some of the practical issues that still need a little work. She has the perspective of someone who has been around some form of open source coding since before it was really called that, but who has now re-entered it and is looking to get some specific tasks done.
Joan’s perspective Chapter 1 discusses Rich’s learning style, which he very evocatively compares to crystals forming in all directions. The virtue and problem of a lot of open source materials is that they evolve in a pretty similar way. Someone seeds a project and then it becomes the hub of interesting things that branch in many directions. As people develop this material, they document what they add.
This means that, unless the originator of the whole thing gave some background about the big-picture view, there may not be an introduction to the big picture of the field available anywhere. New users have to just sort of dive in the middle and flail for a while, asking questions on community forums or trying out stuff on their own, to figure out what is going on. When a community gets big and lots of people are starting to do the same thing, the result is usually not very efficient.
When I started learning 3D printing, this is how things were. There was a big ball of interconnected string, and, in principle, you could get to any point on the ball somehow. But starting in the middle of the ball made it hard to see the big picture or why things were as they were. That is why I wrote Mastering 3D Printing and, now, it is why we are writing this book—to help create some bigger-picture context and some entry points into the ball of string.
This “ball of string” documentation style works well if you learn things the way that Rich does, from the middle outwards. However, if you are traditionally educated as I am and like learning with some structure and hierarchy around your materials, you may be frustrated. If you are dropped into learning something this way and it is not your thing, try progressively harder test projects so that you can grow yourself some scaffolding around the information.
The other challenge in using open source is that programs and hardware are continuously changing. This incremental improvement is a good thing in early-stage development and can move a new idea ahead quickly. However, if you are writing a class that requires the use of open source software, for example, the constant change makes it hard to use screen shots or detailed explanations. If you are using open source materials in a traditional class that is supposed to have materials fixed for several years, some creativity is required. (Universities, and more so K–12 schools, typically develop curriculum tied to a textbook that will be used for several years. Whether these practical limitations will be overcome when textbooks are electronic is an interesting question.)
It’s also important to keep up in the community, since “everyone knows” that you should use version 4.1.17 for application X but 3.2.9 for everything else. For those immersed in it, these are familiar streets in their hometowns, but for immigrants just trying to get something done, they can be frustrating. If you have read straight through the book so far, you will have seen how some standards are emerging in some of these primarily open source hardware and software technologies, and you probably already have a sense of how far there still is to go in many areas.
Summary
This chapter covered a bit about the open source communities that have developed and that support the fundamental work that underlies many of the technologies discussed in earlier chapters. We also talked about the rules of the road for collaborating in an open source environment and about the different types of open source licenses you might see when you start digging into these areas in more depth. Chapter 10 moves on to the topic of how to encourage more participation in these open technologies by women and girls.