While my previous blog entries have not been limited to a single topic, this week will feature more topics than usual, as there is simply a lot of learning to dicuss. I’ll be sharing thoughts on setting boundaries in the world of open source software and contributing to Wikipedia, as well as continuing my log of my project research.

OSS: Open Source Stress

Recently I had the pleasure of reading an interesting opinion piece - in the form of a Github Gist - provocatively named “Open Source Is Not About You” and written by Rich Hickey, who is the creator of the Clojure programming language and CTO of Cognitect. More on him, the language and the company can be found here. If, like me, you’ve been browsing the Internet long enough, you may do what I did and jump right to the comments before even reading the text of the piece, expecting a heated warzone of keyboard warriors. While the comments section is not without some dissenting opinions, and I cannot claim to have reviewed every comment, I can say that I was rather surprised to see that the section was actually largely dominated by supporters saying thank you for what Hickey had expressed. This led me back to reading the actual content of the piece and found a sentiment that I wasn’t surprised by, but have now heard expressed for the first time in the world of open source software.

At the risk of reductionism, Hickey’s point is largely captured by his apt title, and his words serve as a keen reminder that many endeavors require respecting healthy boundaries and being transparent about our intentions. While we may not all have been in his position and while it is hard to be specific without further knowledge of Clojure’s community experience, it is not overly difficult to understand the frustrations that must still arise from having started an open source project, having taken some steps to interact with a community that has built up around it, yet having to deal with a seemingly endless stream of questions, requests, and, at worst, complaints. In particular the following section stands out to me:

The tone is terse and scathing - and I can’t say I disagree with him - but in it I find a familiar narrative. Some of the YouTubers I have watched over the years have been quite honest with their audiences about dealing with similar struggles. While we can debate the sincerity of a particular creator’s claims of just creating content “for themselves” or just in the interest of sharing, it seems as though many creators have found themselves wrestling with their new “public” positions and the communities that have grown around them. Prepared creators can be honest and transparent up front, setting clear boundaries of what will or will not impact what they create (it is remarkable how many viewers try to lecture YouTube creators on personal matters of taste), but all seem to have to fight some frustrations and the ever-present threat of burnout. Why? Some may point to a feeling of self-entitlement, as Hickey does. I think this certainly plays a role, but want to add that I think there is also a certain, now misguided, sense of those with such “power” must equally respect their responsibilities. This sort of dynamic may hold weight when it comes to enormous corporations - think of our ever present concern to keep the “media” honest and balanced - but, even then, those are moral concerns. I don’t think anything that would be classified as a feature request deserves to be called a moral imperative and given the same demanding tone. Further, there is no great imbalance of power here! You in particular may not know how to program, but the wide accessibility of computers and programming resources offers a way to change that. Moreover, open source creators have made it easy for you - they have given you the code and the permission to modify it!

Some may contend that these creators owe something to their communities, but I think what that exactly is can be very hard to define. A cure for a medical condition is one thing; here the better analogy may be a work of art. Imagine all of the viewers of the Mona Lisa (or these days…selfie-takers-in-front-of-the-Mona-Lisa?) gathered around Da Vinci as he worked: asking questions, demanding changes and raising an uproar. Would you envy his position?

Wikipedia:

This week, in preparation for contributing to Wikipedia in the near future, I read Wikipedia’s Contributing to Wikipedia, A primer for newcomers and Help:Talk Pages. I must admit, I found the first two of these documents to be overwhelming (to the point of being counterproductve) in terms of sheer volume of content. Obviously Wikipedia is not a brand new project, its scope is not small and the amount of guidelines, concepts, and editing workflows is considerable. But personally I believe such a wall of text on a newcomer “primer” is too much: I found myself having to take a step back, clear my mind, and try to carefully go through the sections. Knowing that there are in-depth discussions of every aspect of working with / on Wikipedia is reassuring - I may not know everything about checking spelling and grammar on an article now, but I know I can go find a page on the topic - but that is what the primer should cover: the very basics and where to hunt down specific information. If the concern is that new contributors will make many common mistakes…which frequently stem from a failure to read the documents…well greeting them with such a lengthy document is unlikely to get them to read everything to avoid those mistakes.

Rant aside, I was able to glean that Wikipedia manages their own equivalent of a beautifully tagged Github Issues tab, despite the huge disparity in size, needs and varied material compared to large, professional codebases. While I did find the multitude of guidelines and practices regarding new articles, article requests and “research”, off-putting, this helped narrow my focus on revising articles in need of help: either grammatical or in terms of citations. To that end I was able to find a list of “Vital” articles which cover significant topics but need help to gain (or regain) a better quality status, a very extensive list of articles in need of citations, as well as, interestingly enough, the News and Open Tasks page of the Military History WikiProject, which lists military history articles in need of work. Given that, to this day, I particularly enjoy military history, I will likely be scouring the last link first over the next several days to find articles to which I can happily contribute.

FOSS Project Log:

Saturday, March 14

Saturday’s work on our course final project consisted primarily of reading the Atom Flight Manual and having an extended (remote) meeting with Boubacar and Jessica. My ongoing summary of the manual and our joint notes can be found here. Before we could effectively hunt down issues on Github and identify opportunities for contribution, we have been trying to get our heads around the Atom project as a whole, something which has proven to not be a simple matter. Key to understanding Atom is the knowledge that what the average user would download from the Atom website is known as the default distribution, but it itself consists of the core packages (not to be confused with Atom core). Extending Atom involves installing additional, community packages. (Atom is wonderfully extensible and modular in this way.) Thus even what greets you on day one of using Atom consists of multiple packages: the core package for the actual text editing area, tree view (the filesystem browsers on the left), the welcome guide package, etc.

The obvious impression, as we had, is: great - there is plenty of room for contributions! Indeed, that does seem to be true, but navigating these packages and finding potential issues requires some intelligent searching. Some packages can be found in the primary Atom repository in the Atom Github organization, while others remain sibling repos in the organization, complicating the contributor workflow. Our review of this situation lead us to this document on consolidating the packages - helping on this front is a possible, but unlikely avenue of approach.

One of the “sibling” repositories of note, however, is the Atom Flight Manual repository, which is somewhat active and does have issues as contributors seek to improve its quality. It struck us that we already have some insight - due to our development setup woes (particularly relating to Node versioning) - on where this manual can be improved! To that end, we are targeting our efforts on continuing to read the manual - to best understand the whole project - and also focusing on the manual as our first place to contribute. Hopefully by next week, we’ll have some small changes queued up for submission to help us get our feet wet, our names out there, and the creative spirit flowing. In the meanwhile, we’ve taken a smaller step in this direction by requesting access to the Atom community Slack, so we can begin to really get in and take the pulse of the project.

Other Course-Related Activity:

I am calling this week a “week of rest” on the additional contributions front, as I have struggled during this time to catch up on this semester’s workload. Time regained from not having to commute has helped, but deadlines continue to creep up!