Brief Review: Working in Public

Lessons from open source and the future of software creator communities

“Working in Public: The Making and Maintenance of Open Source Software” by Nadia Eghbal explains the open source ecosystem and the not well understood incentive structures and challenges of community built software. The book is definitely written for individuals who have little to no understanding of software or open source. For those that do, there were a few key learnings and insight which I’ll try to recap here:

Few Developers Drive the Success of Open Source Projects

• Open source projects are developed by a tight core group of developers, NOT a large community
• Less than 5% of developers were responsible for 95% of code and social interactions (for 85% of the open source projects on GitHub)

Software Maintenance is Painful and Not Fun

• Developers spend 42% of their time maintaining code — and maintenance costs 50–70% of total expenditures of software development (from survey and research, likely from commercial software not open source)
• In a commercial setting, developers are paid to deal with the things they don’t feel like doing. In open source, where so much work runs on personal motivation, security <documentation, maintenance, etc> can easily fall by the wayside.
• In many cases, particularly in open source, where maintaining is more expensive than creating, it can be better to abandon old tools and write new ones. Sometimes, the best thing for the ecosystem is to let certain projects die

Open Source Needs to better Support and Product Project Creators

• Open source needs to evolve to better align incentive structures for developers and producers to continue to be incentivized to produce and not get bogged down with community support work.
• In other online creator communities it is not required or expected that if you make a youtube video or a blog post that you are EXPECTED or REQUIRED to respond to all feedback, educate and ramp-up and allow low value contributors to participate in your project. Similarly GitHub and open source communities need to evolve to support Creators.
• Producers like to produce software for intrinsic motivation. The act of being inclusive, answering questions, dealing with feature requests, etc.from the community often goes against that. Bottomline it should be up to the core team of creators and maintainers to decide if they want that engagement, if they value those contributions, and without expectation or obligation.
• One idea suggested was “peer source” instead of open source:

Peer source: where all projects would become private repositories, which only trusted developers (people he knew, or that someone could vouch for) could access. “The rest of the community can download binaries, and have the satisfaction that there is accountability on some level, just not to them,”