Open Source Enlightenment 2015 (Part 1)

( If you already know what "Open Source" means, you may wish to skip directly to part 2: https://medium.com/@audrey.tang/lessons-i-ve-learned-32f5d8107e34 )

Allison Randal visited Taipei, Taiwan in 2012 and gave a talk called "Open Source Enlightenment". At that time, I took a transcript and translated it into Chinese. Following is my keynote speech at Modern Web 2015, a continuation of the Allison's ideas, focusing on the social aspect of Open Source.

The word "enlightenment" roughly means, "to share knowledge and logic as a light to illuminate human life". First used in the 18th century when Voltaire, Kant, Newton, and others — who would have pronounced it Lumières or Aufklärung — ushered in the Age of Enlightenment, it marked a stark change from the prior eras, in which people listened to the Word of God through members of the clergy, while making rational decisions based on their limited knowledge. The ideas of the Enlightenment eventually led to the French Revolution, which centered on the ideals of liberty, equality, and solidarity.

There has been a similar enlightening in modern times. Javascript and the Web have been around for about 20 years. When I began my career 20 years ago, Open Source already existed; it had been around for 10 years already, and called the "Free Software movement". Free Software is a struggle for freedom, for unlimited Internet free speech, and unrestricted creation; it is a political movement. In 1998, a group of people involved in the Free Software movement started re-branding an offshoot known as "open source". To appeal to members of the business community, the creators of open source framed it as an economic package: given that businesses strive to treat contributors with equality, open collaboration can help them achieve high efficiency and high quality in their creations, and this is just what Open Source was designed to offer. The two schools, Free Software and Open Source, differ in ideology, but are exactly the same in practice. To write an Open Source program is to write Free Software.

My goal today is not to discuss political freedom, or equal economic concepts, however. Today, I want to focus on the cultural concept known as "solidarity", or "fraternity". The word fraternity (meaning "brotherhood") originated during the French Revolution. Due to the mainstream advancements in our understanding of gender, we tend to say solidarity now, meaning, "helping one another".

Over the years, I started to feel that our participation in the Open Source community was like a road that we all have traveled together. The community we share belongs to the wider science, technology, engineering, and mathematics community that is unique in its potential to have solidarity with any other community, through application of itself to the needs of the client. And, because unrestricted use is the initial defining characteristic of Open Source, we open ourselves to solidarity with the entirety of society.

The Web is built on hyperlinks and inter-connection. The dialogue we have with society as a whole through the Web is constantly creating new types of spaces for discussion and debate to take place. These spaces allow us to become better creators and, by allowing us to work with so very many different types of people, they allow us to become better individuals.

Open Source allowed us to accomplish feats no one had previously accomplished. Why? Because, after someone creates something, you can immediately use that thing to create something else! The creation of Open Source software, by definition, is doing something that no one has done before, to share with everyone else.

There is a saying that I like by the famous Chinese writer Lu Xun: "There is no such thing as hope, or lack of hope; just like the Earth once had no roads, but as more people walked the same way, there became a road." Open Source is a road of creation; along the way, we step in the footprints of our predecessors, leading forward to a place where no one else has gone before. The goal is always to take an idea just a few steps further.

This practice, on the one hand, allows us, and even demands of us, to grow. On the other hand, though, by joining in and contributing to the Open Source community, we are inviting the world to grow along with us. Like flowers in a garden, people inside a community space will grow and flourish.

Every Open Source community has its own online space, such as GitHub and the Gitter chatroom that I'm keeping an eye on even while giving this talk. These communities also have offline spaces, such as Hackathons and Makerspaces. Each of these spaces is a wide-open field, its contents organic. Following the path of Open Source can lead us to a worldwide network of welcoming, open spaces to give us and our ideas the space we need to grow.

So long as we are participating in Open Source, we will have friends all over the world. You will always have friends who will share a meal with you in a foreign country, or friends to meet at the pub in your hometown. The most visible product of Open Source may be code, but at the heart of Open Source are the vibrant and diverse people.

There are many varieties of Open Source projects in which people can assist. This is a photo of a flashmob, a phenomenon from the last decade in which many disconnected people join together to put on an impromptu, yet choreographed, show. Online spaces, like flashmobs, used to follow a 1%-10%-99% rule. If 100 people are involved in the online space, or flashmob, only one person is writing the script or entries, ten people are editing and providing error correction, and the remaining only consume the content.

This rule is a thing of the past, however. With current mechanics such as clicking the "Like" button, or sharing a link, or editing an article on Wikipedia taking less time (editing an article on Wikipedia can now take as little as one or two minutes!), the dividing line between consumers and contributors begins to fade. With time, consumers become potential contributors.

In a typical Open Source project, of course, some people complete the design, and some people write the documentation. Some people write the tests (of course we all write tests, right?). Then, someone writes up the modules, and someone else uses the modules to produce the application. But, sitting at the end of this assembly line are the users, and the users are the most important people in the system, as the project exists to meet their needs.

This all-important user is, very often, the project developer themselves at the very beginning of an Open Source project, having prototyped the project to meet their own personal need (or "scratch their own itch", as some would call it). As others begin to use the project, however, the demand created by the new users' needs shape the future direction of the project, giving it an identity of its own.

This wasn't always the mainstream with software. Back in the early days of Open Source, there was a focus on bringing down the "evils" of Microsoft's empire. The Microsoft Corporation was very secretive, akin to a cathedral; their goal was for every person in the world to have Windows on their computer, the One True Operating System designed and developed by an educated clergy who decided what people needed from a computer, and when.

Windows 95, Windows 98, Windows NT and ME and 2000 — every couple years, the clergy launched products "for the people", designed for the "average person" who could not use DOS or UNIX; and from this, the company grew to be very powerful. The spirit of Open Source was very different, though; instead of being "for the people", we are "with the people". Projects start, and users find the project, apply it to their own needs, and with time these users bring forth their complaints, suggestions, and eventually patches, becoming participants and contributors. If this project isn't quite to your liking, others like it, but which follow a different philosophy, are nearby. Like the monolithic corporation can be likened to a cathedral, Open Source can be considered a bazaar.

Because the relationships between people in Open Source projects are like those between consumers and vendors at a bazaar, we all find ourselves standing on the shoulders of others for the basis of our development. Importing a common library, for example, or referring to another's publications — such as my use of many Creative Commons-licensed images in this talk — is how we set our foundations, and those foundations are someone else's production. If you have a gripe with your compiler, interpreter, operating system, or even the drivers and kernel of your operating system, you need only open a channel on IRC, or send an e-mail, to speak to the people upstream who can take your complaint into consideration.

The Linux Kernel is an excellent example of this. Development of the Kernel is thoroughly decentralized; everyone works together to maintain it, from discussion to patching to testing and onward. This makes changing the Linux Kernel easier than amending a nation's constitution. Our own projects, like the Kernel, gain the same benefit when used by others -- if something needs changing, someone will make the change, and someone else will be sure the tests provide complete coverage in small scale as well as in the context of where users will come across that change. And, if you write a library or module that others use, you might eventually receive a Pull Request, complete with a patch and comments. There is suddenly one more person helping you produce the logic, write the tests, and perform quality assurance, and that makes the situation so much better.

When that person sends you that first Pull Request, you are now taking part in a concept important to Open Source culture: "Upstreaming". Sometimes people take the time to make changes, but keep those changes within their team, not contributing "upstream" to the project, which they changed to their needs. The problem with this situation is, when it's time for the next update, your team will be responsible for all the maintenance required in updating your changes to match the newest version. If you contribute your changes upstream, however, you won't need to make those changes or perform the test-work yourself; it will be a part of the project as a whole and you will have joined the rest of the community upstream to maintain that project. Communicating upstream can be a difficult hurdle to overcome initially for those new in Open Source; however, once you've tried it, the path will be clear from thereon out.

So, how can one communicate with the upstream? First, keep in mind that there are a variety of different types of upstreams. If an upstream author isn't responsive for a week, the project may be stalled or the author may be otherwise occupied. At that point, you could find a new upstream source or, if there are no other effective sources, you could "fork" the project, or duplicate the current source code as a starting point for a new project, producing a new upstream source for others.

But, why does this work? Why do people even get involved with Open Source projects? This is a very important question if you wish to know how the Open Source model works. After all, everyone works with computers at their day-jobs. Why would we continue working with one into our off-hours?

Clay Shirky, an American writer and teacher who works with the social and economic effects of the Internet, calls this drive "cognitive surplus", and describes it this way: During our free time, some people's entertainment is reading, some people paint, some people take pictures of cats and put captions on them, and so on. After the advent of the Web, people who already did these things found that if they do the same things in an online space, they spend the same amount of time to receive far more enjoyment.

When you notice a typo on Wikipedia and fix it without a second thought, the quality of that article is suddenly improved. And like Wikipedia, everyone has a chance to make a contribution to our culture, no matter how small; even the things we do in tiny bits and pieces can change our culture tangibly.

This type of endeavour, though, is always on the cutting edge. Everything you can create is something the world has never had before. People in the Open Source community can be exposed to the most exciting, fresh ideas and technologies, and even by sharing with others in discussion of these technologies, we can get to know like-minded friends and help increase other's enjoyment, if not their understanding, of an itch they wished to scratch.

But, sharing words, ideas, images, and programs is just the start. People traditionally say they "own" things, like a car or a house. Platforms like Uber, Airbnb, and others have taken advantage of the concept of a Sharing Economy, however, and this is how we see Open Source seeping into mainstream culture.

Far more than just utilitarian, the people in Open Source projects tend to share a spirit of altruism, wanting others to enjoy without having to give anything in return and finding that helping others is a great source of happiness. And this happiness is contagious.

Famed battlefield philosopher Iain King wrote a book about The Help Principle, after following the United Nations into Kosovo, to understand and meditate on the subject of people in need of help. If spending one unit of your effort could help another person by two units, he detailed in his book, you should help. If you spend two units of effort, however, only to help another person by one unit, then it does not fit into the spirit of utilitarianism.

Open Source takes this principle further, through having zero marginal cost. If I develop an Open Source tool, I am first helping myself, and then another person. This person might take the time to help another by sharing this tool with them, or modifying the project to help meet the needs of their friend, all at no marginal cost. Mostly, we just post a link to the project and say, "This tool can solve your problem", and as other share the link, four becomes eight, and eight becomes sixteen, and so it continues, exponentially. By working with an Open Source project, as long as you can provide 1.0001 units of help for one unit of effort spent, the help provided by that ripple will expand out, helping more and more people.

In addition to the psychological reward that comes from helping others, participating in Open Source can provide many external rewards. Among other things, you can gain respect from others on the merit of your work. With this new thing you've created, you will find yourself collaborating with others, others who appreciate this individual with the clever idea or perspective.

We all use Git here, right? Git is amazing, and makes it very easy to explain the concept of Open Source collaboration. Back in the cathedral model, one would have to appeal to a higher authority on any subject, in order to elicit change in a project; but, Version Control, and eventually Distributed Version Control, gave everyone the freedom to do as they pleased and publish their results as Open Source, making it tremendously easier to merge in new ideas when they come along, or offer up portions of your own ideas to solve problems others might be having.

Even when a project finds itself standing in two diametrically-opposed camps, wishing to solve one problem in two different ways, the project can amicably diverge for a time and work through their perspective on their own, and merge again at a later date, as was the case with Node.js and io.js. When someone's fork gets merged, it speaks highly to the skill and intelligence of the maintainer of the forked project -- and kudos to you if you are one of those fork maintainers.

I think everyone should show thanks and respect for the people involved in any part of a project, though; the positive reinforcement of "kudos" encourages them to continue to participate in project activities. We get to know them better, through their contributions and comments, and as people discuss an idea in one project, friendships are formed as these two form a new group to tackle a new project.

I see these relationships often, and have formed many myself. "I'd like to know you by your values, not by your types, classes, or roles" is how I like to describe how these relationships form.

What I mean is, I am willing to meet people through Open Source to learn what they value -- that is, I am interested in what they feel is important, rather than what type of person they are, what class of person they are, or what roles they usually fill. People's types, classes, and roles change with their environments, but their Open Source contributions reflect what they think matters, and that is what I find valuable.

It is validating for a person to respect and appreciate another's values, and expressing that appreciation is important. "I really appreciate you writing this" and giving a "Like" or "++" goes a long way in making people happy for taking the time to contribute. I have contributed code to Open Source for about 20 years; for a long time, I received a thank-you email each morning, saying, "I really appreciate your doing this stuff, I used it in such-and-such project". I was able to maintain around 100 projects solely on the foundation of this enthusiasm. Nowadays, of course, I receive Pull Requests, which make me even more pleased.

This gratitude can be contagious. When I am happy, I remember that I am using the works of other people. Perhaps thanking them is in order.

More than thanking them, perhaps we should be giving them encouragement and praise. There is a custom in many of the online spaces in which I live, to add "++" to the end of a person's name, granting them "karma points" for what they've said or done. Other online spaces use the "Like" or "Favourite" or "Star", but it always means the same thing: this is the kind of contribution that our community needs and appreciates.

Someone involved in the Open Source community might see that an individual is doing something very challenging, and suggest some collaborators who could contribute their expertise to fill in where the individual was having trouble. This idea is known as "Ubuntu", which was first a philosophical concept before being adopted by the Linux distribution of the same name.

Ubuntu implies that everyone has different skills and strengths; people are not isolated, and through mutual support they can help each other to complete themselves. This emphasis on complementing and completing each other, and through it, helping people to self-actualize, is a South African cultural value.

When we help others, whether it be through code contributions, documenting, or even something as small as posting an issue to the tracker and seeing it through to the end, we often inspire each other as well. If there is something that needs to be done, we can turn to the right person and say, "You know, there's a gap in this project I'm working on that would be perfectly filled by you." We imply their suitability for working on it, and in some cases challenge them to reach outside their comfort zones. Thus, with just a little encouragement, the gap can be bridged and more gets done.

We must, therefore, strive to inform each other, and spread what information we have; communication skills are very important. In the Open Source culture, after decades of working with all different types of people, filling in the gaps as they came along, encouraging and challenging one another, laying out plans and changing our plans, we have developed many ways to communicate what is already established.

A GitHub project, for example, will almost certainly feature a README file, that describes, amongst other things, what issue the project is trying to solve.

Maybe there's a Changelog, or NEWS file, that provides information about the history and current state of the project. It may have a ROADMAP, or plans documented in a maintenance directory, describing what is coming next. It could feature a wiki or FAQ, directing the reader on how they can better support the project and other users of the project. These are our communications protocols.

By investing ourselves completely in development, and ignoring our users, we may be able to push commit after commit to GitHub, but we will be more likely to step on someone else's toes, repeat the efforts (and sometimes failures) of others, or hamper other people's work in different directions, as there is no communication.

On the other hand, if two projects are focused on the same issue, and those working on the projects have an open conversation, their work complements each other's and the solutions that work for one project, can benefit the other. React and AngularJS, for example, have common grounds where they have discussions about their ideas, and meeting minutes posted to Google Docs. Without that open communication, it would be easy for members of one or both groups to think the other was taking advantage, or just trolling.

Why would they do this, though? The answer is found in human psychology, in a cognitive bias known as "the illusion of transparency". I may be nervous when I talk, for example, and mistakenly think everyone knows how nervous I am, but this is the illusion of transparency at work. In reality, most of you probably can't see it; you're merely listening and considering what I have to say.

The illusion of transparency might be the reason a Tweet or Facebook post I might make seems to completely convey my state of mind when I send it, but gets mistaken for trolling behaviour once received. It is easy for me to believe that I did something that makes sense, and was well-reasoned, but only I have all the information about myself available to me at that time.

From the perspective of the observer, it's easy to fall prey to another cognitive bias: the "fundamental attribution error". An example of this would be assuming that a person you see doing something that appears trollish, is in fact a troll. It's far too easy for our brains to jump to the conclusion, "This is a bad person, and they are doing this on purpose", when in fact, what they are doing is probably just a reaction to a specific situation.

If there is no communication, people tend to feel left out, and feel more distanced from one another. With the illusion of transparency on one side, and the fundamental attribution error on the other, it quickly becomes difficult for the two sides to even speak to each other. This scenario is well-known in the world of technical problems, where "flame-wars" can erupt from seemingly innocuous circumstances. People think, "if we can find the best solution to this problem, it will end the flame war". However, there is a saying, "perfect is the enemy of good". So, while everyone is pursuing perfection, meeting their individual needs, perfection is not what comes of their actions; it is merely disagreement on what perfection might be. And so they will continue to fight, hurling insults and defaming each other, without making any real progress.

When the Internet was new, we, the early adopters, learned quickly to aim for a rough consensus — rough as in coarsely grained, not the kind shown in the picture. When a group grows past 10–20 people, it just isn't possible to form a finely-grained consensus. Those who argue loudest, and longest, tend to win out all other parties when a finely-grained consensus is the goal; they wear down and drown out their opponents until there is no fight left in them. Were this a real-world situation, it would be similar to achieving one's goals through violence. So, how did we solve this problem?

We learned, with time, to accept all possibilities, through the different kinds of people we met, and tools like GitHub, allowing us to see just how many different ways one could solve a problem through forks, pull requests, and discussion. We still work on our own projects, but learned to keep an open mind, as people trying to solve the same problem aren't actually interfering with us in any way. If we disagree, we can fork the project and offer our changes to be merged back into the original project.

We don't ask for permission when forking someone else's project, and all we need to merge is an agreement with the upstream project.

When Microsoft added support for Windows on ARM processors to Node.js, for example, they didn't ask anyone, or take part in meetings with the Node.js community, before beginning; they just took the initiative, and did it. Whether or not that code makes it into the original project, though, is in the hands of fate.

In my Asian culture, a lot of us feel that communicating progress is a form of boasting, since we believe that "empty vessels make the most sound"; this, however, could not be further from the truth. Share your experiences with courage, as well as a thick skin. Say something foolish — on the Internet, the best way to get attention isn't to ask questions, but to provide the wrong answers.

If you want the opportunity to learn new things, give the wrong answer to a problem; out of nowhere, experts will appear to correct you. If you are not initially talking about an imperfect answer, however, no one will show up to say much of anything.

In the words of Leonard Cohen, "There is a crack in everything, that's how the light gets in." Without an imperfect sketch, there isn't anything to inspire better.

=>> Continued in Part 2: https://medium.com/@audrey.tang/lessons-i-ve-learned-32f5d8107e34

(Thanks Jennie Rose Evers for translating from the original Mandarin transcript, and to Maryann++ for proofreading.)