Lessons learned from open source communities
Cache invalidation, Troll hugging, and Reactive functions.
Be bold
In 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 materialise and correct you. If you are not initially talking about an imperfect answer, however, no one will show up to say much about 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 us to do better.
Searching and Asking
Another important point is to ask questions. The benefit of having a community is that you can find people and information through forums and chat rooms. When you are working on a new project, you want to put it all in an easy-to-remember Web domain. With the new crop of top-level domains, getting friendly URLs is much easier and cheaper than it used to be.
Keywords are very important. The project “go,” for example, could not be found in search engines, so researchers had to invent a new keyword, “golang,” so that others on Google or in the Forum would be able to find the right place to be able to ask the right kind of people.
Coming up with new names, of course, is a very difficult thing. There is a saying: “There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”
RTFM Considered Harmful
So when someone asks you questions, when they finally find you through keywords, you can seriously respond, instead of coldly saying, “Read The Fine Manual.”
Saying RTFM is like saying, “Do not deal with people — deal with books instead.” But this way is unproductive because it blocks what we call our social objects. In contrast to RTFM, someone can ask a question, meet new people through answers, learn things through their answers, and again meet new people when offering this answer to others, continuing the loop.
If you cut this chain of souls, saying to someone, “Your step to me is the last step — go back and read the manual,” then their journey of joining the open source process is blocked, and they must find a new upstream before they can continue. So please don’t ever do that. Rather, help a person go down this road together. You can walk this road together much longer and go much farther.
Warm Reception
Sometimes such mutual support and community is viewed as a clique, a coterie, and so on. But, don’t look down on cliques — when it comes climbing with a group of people in the cold of the mountains, a close group around the campfire can be the most basic need. This is essential, especially for the novice who climbs for the first time — in psychology, we call that the Basic Assumption Group.
Only when the need of closely-knit supports is present will people be able to form a Working Group, which does the real work of climbing higher peaks. Especially for the novice, such a closely-knit support circle is indispensable.
Now I want to talk about how to offer constructive criticism. Although we just said individuals need to be open-minded regarding the varying development of others, under specific circumstances it is possible that other people’s brains contain cached information that has expired. At this time, we still need to offer criticism, asking others to clear their cache.
This time the focus is having a friendly attitude — to find at least one common ground that both parties agree upon. They may make ten claims, nine of which you think are wrong, but you still can respond to the one with which you agree: “I think you are talking about one thing that is right, but circumstances have changed for those nine other things.”
Cache Invalidation
We can take a very practical example. After a big earthquake in Nepal, more than 2,000 mappers from all over the world helped in the humanitarian OpenStreetMap team effort to create a street map around Kathmandu. Within 72 hours, they had mapped hundreds of thousands of roads and buildings based on satellite images.
In Taiwan, a civic hacker, Billy Lin, wrote an instructional article that called for novices to join OpenStreetMap and spend maybe half an hour learning to help with the Nepal mapping effort. Coincidentally, our president-to-be, Tsai, shared Billy’s call for help, resulting in an influx of interest.
At this time, the media was interviewing T.H. Schee, who had helped in the Typhoon Morakot relief effort and is an expert on crowd-disaster relief. He said that this is not always a good situation because in disasters, resources are very precious. A sudden influx of thousands or tens of thousands of people rallying together can overwhelm server resources, leading to a system breakdown. Instead, he thinks the priority should be reserved for the professional OpenStreetMap community, not for newbies.
When I communicated with T.H., I began by noting first that his concerns are certainly valid; this was especially true in 2008 when Elastic Storage was new to the scene. Seven years ago, if there was an influx of new contributors, there was no fast way to absorb them; but today we have auto-scaled elastic servers and machine-learning or peer-view systems in place to validate new contributions.
While T.H.’s concerns may have been important and valid back in that time, now the situation is different. Still, it’s necessary to adopt a friendly approach to communication. Subsequently, T.H. checked the mailing list and found that it was not the same as before, so he also publicly corrected this. However, the key here is to first agree on the concepts behind his ideas, although there may be some preconceptions that have since expired, so we just need to clear the cache.
Troll Hugging
Of course, not everyone will respond this gracefully to such communication; many others react negatively, so being thick-skinned is good. Perhaps someone writes 100 words, and 95 words are ad hominem attacks, and only 5 words have redeeming quality. From this point of view, you might as well ignore those 95 words, and instead politely and sincerely respond to the 5 words.
Here is a concept I proposed called “Troll Hugging”. As long as someone comes across as disruptive, I do something to keep talking until they stop. This is my personal interest — not to say everyone here needs to cultivate this hobby.
Specifically, how does that work? If someone types ten statements, nine of which are trolling, you can still respond to one single non-trolling statement in a sincere manner (and even that one line is trolling, but you can interpret it in a non-trolling fashion). Then, the person will learn that the nine trolling statements had no effect, as they received no response, but the other one statement was meaningful.
Trolls, in fact, are usually just people craving attention; by understanding what is constructive and merits attention, we can encourage participation and make contributions in a constructive way in order to get attention. In that case, they will be more likely to become a part of the community.
Reactive Functions
Here, listening is very important. Sometimes during a ‘flame war,’ if one side stops and says, “For the next two hours, I will quit talking and listen to you,” there suddenly is no war anymore. Often, we are caught in the heat of the moment; every 30 seconds, we can’t resist the urge to type, “Hey, this sentence you said is wrong,” but they have not yet finished typing. So it is important to sit quietly and let the other person speak their mind.
Reactive here means not rushing to say something, instead giving the other person your full, complete, listening attention; this is called active listening. There is an easy mnemonic for this technique.
We may know that there is a protocol called HTTP, which is the way browsers communicate with Web servers. When a browser talks with the server, the server can respond with five different kinds of codes. When we are in active listening, we try to take only the first three kinds, and ignore the 4th and 5th kinds of responses.
Specifically speaking, when someone is telling you something, you can offer them three kinds of responses:
- 100, please continue to speak;
101, I don’t understand, can you speak a common language? - 200, I heard you;
201, I heard you, and here’s what I think you meant. - 300, there are lots of different communities for this topic, you can try to approach any of them;
301, I suggest you find another person with whom to discuss this.
It’s great up to this point. Avoid 400, which is saying, “You are wrong, this is your fault,” or 500, which is saying, “Oh, I’m sorry, it was my fault.” Okay?
So, the point is to avoid 400 and 500 — don’t rush to identify blame in the situation.
Empathy
Sometimes say, “Yes, please go ahead,” sometimes say, “I understand, make sure I heard the meaning,” and sometimes say, “There are some people we need to consult.” Then, when the other person finishes what they have to say, there is no fire in the flame war anymore; this is a fundamental demonstration of empathy.
By looking at others’ statements this way, you’re making moves to put yourself in their shoes and gradually learning about their character. Anyone’s activities in the open source community leaves footprints, meaning we can trace back their words, their comments, and so on, seeing a new worldview from that other person’s point of view.
No One is an Island
Characteristics of the open source community, its solidarity as sociologist Gilles Deleuze described in the book “A Thousand Plateaus,” are of the Rhizome model. Think about plants like ginger, with organic growth in various directions, self-organized, and wherever it breaks it may sprout in the broken point; where there are vacancies, a new community springs forth. Communities keep pushing forward in all directions based on this idea.
The point is, regardless of how brilliant you are in a field — a so-called “demigod”, even — it is still important to remain humble because only with a humble attitude can we welcome others with different skillsets to join the project. Otherwise, it’s like saying, “I don’t need you; I can do things my way.” Such an isolated attitude cannot help us connect with new contributors.
Worse is Better
There is a formula called Worse is Better, which I translated to Chinese as 劣即是夯. In short, it means “Do not be afraid of ‘losing face.’” No matter how bad something is at first — such as JavaScript — in the end it becomes the most popular language, so you should not be afraid of initially losing face. Throwing out an ugly version is fine.
The leftmost logo was designed by two great programmers who are, however, not great at designing logos.
That logo was displayed in the 0th gov-zero hackathon, where the designer Even Wu saw it and became rather troubled; this is known as “one who cares, suffers” —Wu was compelled to improve the design; otherwise his day would have been ruined.
So as long as the first initiator is not afraid of losing face, better improvements will surely appear.
Safe Space
Here we emphasize the cultural concept of intersectionality, which means that each person is in a social class, status, ethnicity, gender identity and orientation — maybe we are privileged in some aspects, and in minority positions for others. Using our own experiences in vulnerable positions, we can empathize with people in the minority; you can put yourself in their shoes, fostering genuine solidarity.
In the past few years, we are encouraging conferences to adopt Codes of Conduct to set norms for participation. As no Code is universally applicable, we encourage conference organizers to consider and imagine that participants come to learn things; then commentary on body shapes, skin color, and sexy pictures are perhaps unwelcomed distractions. If they are indeed distractions, maybe we can agree beforehand not to avoid perpetuating those commentaries. This way, everyone can have a safe space to learn together.
Solidarity & Diversity
Just as there are different cultures, like Perl, Ruby, and PHP, all these communities have their own unique methods of operation, and it’s important that we are able to humbly communicate with each other —that’s the only way to learn from each other.
During apartheid in South Africa, blacks and whites didn’t speak to each other, but if you ask Obama now, is he white or black? People in the audience, are you white or black? The concept of diversity is not to divide people into binary groups, like programmers and non-programmers.
By contrast, if there are 1000 people here, then there are 1000 kinds of people here. Only in this context is authentic communication possible, so we can understand each other, rather than labeling each other.
Self Governance
Open source folks, of course, likes to have fun, but also has the responsibility, on a personal level, to practice techniques such as Pomodoro Technique and Inbox Zero, which help to keep promises on things we agreed to work on.
At the community level, it’s important to be as transparent as possible in the decision-making process. Why transparency? Because in life there are so many things outside of the community, and maybe one day you can’t take so much responsibility anymore.
Delegation over Inheritance
When we write programs, we know that inheritance — in the sense of “abruptly leaving a legacy to be inherited” is seldom a good idea; we should instead focus on delegation, gradually passing the baton through a modular approach, enabling a collaborative, community-based approach to the project.
This is a natural element of the project cycle, because open source is not a zero-sum game; there is no risk of “losing the race at the starting line.” As long as you make sure that the person picking up the baton can run toward their own direction, then they have won the race already —by deciding on a goal of their own.
Shared Memory
Eventually, the only thing that remains is how we live on in each other’s minds.
Deserts Xuan has a lyric that says, “Time soars away, we’re not beside each other, but within each other.” In this era of the social Web, we are each other’s horcruxes, embedding our soul shards through work that lives in each other’s minds.
I may have left Perl 6 development for a long time, but the community still keeps the culture alive, and together a production-ready Perl 6 release was delivered on Christmas 2015 — in the spirit of Optimizing for Fun.
Ars Longa!
Projects are like the pyramids — the community may see the pyramids from a distance, and then gather around the pyramids to form a bazaar, where we find each other, and learn from each other.
A website exists for a time, of course, and open source is for a lifetime.
A lifetime is not long, however; life is like a rainbow, emerged and borrowed from nature.
Others who see the rainbow may be touched by it; people touched this way are inspired to make new creations, and the creation can move more people, which is how culture becomes endless and brings us continuous delight.
Finally, when I was learning Git myself, this is how I learned its commands:
- Fetch new facts as they arise — accept it.
- Merge with your existing understanding — face it.
Conflicts may arise here; we just need to resolve them. - Commit to an action — deal with it.
- Push it to the world — let go of it.
Why “let it go?” Because after you push out open source code to the world, it’s no longer yours.
Open source means that anyone can take the code, and run with it toward a new creative direction. We need to avoid obsessing over the ownership of our work.
These are the lessons that I have learned from open source communities. Thank you.
(Source: CC0 1.0 https://hackpad.com/C7vQilFOSGD)
