Acknowledging Non-Coding Contributions

Open Source software development has a firm foothold in the technical world. The plethora of social networks around code, the thousands of conferences and community groups all attest to the many people working towards the common goals of free and open source software.

However, most of the time it’s only the contributions of coders that are acknowledged. Software platforms will issue a press release about their latest major version, and append a generated list of registered users whose code was accepted in the last release. The contributors page on a software project’s online profile only includes the usernames of programmers whose code has made it into the master branch.

Besides the code, there are dozens of other functions that go into the continued fruition of free and open source software: The developers who pair program and review the code, but don’t make the commits. The project managers who organise the sprints and scrums, who organise and advise, but don’t make the code. Not to mention all the other functions of the software development lifecycle: the graphic designers and software architects, those who do the testing and QA. Beyond that, the marketing and promotional aspects of large projects, the members of foundations and councils that promote a product or FOSS in general. Even more, the scores of those who work behind the scenes in organising events and conferences for products and services. Down to the people who attend these events, speakers and attendees alike. Even the people who download, use the software, and recommend it for others.

Photo CC-BY sookie of Untitled (Toronto) by Felix Gonzalez-Torres, filtered.

There’s no limit to the amount of raw effort that goes into these projects, yet their efforts in these ofttimes thankless tasks are unacknowledged. And even then, it’s often relegated to a ‘Thank You’ at the end of a conference to the one or two main organising faces of an event.

In early 2015, Leslie Hawthorn wrote about how we can take the simple step of publicly thanking people for their efforts in her article A place to hang your hat. She details a series of simple steps to take: write down a thank you and send it. For bonus points: put it on social media. For epic bonus points: use these words as a basis for a formal recommendation on a service like LinkedIn. And the final gravy: give this thanks to someone not like you — someone who works in a different role than you, someone who is part of marginalised group; someone who would otherwise be overlooked.

This trend of thanking people was captured under the #LABHR hashtag on Twitter, and while it was an exceptional way to bring light to the thankless work done by a lot of people, it’s not something that should happen just once as a trend. It should be mechanism so ingrained into our projects and events and communities that we don’t have to create a special trending hashtag to thank people for helping.

For contributions that happen in a non-digital space — where people are literally working behind the scenes — actively thanking, and assisting where you can is one way to show gratitude, and help carry the workload. Hearing about delegates at events actively disrespecting and insulting the volunteer helpers is degrading and actively harming those involved, to the point of burnout in some cases. Going out of our way and thanking people for their efforts makes them feel appreciated. Even thanking for the smallest thing can result in that person helping more than what they otherwise would, thus improving the positive impact on the project. Encouraging them to continue doing what they enjoy, and sharing that with a wider audience, can help them gain recognition for their own efforts, and gather support for their own endeavours.

In the digital space, there are changes we can make to help find those who make a mark on our projects, and whose contributions aren’t usually acknowledged. User accounts on StackOverflow show a lot of information about contributions, but it should enforce the importance of moderation functions: edits, votes, and conversations about the answers. The StackOverflow API has a top question askers and answer givers endpoint, which should be sourced by project owners for sufficiently popular projects with their own StackOverflow tag. The people actively helping others on this tag are your free support network. Wikipedia pages hold a trove of readily-updated content about projects, and the Edit History page shows just who is doing that. Find these people and thank them.

‘Social Coding’ networks like GitHub are harder. A user’s GitHub profile is nigh uneditable; the ‘Popular Repositories’ is just a list of projects based on their star count, a mechanism for rating a repo so underutilised as to be almost useless in terms of signal. The ‘Repositories contributed to’ is based on an algorithm of ‘contributions’ over ‘time’ that isn’t documented, nor editable should the algorithm get it wrong.

Photo CC-BY Victor, filtered.

On a project level, GitHub really misses the mark. The ‘Contributors’ for any project are only those who have commits in the master branch. And even then, for sufficiently large projects where the number of coders is more than 100, only the first 100 are displayed by name, sorted by the lines of code contributed. The amount of lines of code a developer writes isn’t a metric for performance, so why is it being used as a metric of merit? People contributing bug reports aren’t included. Those reviewing code are discounted. Partial implementations that don’t make the grade of over-zealous product maintainers get nothing for their efforts.

Imagine if this social coding network allowed for editable profiles. A project could mark a user as a ‘contributor’ even if they had contributed no code, but were helping out the project in other ways, even offline. A user could chose to show their contributor status for their projects as a badge of honor, removing the noise from their profile. A user could even remove the dreaded ‘Green Contribution Graph’, a mechanism that is flawed in itself, useless as a real metric of contribution, misunderstood by recruiters as an accurate representation of worth, and which directly contributes to coder burnout.

The GitHub API and Archives hold tremendous amounts of data that their user interface takes no advantage of. We can use this information to create our own profiles of our projects. The octohatrack project which I maintain does exactly this. It dives through every Issue, Pull Request and Code Comment for a given project, and displays every single user who has made a digital mark on the project: The users who have contributed code, even those who are normally lost under the fold. The users who have contributed to bug reports, feature requests and code reviews. Those who have done as little as throw a `+1` to a comment are making a difference, and should be attributed as helping with a project, and thanked for their efforts.

Using this software, we can see that for a project with a moderately large user base, the amount of total contributors is often orders of magnitude greater than the core code contributors, which goes to show the amount of hidden work that goes unrecognised. For example, popular JavaScript based slideshow software reveal.js is hosted on GitHub. The banner at the top of the list of files boasts 160 contributors. If you click on this link, you only see 100 named contributors, which is GitHub’s limit for the Contribution Graph. However, using octohatrack, you can see that there are over 1,200 contributors to the project, both code and non-code. Someone might be on this list for doing something as small as a “+1” to a suggestion, or something as big as helping debug a complex issue; but if they don’t commit any code into the solution, GitHub doesn’t count them as a contributor. In this case, there is nearly a ten-fold increase in contributors compared to what’s being reported. If you run an project on GitHub, run `octohatrack` across your repo. See who has contributed, and go out of your way to thank them. Engage with those who engaged with you, and you might find a new pool of resources to help your project reach new heights. And it’s not just that one repo: there’s many people who talk about reveal.js on StackOverflow, and many more who have conversations, either code or use related, outside of these environments.  

There is so much work that’s already been done in open source. Bringing this into the light, and giving people the recognition and respect they deserve, is just the start of helping evolve open source software into a more sustainable ecosystem.

This is a cultural change, but if we make the effort, we can create a more healthy environment where all contributions are valued… not just the code.

Liked this piece? Get a 2016 subscription today.