Reading 07: Learning to Play by Implicit Rules

I think a hacker’s reasons for engaging with the open source community develop in stages. First, there is curiosity. As ESR points out, one of the striking similarities between the open source community and academia is that participants in both “stand on the shoulders of giants”, they continue researching or developing forward without having to reprove all the groundwork theories researchers before them discovered. Hackers begin to engage with the open source community when they reach a point of technical understanding that allows them to wonder about what they themselves might create in computing. Open source provides the canvas for young hackers to begin to crawl in expressing new and innovative ideas, even if just to their own minds, and bringing them to life. This canvas for exploration initially draws a young hacker to the open source community, but it is a selfish desire for better tools that causes them to stay engaged with the community.

ESR predicted that the future of open source would be in developing applications for non-techies. This is only partially true, because we have seen that development is not driven by what would be good for individuals outside the open-source community. In fact, it is driven by what those in the community desire to have and are willing to create, and if “non-techies” benefit, then that is ok too. Take for instance, word processors. A technical person, who we assume is naturally averse to documentation, doesn’t want or need much from a word processor. In fact, a supped-up vim editor can sometimes be enough. Obviously, this is not a reasonable solution for text editor demand among the lay person, so fancier editors like Microsoft Word develop and gain popularity. On the other hand, consider IoT development. Hackers have become interested in what they can automate and control in their houses with commodity equipment. This leads to new features being implemented to IoT products, and non-techies benefit without ever seeing open-source happen. This demonstrates that a hacker’s own selfish desire for things that they want, limits the scope of things that the open source community will work on.

One of the biggest obstacles to contributing to the open source community comes early in the curiosity phase of a young hacker’s life. I experienced this personally in my internship over the summer, but I think that without some sort of education into the culture and rules of the open source community, young hackers become unwilling to push code into a formal repo for fear of technical scrutiny. It is kind of intrinsically clear to a newcomer to open source that this community is reputation based. Therefore, seemingly the worst thing you could do is contribute bad code. As a computer science student in the process of learning about the concepts needed to contribute, it seems entirely likely that your code won’t be great code. How will you go on in the community if you tarnish your reputation early? And it’s not like you can push with the commit message “I did x,y, and z but I’m a student so pls go easy on me”. I first came to grips with my own unaddressed fear of ridicule in an internship where I was tasked to branch a project with contributors way smarter than me. I defaulted to keeping development stashed away on my local machine (which I know is bad for multiple reasons) so that they didn’t see anything until everything was just perfect the way I wanted it. Over the summer they subtly wore me down, and in reflection I came to realize what ESR states explicitly. One of the implicit rules of open source is that devs don’t flame other devs over technical skills.

I don’t know how you learn that about the open source community without a mentor to show it to you. So, unless you’re a prodigy programming whiz, it seems entirely likely to me that the open source community is missing out on attracting talent who fears the public shaming of a bad commit. In fact, I know there are some here at Notre Dame. For the open source community to sustain itself going forward, it needs to make at least this rule explicit, almost like a terms of use agreement. Like the Zen of Python or the Unix Philosophy, the open source community almost needs a short mantra that captures its development process and the guarantees that developers will uphold with one another. I think this would draw a whole new pool of contributors with tangential interests, who with a guarantee of safety for their ideas and contributions, might start developing more of the user applications that ESR imagined for non-techies.