Working in Public is an excellent book, in my opinion, but I am unsure who I would recommend reading blindly. If you are doing open source, I am sure it will be a great source of inspiration and information. It would also be an excellent reference for people out of open-source to learn how we operate in the software industry since it is hard to explain why super-smart people work thousands of hours for free to give the result of their work for free work well to everyone.

The author captured the hearth of open source in many ways and left some open questions that can help us understand where we are going. She proposes an particularly interesting clustering for open-source projects in Federation, Clubs, Toys, and Stadiums to me, they are by far the best separations of kinds of open source I ever read about.

It was not a particularly easy read. On the other hand completely worth it. It got me thinking about so many things about my career, my open-source projects, and the futures of Nun-db. She brings up real problems for current maintainers of big projects and how they are under-supported today by the platforms. The points on how to fund open source are also great.

Points on problems for maintainers of prominent open source projects

• “Getting new contributors is not the problem. Making them have a positive impact easy and leave is.” Like in the companies we work for, it is not hard to get new people to work on our projects. But, having them have a good experience and creating meaningful contributions is a big challenge.

• The internet is created more by individuals rather than communities. But, like in open source and other communities like Youtube and Twitter, a few people bring the most value and are the key for a more significant community around them, and they will do most of the work.

• Maintainers have to deal with an overwhelming amount of information from many sources. How do we deal with that? How do we keep making progress and receive all the information process and still find time to work on the things that matter. The great tweet brings up some points about it like I how next. ``` Some observations from having merged thousands of pull requests in the past few years:
• Almost no one writes a good pull request title
• • More than half don’t know about the Fixes #112 syntax
• • ~30% don’t run tests locally before submitting a PR
• • ~40% don’t include docs/tests ```

Correlations with my master degree findings

I found some correlations between the book and my master’s degree research while researching the java 100 most popular repositories in Github. I found one cluster of developers that would have quite specific characteristics. I called them the “Open Source Heroes.”

Open Source Heroes

“Open source heroes (cluster 4) is the smallest group with only 21 profiles or 0.13\% of the final dataset. With a contribution min of 6,089, five times bigger than the Regular contributor min contributions, and 1.9 times bigger than its mean contributions, when looking at the number of pull requests, the min for this cluster is 185 when in all the other clusters we have at least one profiles with 0 pull request. Here, we find profiles that contribute to only one project but not for more than seven projects. The number of projects is also a significant difference between this and the Regular contributor (where we find people contributing up to 10 projects), this shows the people here focus on the projects they work on, and they probably use the open-source project as their full-time or part-time job.”

This book was not published back then, but it would have helped me with naming for sure :).

The fact is that my findings correlate with what the author mentions in the book, and it is complementary in some sense where we find a long tail of contributors eventual in my dataset they were 89,14\% of the dataset with a mean of contributions(commits + comments on pull request) of 19 mean contribution.

What did the question the book got me thinking?

Why do I do open source?

The author speaks about the costs of open source production and tries to find why people build it.

• So I asked myself, Why do I do open source?
  1. I do open source because I like to code.
  2. I do open source because I want to build different kinds of software that I don’t do daily in my job.
  3. I do open source to have long-term projects regardless of how many jobs or projects I participate. I will have projects that run for years and only depend on my abilities t make them succeed or fail.

How do I fund my open source projects?

I don’t particularly need funds for most open-source projects because they are small. For the ones getting bigger, I fund them with my own money and time, which is sustainable for the beginning since we make good money as a developer working regular hours; I can put in a couple of extra hours and get my stuff out there.

What if the project grows and requires more time? In that case, I think it means there will be some financial interest in the project, so I guess I can fund it with consulting or recurrence bills. I know how to run both businesses and have done the past, so it is not a source of stress to me today.

Conclusion

I would recommend this book to everyone in the open-source business; you may want to skip some chapters where she explains how we work and focus on the ones where she characterizes the problems and the problems we are facing to support maintainers. Probably a book I will re-read in a few years once my open source projects are more aged.

Where to find it

Amazon