"Working in Public" - a recommendation not a review

One of the podcasts from the Changelog I really really enjoyed (I actually enjoy all of them), was the "Request for Commits".

It is hosted by Nadia Eghbal (Twitter/GitHub) and Mikael Rogers (Twitter/GitHub).

The podcast covers topics such as:

• open source sustainability
• maintenance
• economics
• licensing
• etc.

When I found out that one of the hosts: Nadia had published a book entitled "Working in Public" I had to get it. The book is not about sitting with your laptop in a fancy coffeeshop in San Fransisco, but about open source, the complete title is: "Working in Public: The Making and Maintenance of Open Source Software".

The podcast has been retired now, but the whole back catalogue is available and is definitely worth a listen if you are interested in open source - now about the book.

I personally find the whole open source movement incredibly interesting and I have sort of grown up with open source, so books, articles and podcasts on the topics often catch my attention.

I have previously read: "Coding Freedom: The Ethics and Aesthetics of Hacking" by Gabriella Coleman another book on open source, which is worth mentioning.

Having been an open source consumer, contributor and maintainer for a long time, the topics related to open source hold an interest to me, only surpassed by the actual technical making of software. None of the above titles are about the technical part directly, they are about community, open source and understanding what open source is.

Nadia has worked for GitHub and her book is very much about the GitHub generation as she calls it, which even though I got into open source long before GitHub and Git, the book really covers some aspects I have not come across before or seen covered in such a structured way. The books is not about the GitHub generation, but it is founded in a period where GitHub and Git has been available and this defines a nice frame for the book and what Nadia wants to cover.

The book covers some interesting aspects of open source. One of the aspects, which really was eye opening two me and made me reflect on my open source involvement was the categorization of open source projects.

The above table is taken from "Working in Public", page 59.

I found out that even though I had been doing open source for a long time, ALL my projects had:

• Low User Growth
• Low Contributor Growth

So my projects are all actually toys.

This was not really a surprise, I knew I was not making anything of significance, I actually make most of my open source stuff for myself, but it was interesting to reflect on this categorization.

At some point a few years ago I decided to try to push myself to get involved in some more prolific projects. I wrote a blog post entitled "Contributing to a new project – a bit like starting a new job". Unfortunately the endeavour did not have the outcome I was hoping for and I slipped back into my comfort zone of toys.

There is absolutely nothing wrong with toys, to me open source is primarily two things:

• A platform for consuming software, I can use and on some occasions contribute back
• A platform for me to experiment and learn, on occasion contribute back

Lets start with the latter.

Open source has learned me a great deal on the topics of:

• Programming
• Test and quality
• Bug fixing and bug triage
• Documentation writing and communication
• Automation and CI/CD
• Software releases and road mapping and planning

So you could say that I am often just scratching my own itch. Oftentimes I do not even need the software I make, but I find the problem area interesting or contained and a good case for a learning experience. Almost all of my experiments are open sourced, since I do not mind sharing. I know this is not really contributing back, but I put it out there just because it might be of value or interest to somebody else - like I have found open source projects that have inspired me or taught me something useful.

About the first part, I am a heavy consumer of open source and I use a lot of open source software, simply because it is easily available and it is sort of all over the community in which I navigate.

Like the urge to contribute to something significant, as described above, I have taken over open source projects from other maintainers, either because I was using their software or I had the ambition to do so.

Examples of this are:

• Workflow, a simple, flexible system to implement workflows in Perl
• Spellcheck GitHub Action, a GitHub action for checking the spelling of text in your documentation

I use the latter professionally and for almost all of my open source projects.

Workflow has been on quite an interesting journey. I have been close to abandoning it even though it has been one of the more successful projects I have worked on. Recently the project has picked up pace and currently I have been joined by two contributors and we are planning the future, improving the code, fixing bugs and shipping plenty of releases.

I would even go so far as to say that Workflow has moved from a toy to a club, which is very satisfying and makes me want to continue to maintain and contribute. The project has actually gotten to 24 stars on GitHub - I find that amazing. All we do is work with the two other projects using Workflow and blog about it. Next step could be to see if we could obtain stadium level - just kidding, but some more users and contributors could be beneficial to the project and lots of fun.

Speaking of contributors, "Working in Public" touches on the topic of casual contributors. This is a topic on which there are very differing view points. Nadia describes the difference between active contributors and casual contributors. The first group are the kind of contributors, which stick around the project for a long time and contribute regularly. Whereas casual contributors do not, they submit a PR for a single improvement/fix or similar and are then on they way.

I myself am very much a casual contributor.

I have had PRs declined, sometimes because I did not know the project I was contributing as a whole or simply because I did not bring any value - I am sorry if this has taken up precious time for somebody, but I have always learned something, if not about technology, then about English spelling or something.

I have also experienced, moving from casual contributor to active contributor.

A long time ago I was using Sublime Text and I was really getting into Markdown and I found MarkdownTOC, a plugin to generate a table of contents for Markdown documents. I did some poking at the project, while working on picking up Python. I found the documentation a bit unstructured and decided I approached the maintainer, who was most welcoming since he was not a native English speaker (neither am I) and started to contribute to the documentation big time. This evolved into a long term collaboration and I drop by the project from time to time or if the maintainer pings me and asks for assistance.

I have been a casual contributor to many projects and I recognize why some maintainers prefer active contributors over casual contributors, but some of us really want to help with a single thing and do not want to get involved full time in another project, but we want to:

• Add a feature
• Fix a bug
• Document the implementation
• Correct a spelling error or a broken link

I for one welcome casual contributors to my projects, I cannot allocate all of the time to my projects that I would like, so if somebody wants to do the heavy lifting and all I need to do is review, squash and merge - please submit your PRs.

I have only mentioned a few of the topics covered from "Working in Public" and I have by no means delved into the book. The book covers a lot of material, without being a hard read. If you are vaguely interested in open source - you need to read this book. The book really helped me to understand aspects of open source I thought I understood, it have me perspective on things I did not fully comprehend and it framed me and my involvement in a way, where I now understand the open source "community" even better.

Happy coding ... and reading - and remember to check out the podcast.