I've been reading "Working in Public: The Making and Maintenance of Open Source Software" by Nadia Eghbal. And I like writing little summaries and notes when I've read books with others in a book club style in the past

So for this I'm going to do a 'Book Club' with all of you! As I read each chapter I'm going to write up a summary of the chapter and my thoughts on it.

If you want to buy the book, while supporting me and local bookstores consider using my bookshop.org link below

💰 Affialiate Link: Buy now

While Open Source and software is bigger than Github, Github and the developers who use it will be the focus of this book.

The early days of free and open source software was mainly driven by people with ideological views on software and open source. Many going as far as to not use any proprietary software if they can avoid it. People in these communities don't generally use Github, since it is proprietary softare.

But Github is the platform for today's developers. They want to share by default, and have adopted the MIT license as the, "set it and forget it" license. Github for them is all about convienence. And out of and around this was born package managment solutions like NPM, where smaller and smaller pieces of code were being bundled together as packages.

The persona of an open source developer is also changing in this time. Instead of the loud mouthed developer who doesn't care how the world views them, we have caring and empathetic developers wanting to help others learn. Never turning away a new contributor to their projects.

And instead of projects being the focus we are seeing shift to where the developers are the focus. Individual developers become more know by who they are than any one specific project they are working on.

There is some tension that we see arise between maintainers and their contributors who often make single changes. This tension is due in part to Github the platform making it so easy to contribute, and in part due to the more open and friendly developers that maintain these projects. This can leave maintainers having to do lots of organizational work to sort through different contributions, all while teaching the same basic of open source to each contributor.

I definitely see myself in the "MIT License and Set it and Forget It" crowd. I slap an MIT license on most things, and push it to Github. I have over 150 repos there right now.

And I want to see myself in this newer more friendly persona of developers. I want to teach and mentor others, and I'm hoping to learn better ways to approach that as a solo dev.