* Masters of Doom

* Where Wizards Stay Up Late

* Working in Public

Marketing for Developers
by Justin Jackson

Traction: How Any Startup Can Achieve Explosive Customer
by Gabriel Weinberg and Justin Mares

This Is Marketing
by Seth Godin

Working in Public: The Making and Maintenance of Open Source Software
by Nadia Eghbal

I recently read "Working in Public" which was great, I recommend it. One interesting observation that was made: The perceived pipeline of user => casual contributor => active contributor => maintainer...is a lie. In the book they argue (convincingly) that you do not convert someone from casually contributing to actively contributing, it's instead that active contributors also make casual contributions.

What does that mean in this context? This company is operating under the assumption that they are helping by getting more people into the pipeline. In reality, what we need are active contributors who are invested in projects, not fly-by-night-i-want-a-shirt contributors.

For context I maintain https://www.CodeTriage.com which is a community of about 55,000 devs interested in open-source.

[0] https://www.fordfoundation.org/work/learning/research-report...

On a semi-related front, I'm also interested in lowering the threshold for participation in FOSS projects, but I approached things from the lens of helping potential contributors better grok/intuit the social/organizational structure of a project. To that end, I made small badges that projects can add to their READMEs to indicate, to a rough approximation, what "type" of project they are[0]. The project types are described in a really interesting book called Working in Public: The Making and Maintenance of Open Source Software[1] by Nadia Eghbal.

[0]: https://project-types.github.io/
[1]: https://www.amazon.com/dp/0578675862/

- Coders at Work (Seibel)

- Working in Public (Eghbal)

The first one is very entertaining. Read it a couple years ago and found it gives some valuable perspective. The second one is on my reading list, it was recommended around these boards.

Related to software design, there are many. The two that are on my recent list are:

- Software Design for Flexibility (Sussman, Hanson)

- A Philosophy of Software Design (Ousterhout)

I can't comment personally on their content yet, still have to work through those two, but I have zero doubts to learn something valuable. Certainly consider them.

This project includes badges you can add to your README to indicate your project’s current or desired type. This is a fun exploration of one aspect of the book that I found particularly interesting.

If you pay $X for someone to "resolve" the issue, when they submit a patch that doesn't work, or doesn't follow the style guide, or doesn't fit the software architecture, or is otherwise unsatisfactory, how much time are you going to spend fixing/massaging/arguing? Will it be worth it to answer the jilted contributor who keeps sending "I want my $50!!!!" emails?

Nadia also has a quick 10-minute presentation on some ways you can use money to help open source, but without actually paying for bug fixes. [2]

[0] https://smile.amazon.com/dp/0578675862
[1] https://blog.domenic.me/hacktoberfest/
[2] https://www.youtube.com/watch?v=bjAinwgvQqc

You could reverse this and say that if open-source advocates would make usable products with features on par with commercial products, people would adopt them. There's a chicken-egg problem here.

People interested in these issues should read Working in Public by Eghbal, which is about open source culture and sociology. I just finished it.