What do you think?
Rate this book
Working in Public: The Making and Maintenance of Open Source Software
An inside look at modern open source software developers--and their influence on our online social world. "Nadia is one of today's most nuanced thinkers about the depth and potential of online communities, and this book could not have come at a better time." --Devon Zuegel, director of product, communities at GitHub Open source software––in which developers publish code that anyone can use––has long served as a bellwether for other online behavior. In the late 1990s, it provided an optimistic model for public collaboration, but in the last 20 years it’s shifted to solo operators who write and publish code that’s consumed by millions. In Working in Public, Nadia Eghbal takes an inside look at modern open source software development, its evolution over the last two decades, and its ramifications for an internet reorienting itself around individual creators. Eghbal, who interviewed hundreds of developers while working to improve their experience at GitHub, argues that modern open source offers us a model through which to understand the challenges faced by online creators. She examines the trajectory of open source projects, • the platform of GitHub, for hosting and development; • the structures, roles, incentives, and relationships involved; • the often-overlooked maintenance required of its creators; • and the costs of production that endure through an application’s lifetime. Eghbal also scrutinizes the role of platforms––like Twitter, Facebook, Twitch, YouTube, and Instagram––which reduce infrastructure and distribution costs for creators, but which massively increase the scope of interactions with their audience. Open source communities are increasingly centered around the work of individual developers rather than teams. Similarly, if creators, rather than discrete communities, are going to become the epicenter of our online social systems, we need to better understand how they work––and we can do so by studying what happened to open source.
256 pages, Kindle Edition
First published July 1, 2020
465 people are currently reading
3463 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 115 reviews
February 4, 2022
I've been excited to read this for months. What a disappointment.
This is a good example of what happens when a person hones their long-form writing skills on Twitter threads. This book is a printed Twitter thread.
The first half of the book is an acceptable contemporary survey of the history of Free and Open Source Software. Many important historical details are missed, but Eghbal can be forgiven for this; she isn't a software developer or an industry expert.
The rest of the book, however, is a poorly-researched advertisement for GitHub. Until we reach the final chapter, entitled "Conclusion" despite the fact that no conclusion is reached or even approached, erroneous and misleading statements soak almost every page.
On page 129, Eghbal declares that "Facebook doesn't have a customer support line you can call because they have more than 2 billion monthly active users." Facebook does have a customer support line you can call — if you are a customer. Facebook's customers are advertisers. Facebook's users are inventory. For someone so obsessed with social media, one would expect Eghbal to understand this.
On page 142, she declares "[c]ode by itself is not, and has never been, worth anything, and consumers already know this intuitively when they refuse to directly pay for it." By that same logic, a road or a library also has zero value. The latter half of the book waxes poetic about Club Goods and Public Goods, but it would appear little thought has been given to the semantics of those terms. Worse yet, she doesn't seem to appreciate that code has no analog in the economy which preceded computation. Between mixed metaphors and grand, declarative statements no space has been given to surface original thoughts about the topic at hand.
The tells that announce this deep misunderstanding of open source and its role in the economy are scattered throughout the book. On page 155 we have our first mention of the "Free Rider Problem," which is always a good indication the author has acquired her knowledge of public goods from Wikipedia. Perhaps recently. By the time we get to a comparison of the open source ecosystem to late-90s P2P filesharing systems on page 164, the jig is up. She doesn't understand the topic of her own book.
The writing is poor throughout the book. Nearly every page has a quote on it but, for some reason, the chosen quotes are always full of misspellings, causing Eghbal to shove [sic] into every one. By the tenth instance I had to wonder why her editor didn't suggest correcting all the spelling mistakes and prefixing the book with a caveat. Surely she had an editor? The words which aren't quotes are those of a first draft — a rambling and largely incoherent stream of consciousness broken up with the occasional dull fact or term definition. It was a chore to read.
But I did read it. All the way through to the "conclusion." Eghbal is a fan of scare quotes where they don't belong, such as declaring "clone" to be whimsical GitHub parlance rather than a very specific command of the underlying distributed version control system, but "conclusion" deserves scare quotes. In a book ostensibly about open source software, the final chapter is a stoner's daydream about social media and "content producers" on Facebook. In this final chapter, which doesn't reach any conclusions or formulate a single argument, open source is mentioned once. In a footnote.
This is a good example of what happens when a person hones their long-form writing skills on Twitter threads. This book is a printed Twitter thread.
The first half of the book is an acceptable contemporary survey of the history of Free and Open Source Software. Many important historical details are missed, but Eghbal can be forgiven for this; she isn't a software developer or an industry expert.
The rest of the book, however, is a poorly-researched advertisement for GitHub. Until we reach the final chapter, entitled "Conclusion" despite the fact that no conclusion is reached or even approached, erroneous and misleading statements soak almost every page.
On page 129, Eghbal declares that "Facebook doesn't have a customer support line you can call because they have more than 2 billion monthly active users." Facebook does have a customer support line you can call — if you are a customer. Facebook's customers are advertisers. Facebook's users are inventory. For someone so obsessed with social media, one would expect Eghbal to understand this.
On page 142, she declares "[c]ode by itself is not, and has never been, worth anything, and consumers already know this intuitively when they refuse to directly pay for it." By that same logic, a road or a library also has zero value. The latter half of the book waxes poetic about Club Goods and Public Goods, but it would appear little thought has been given to the semantics of those terms. Worse yet, she doesn't seem to appreciate that code has no analog in the economy which preceded computation. Between mixed metaphors and grand, declarative statements no space has been given to surface original thoughts about the topic at hand.
The tells that announce this deep misunderstanding of open source and its role in the economy are scattered throughout the book. On page 155 we have our first mention of the "Free Rider Problem," which is always a good indication the author has acquired her knowledge of public goods from Wikipedia. Perhaps recently. By the time we get to a comparison of the open source ecosystem to late-90s P2P filesharing systems on page 164, the jig is up. She doesn't understand the topic of her own book.
The writing is poor throughout the book. Nearly every page has a quote on it but, for some reason, the chosen quotes are always full of misspellings, causing Eghbal to shove [sic] into every one. By the tenth instance I had to wonder why her editor didn't suggest correcting all the spelling mistakes and prefixing the book with a caveat. Surely she had an editor? The words which aren't quotes are those of a first draft — a rambling and largely incoherent stream of consciousness broken up with the occasional dull fact or term definition. It was a chore to read.
But I did read it. All the way through to the "conclusion." Eghbal is a fan of scare quotes where they don't belong, such as declaring "clone" to be whimsical GitHub parlance rather than a very specific command of the underlying distributed version control system, but "conclusion" deserves scare quotes. In a book ostensibly about open source software, the final chapter is a stoner's daydream about social media and "content producers" on Facebook. In this final chapter, which doesn't reach any conclusions or formulate a single argument, open source is mentioned once. In a footnote.
September 7, 2020
In _Persecution and the Art of Writing_, Leo Strauss describes some techniques by which authors conceal heterodox ideas. One pattern he identifies is a book that has a long tedious and orthodox first part, and then suddenly the tone changes and there are a few striking ideas in the middle, at a point where most censors will have stopped reading.
I don't know if it was deliberate, but Eghbal does exactly that. The first half of this book was a rather tiresome taxonomy of projects and ethnography of contributors. And then suddenly she starts shooting up fireworks. The big point of the book is "project owners are busy and users impose costs on contributors." It's draining to have a clamor of users who need help, need you to fix bugs on their peculiar use case or platform, draining to have novice contributors who need a lot of coaching or whose well-intentioned patches are a bad fit for the project. In consequence, open source projects are _not_ a public good where there are no marginal costs. There very much are marginal costs per active user. And the big challenge of running an open source project is managing that.
Eghbal was a senior developer-relations researcher at Github and is able to speak knowledgeably about the costs and benefits that open source developers perceive. None of what she said shocked me -- it all fit well with my experiences as an engineer -- but I had never seen anybody say it in print, and seeing it, I realized it was a radically different perspective than open source advocates like RMS, ESR and Corey Doctorow have been pushing.
In Eghbal's account, the hard part about open source isn't starting a project, it's stopping one. When and how can project owners leave? Should they hand off the project? Abandon it? Maintenance is rarely fun, and once a project's user base starts to shrink, or once something better exists, it can be rational to just stop. There's a reason the Python community decided to kill Python 2.
It's worth slogging through the first 80 pages; the rest is definitely mind-expanding.
I don't know if it was deliberate, but Eghbal does exactly that. The first half of this book was a rather tiresome taxonomy of projects and ethnography of contributors. And then suddenly she starts shooting up fireworks. The big point of the book is "project owners are busy and users impose costs on contributors." It's draining to have a clamor of users who need help, need you to fix bugs on their peculiar use case or platform, draining to have novice contributors who need a lot of coaching or whose well-intentioned patches are a bad fit for the project. In consequence, open source projects are _not_ a public good where there are no marginal costs. There very much are marginal costs per active user. And the big challenge of running an open source project is managing that.
Eghbal was a senior developer-relations researcher at Github and is able to speak knowledgeably about the costs and benefits that open source developers perceive. None of what she said shocked me -- it all fit well with my experiences as an engineer -- but I had never seen anybody say it in print, and seeing it, I realized it was a radically different perspective than open source advocates like RMS, ESR and Corey Doctorow have been pushing.
In Eghbal's account, the hard part about open source isn't starting a project, it's stopping one. When and how can project owners leave? Should they hand off the project? Abandon it? Maintenance is rarely fun, and once a project's user base starts to shrink, or once something better exists, it can be rational to just stop. There's a reason the Python community decided to kill Python 2.
It's worth slogging through the first 80 pages; the rest is definitely mind-expanding.
March 30, 2024
The book is concise and to-the-point. A must-read for anyone interested in learning more about contributing to open source.
August 14, 2020
We assume that open source projects need to grow strong contributor communities in order to survive.... But this narrative no longer translates to how many open source projects work today.
This book is packed with interesting quotes, stats, and analysis.
My main takeaway is: most open source projects are reliant on an individual or small group of core contributors. The attention of those individuals is a crucial limited resource that needs to be rationed. Pushing a larger number of people to make open source contributions, or expecting maintainers to foster a sense of community participation, can be counterproductive, as it requires the maintainers to spend more time on reviews and discussions of contributions that frequently turn out to have low value.
This makes sense to me. In an enterprise setting, once a team gets beyond a certain small size, adding new people often does not increase productivity. It carries significant training costs (which don't pay off if the people don't stick around - most open-source contributors won't) and coordination costs. I don't know why we'd expect this to be different in the open-source world.
I'm also fascinated by Eghbal's claim that the focus of developer culture is shifting from projects to people, with some developers publishing large numbers of projects or code-related media, and holding influence over fans who follow them personally rather than following any particular project. There's an exciting aspect to this trend: as more developers fund each other on an individual basis (e.g. via Patreon), open source can perhaps be less beholden to corporate interests.
January 6, 2021
This book is tough to review because I really think it's two books: one is a collection of ideas about the history of open source, of software creation, and of the internet, and the other about a synthesized understanding of what open source means, the economics of it, and the author's own experience, having worked at GitHub.
Although there are a lot of really interesting ideas, fragments, quotes, and papers included in both tracks of thought, there is not really a central, cohesive narrative, and I found myself struggling to understand the thesis, the heart of what working in public is all about today, although I was very eager going into the book to read about it.
I think it could have been much better organized, although the visual layout, as with all Stripe books, was lovely, and it's obvious that a lot of research went into it.
Although there are a lot of really interesting ideas, fragments, quotes, and papers included in both tracks of thought, there is not really a central, cohesive narrative, and I found myself struggling to understand the thesis, the heart of what working in public is all about today, although I was very eager going into the book to read about it.
I think it could have been much better organized, although the visual layout, as with all Stripe books, was lovely, and it's obvious that a lot of research went into it.
September 17, 2020
The few insights could have been summarized in a few minute blog. This book might be useful for someone who knows literally nothing about software, open source, and perhaps technology to get an understanding of the dynamics in that world.
December 30, 2022
4.5 stars!
This book was SO interesting! I like to imagine I'm pretty web- and technology-savvy but prior to reading this book I didn't have a good idea of how open source software projects work in practice.
(My level of development literacy is: I can reliably track down where to submit issue/bug/feature reports and (hopefully) provide an above-average submission, but I have no idea how to submit a pull request.)
Eghbal did a terrific job covering how these projects start, from a very small to a very large scale, how communities form around them, and posed interesting questions about how the maintainers and contributors are motivated and compensated (in both reputation and money).
I'd be tempted to recommend this read to my developer friends as an interesting read (you know who you are). It's not a programming book, it's a people/projects/ideas book.
Another beautifully bound and printed Stripe Press publication!
This book was SO interesting! I like to imagine I'm pretty web- and technology-savvy but prior to reading this book I didn't have a good idea of how open source software projects work in practice.
(My level of development literacy is: I can reliably track down where to submit issue/bug/feature reports and (hopefully) provide an above-average submission, but I have no idea how to submit a pull request.)
Eghbal did a terrific job covering how these projects start, from a very small to a very large scale, how communities form around them, and posed interesting questions about how the maintainers and contributors are motivated and compensated (in both reputation and money).
I'd be tempted to recommend this read to my developer friends as an interesting read (you know who you are). It's not a programming book, it's a people/projects/ideas book.
Another beautifully bound and printed Stripe Press publication!
March 29, 2021
I got a lot of value from this book, but I wish it were better organised. Also wish it contained a section on open-source licensing, and how the cloud has changed the adoption of open-source products
It had 3 themes: how the open-source ecosystem has evolved, an application of economic theories to open-source, and a prescription for how creators and platform could manage and sustain open-source projects better
Some key points were:
1. Software is frequently characterized as “zero marginal cost”. It's not. It has significant distribution and maintenance costs.
2. Charging price equal to marginal cost leaves the producer bankrupt, with little incentive to maintain the product except the hope of maintenance fees, and no incentive whatsoever to make another. Without non-financial incentives, all but the most masochistic producer will get out of production.
3. While more people use open source code than ever before, its developers failed to capture the economic value they created
4. The GitHub generation of open source developers prioritize convenience over freedom or openness. They just publish their code on GitHub because sharing is the default.
5. Creation is an intrinsic motivator, maintenance usually requires extrinsic motivation. Some developers love to make things, but they don’t like maintaining them. Functionally, the work required by these two roles is different.
6. The combination of unpredictable quality and high volume means that casual contributions can quickly turn into a time sink for maintainers if they’re not careful
7. When user adoption is low, the cost of support feels trivially small. But as adoption grows, the once trivial cost of support can become significant. If 0.1% of users require support and a company has 1,000 users, then only 1 user needs support. But 0.1% of 1 million users is 1,000 users
8. Code by itself is not, and has never been, worth anything, and consumers already know this intuitively when they refuse to directly pay for it. What's valuable is the projects that depend on the code, the reputation of the creator, and the energy of its community
9. Crowd-funded (as opposed to corporation-funded) open-source projects can be successful. In politics, politicians funded by grassroots operations are viewed more than those funded by corporate donations
10. Reputation-based funding helps incentivize the ongoing production of creative work, because reputation is measured by past and future expectations. What people are paying for is not a bunch of text. They are paying for the perspective the writer brings to the subject.
It had 3 themes: how the open-source ecosystem has evolved, an application of economic theories to open-source, and a prescription for how creators and platform could manage and sustain open-source projects better
Some key points were:
1. Software is frequently characterized as “zero marginal cost”. It's not. It has significant distribution and maintenance costs.
2. Charging price equal to marginal cost leaves the producer bankrupt, with little incentive to maintain the product except the hope of maintenance fees, and no incentive whatsoever to make another. Without non-financial incentives, all but the most masochistic producer will get out of production.
3. While more people use open source code than ever before, its developers failed to capture the economic value they created
4. The GitHub generation of open source developers prioritize convenience over freedom or openness. They just publish their code on GitHub because sharing is the default.
5. Creation is an intrinsic motivator, maintenance usually requires extrinsic motivation. Some developers love to make things, but they don’t like maintaining them. Functionally, the work required by these two roles is different.
6. The combination of unpredictable quality and high volume means that casual contributions can quickly turn into a time sink for maintainers if they’re not careful
7. When user adoption is low, the cost of support feels trivially small. But as adoption grows, the once trivial cost of support can become significant. If 0.1% of users require support and a company has 1,000 users, then only 1 user needs support. But 0.1% of 1 million users is 1,000 users
8. Code by itself is not, and has never been, worth anything, and consumers already know this intuitively when they refuse to directly pay for it. What's valuable is the projects that depend on the code, the reputation of the creator, and the energy of its community
9. Crowd-funded (as opposed to corporation-funded) open-source projects can be successful. In politics, politicians funded by grassroots operations are viewed more than those funded by corporate donations
10. Reputation-based funding helps incentivize the ongoing production of creative work, because reputation is measured by past and future expectations. What people are paying for is not a bunch of text. They are paying for the perspective the writer brings to the subject.
September 4, 2020
Speaking as someone who knows little about open source, I found this book both informative and thought-provoking.
Describing the dynamics of the open source community and the varied and complex relationships people have with code (some "consume" code, some write code, some maintain code, some do a little bit of everything), Eghbal captures a set of concepts and metaphors that have broad application outside of their immediate contextual sphere.
At heart, the discussion centers around questions of community (i.e. what is the ideal community for a creator?), status (i.e. can we be honest about the fact that we are drawn to platforms like Facebook because they offer Status as a Service, and there is nothing wrong with that?), and creativity (i.e. what is a creator's responsibility to her work over time?).
Eghbal envisions an increasing number of creators, whether in code or Instagram or journalism, finding their niche with smaller, more engaged followings. In the future, it may become common for these small niches to sustain creators financially, removing the need for a corporate intermediary.
Describing the dynamics of the open source community and the varied and complex relationships people have with code (some "consume" code, some write code, some maintain code, some do a little bit of everything), Eghbal captures a set of concepts and metaphors that have broad application outside of their immediate contextual sphere.
At heart, the discussion centers around questions of community (i.e. what is the ideal community for a creator?), status (i.e. can we be honest about the fact that we are drawn to platforms like Facebook because they offer Status as a Service, and there is nothing wrong with that?), and creativity (i.e. what is a creator's responsibility to her work over time?).
Eghbal envisions an increasing number of creators, whether in code or Instagram or journalism, finding their niche with smaller, more engaged followings. In the future, it may become common for these small niches to sustain creators financially, removing the need for a corporate intermediary.
August 20, 2020
Software has eaten the world, and open source has been a huge part of that. I’ve been attending interesting talks about some facets of this book for the last few years, but was amazed by how thoroughly and thoughtfully the disparate strands of history, communities, and technology were woven together in this analysis.
I’m squarely in the center of the target audience for a book like this, having managed to build a small community around a set of my own open-source projects, but I think anyone who writes (or even interacts with) software will find a lot of interesting and accessible insight.
And buy the physical hardback! I was surprised to discover that it was even still possible to print and bind a book with such quality today.
I’m squarely in the center of the target audience for a book like this, having managed to build a small community around a set of my own open-source projects, but I think anyone who writes (or even interacts with) software will find a lot of interesting and accessible insight.
And buy the physical hardback! I was surprised to discover that it was even still possible to print and bind a book with such quality today.
September 9, 2020
It's a little hard for me to say just how interesting this will be to folks outside of the world of open source software, but I suspect that if you are interested in markets and economics, public goods vs. common goods, relationships between big online platforms and online creators, etc, you will enjoy this. It is extremely relevant to my day-to-day life and I have seldom seen someone write about what's actually going on in technical communities with such insight.
It's also a really beautiful physical book.
It's also a really beautiful physical book.
April 19, 2021
This book reveals a very intricate look of the open source software (OSS), where Github is the hosting platform.
At first, the author introduces Github, its features and community, from multiple reference points: stats, narrative and personal view. These telling stories show up many corners, from the diversity in characteristic of open source developers to tribalistic behavior of github projects. In hindsight, the first two chapters, rather arid, are later used as material to cook the main thesis of this book.
The tongue is suddenly changed when Eghbal introduces modern economic theories on how common resource are produced, used and managed, which challenge Ronald Coase's old concept on why production is only efficient at institutional level. While Ostrom outlined how successful commons usually are managed as group, Benkler's works explained at individual level why creators voluntarily come in and contribute code. Benkler supposed that most of work done within common-based peer production were motivated by intrinsic motivation and expedited by inherently modular and granular properties of software. He further argued that successful common resources must have low-cost coordination, which is no longer true in the OS world powered by Github.
Why does Github make that difference ?
The same as the invention of New feeds for Facebook (and social network in general), Github supplies OS people with a highway system to access OS projects. Imagine that a bunch of tribes lived 100 miles apart in a quasi-private mode, suddenly all are gathered into a large open-plan living room where one can look at and interfere other's life with ease.
The walls were torn. The tribes' identities were blurred. All merged into one. Consequently, there are two things happened. Maintenance costs have increased significantly due to the increasing number of contributors/users, and so on the total amount of reputation assigned for Github projects.
While creation is the joyful work, nurturing and maintaining existing projects oftentimes are tedious and requires some sort of external rewards involving in. Github, as a result of making the OS world more fluid, puts OS's maintainers in a position of being freely accessed (non-exclusive) to their limited attention (rivalry). A tragedy happens when an OS project gets matured: while the amount of maintenance work increases, the recognition, the predominant extrinsic motivation, for maintainers is stalled, if not decayed. If experienced maintainers leave, it'd be incredibly hard to find a replacement with in-depth knowledge about the project.
The solution for this problem is either to direct the use of maintainer's attention properly, or/and to yield more external reward for maintenance work (time to bring money to the table).
- In an OS project, everyone, either user or project's creator/maintainer, can be considered as a participant. This ill-defined problem results in over-participating and resource depletion.
- Though everyone should be set to use OSS at will (because it's a non-rivalrous good and can be distributed with almost zero marginal cost), accessing to maintainer help must be restricted. The author suggests that to reduce the burden on maintainers, first of all, we must separate production from consumption. Then, the ideal platform for production should be set up as the one-way mirror where producer/maintainer can keep making in public, but be able to evade arbitrary public demand, especially from extractive users.
Until recent, paying for Github's OSS was still an alien concept. There is a social norm by that we should not be charged for information ("Information wants to be free"). In the past, people paid for the device in that information was embedded (i.e people bought the physical book that contains content, bought hard disks that were sold together with software, etc.), not information itself. Nevertheless, making a living by being content creators on the Internet has became a new trend since the 2010s. And by content creators, I mean writers, designers, streamers, and developers.
While many questions are left unanswered (What price should we should for an OSS? who should we directly pay for? etc.), I am particularly interested in Why people pay for an OS project. It's turned out there have been no unified answer for this yet. Incorporation may sponsor OSS to get privilege supports when they need. Patrons support their creator for the future work, while subscriber may pay the fee to enter the community of like-minded people. These emerging behaviors suggests that there may exist new business model to monetize OSS, other than the dully Ad-based model or artificially scarcity by licensing.
Looking toward the future, I'd be super excited to see how new generation of OSS (Docker, Huggingface, etc.) conquers with orthodoxy, makes profits and creates new unicorns, while still keeping to work in public.
In general, I'm enjoy reading this book. There are many interesting pieces of information that I still didn't have a comprehensive view about. Will re-read it.
At first, the author introduces Github, its features and community, from multiple reference points: stats, narrative and personal view. These telling stories show up many corners, from the diversity in characteristic of open source developers to tribalistic behavior of github projects. In hindsight, the first two chapters, rather arid, are later used as material to cook the main thesis of this book.
The tongue is suddenly changed when Eghbal introduces modern economic theories on how common resource are produced, used and managed, which challenge Ronald Coase's old concept on why production is only efficient at institutional level. While Ostrom outlined how successful commons usually are managed as group, Benkler's works explained at individual level why creators voluntarily come in and contribute code. Benkler supposed that most of work done within common-based peer production were motivated by intrinsic motivation and expedited by inherently modular and granular properties of software. He further argued that successful common resources must have low-cost coordination, which is no longer true in the OS world powered by Github.
Why does Github make that difference ?
The same as the invention of New feeds for Facebook (and social network in general), Github supplies OS people with a highway system to access OS projects. Imagine that a bunch of tribes lived 100 miles apart in a quasi-private mode, suddenly all are gathered into a large open-plan living room where one can look at and interfere other's life with ease.
The walls were torn. The tribes' identities were blurred. All merged into one. Consequently, there are two things happened. Maintenance costs have increased significantly due to the increasing number of contributors/users, and so on the total amount of reputation assigned for Github projects.
While creation is the joyful work, nurturing and maintaining existing projects oftentimes are tedious and requires some sort of external rewards involving in. Github, as a result of making the OS world more fluid, puts OS's maintainers in a position of being freely accessed (non-exclusive) to their limited attention (rivalry). A tragedy happens when an OS project gets matured: while the amount of maintenance work increases, the recognition, the predominant extrinsic motivation, for maintainers is stalled, if not decayed. If experienced maintainers leave, it'd be incredibly hard to find a replacement with in-depth knowledge about the project.
The solution for this problem is either to direct the use of maintainer's attention properly, or/and to yield more external reward for maintenance work (time to bring money to the table).
- In an OS project, everyone, either user or project's creator/maintainer, can be considered as a participant. This ill-defined problem results in over-participating and resource depletion.
- Though everyone should be set to use OSS at will (because it's a non-rivalrous good and can be distributed with almost zero marginal cost), accessing to maintainer help must be restricted. The author suggests that to reduce the burden on maintainers, first of all, we must separate production from consumption. Then, the ideal platform for production should be set up as the one-way mirror where producer/maintainer can keep making in public, but be able to evade arbitrary public demand, especially from extractive users.
Until recent, paying for Github's OSS was still an alien concept. There is a social norm by that we should not be charged for information ("Information wants to be free"). In the past, people paid for the device in that information was embedded (i.e people bought the physical book that contains content, bought hard disks that were sold together with software, etc.), not information itself. Nevertheless, making a living by being content creators on the Internet has became a new trend since the 2010s. And by content creators, I mean writers, designers, streamers, and developers.
While many questions are left unanswered (What price should we should for an OSS? who should we directly pay for? etc.), I am particularly interested in Why people pay for an OS project. It's turned out there have been no unified answer for this yet. Incorporation may sponsor OSS to get privilege supports when they need. Patrons support their creator for the future work, while subscriber may pay the fee to enter the community of like-minded people. These emerging behaviors suggests that there may exist new business model to monetize OSS, other than the dully Ad-based model or artificially scarcity by licensing.
Looking toward the future, I'd be super excited to see how new generation of OSS (Docker, Huggingface, etc.) conquers with orthodoxy, makes profits and creates new unicorns, while still keeping to work in public.
In general, I'm enjoy reading this book. There are many interesting pieces of information that I still didn't have a comprehensive view about. Will re-read it.
July 5, 2022
It is clear from the first chapter that Nadia has thoroughly researched the open-source software (OSS) ecosystem. The book begins with explaining what OSS is and its history whilst highlighting fundamental modern-day OSS engineering tools such as git and several Linux flavours.
It also points out the ambiguity of the word 'free' in English when describing this topic by pointing out that Spanish has two words to disambiguate it into 'gratis' and 'libre' (also points out this is where LibreOffice gets its name from, interestingly enough).
The book provides chapters at the intersection of technology and sociology by discussing the different types of communities that exist in OSS and the dynamics. It also provides chapters at the intersection of technology and business by discussing how those developing OSS can be paid (since at the moment they are woefully underpaid, considering their code is used at large corporations for profits in the scale of billions).
Another interesting prediction is that GitHub will become for OSS what Twitch is for streaming or what YouTube is for videos. It is an interesting idea since this is a viable possibility with the same dynamics possible between creators and consumers.
All in all, very well-written book and I would highly recommend it to people wishing to learn more about the world of open software.
It also points out the ambiguity of the word 'free' in English when describing this topic by pointing out that Spanish has two words to disambiguate it into 'gratis' and 'libre' (also points out this is where LibreOffice gets its name from, interestingly enough).
The book provides chapters at the intersection of technology and sociology by discussing the different types of communities that exist in OSS and the dynamics. It also provides chapters at the intersection of technology and business by discussing how those developing OSS can be paid (since at the moment they are woefully underpaid, considering their code is used at large corporations for profits in the scale of billions).
Another interesting prediction is that GitHub will become for OSS what Twitch is for streaming or what YouTube is for videos. It is an interesting idea since this is a viable possibility with the same dynamics possible between creators and consumers.
All in all, very well-written book and I would highly recommend it to people wishing to learn more about the world of open software.
January 21, 2021
A well-written, economics-focused look at open source software. I enjoyed this book a lot, it kept my attention the whole time! It was fascinating to see behind the scenes of some of the open source contributors and projects that I’ve kept my eye on for a while now (React, Django, Linux, and others). The author also shows some great analysis and observations on how open source maintainers (but also people like Twitch streamers!) can and should charge for the work they do.
Highly recommend reading this if you have any interest in open source, or if you are a creator trying to monetize yourself or your work.
Highly recommend reading this if you have any interest in open source, or if you are a creator trying to monetize yourself or your work.
January 31, 2022
Good book. Would recommend to anyone who is trying to understand more about technical program(product?) management especially. Very applicable even working on propriety code really like explicitly puts words/ideas to things I had vague like half coherently formed ideas about before from my own experiences.
August 19, 2020
an exceptional book. physically an immensely pleasing object to hold, page through, and possess. intellectually stimulating if you work in open source, or are generally interested in the 'passion economy', trends in internet culture, or behavioral economics. style is semi-academic but also light. accessible to people who don't code.
December 17, 2021
Lacking structure but a decent introduction to the world of open-source software and the background work that goes into maintaining them.
July 18, 2024
Let me start on the good sides:
- It has a lot of new and valuable information about open source. I've been a FLOSS enthusiast for fifteen years and some ideas in the book were new to me. I genuinely recommend this to people who are new to open source and want to understand it (with a big emphasize on that they should take every sentence of the book with a grain of salt).
- It feels like an oasis. I don't know any other book about open source. It's good at least someone is exploring this area.
- This made me laugh out loud: "If you don't think this causes spam, trust me: It's incredible what developers will do for a free T-shirt" (yes, it's true).
Now the negatives:
Content:
- The github bias was clear as a day.
- No mention of heartbleed and how the broken support of open source devs led to this
- Praising npm and the ecosystem around it as a success, specially emphasizing on the small package paradigm and "modular" and saying that's great. Really? After so many security incidents and supply chain attacks and many other non-security incidents?
- Suggesting many ideas (e.g. subscription-based system) while not bothering to mention how many of those are extremely corporate ideas in complete disagreement with the original FLOSS movement ideas and principals. It's fine to want those, to think about them, or even suggest them but at least mention its disagreement with "original" FLOSS ideas.
- As someone who studied physics in uni, the comparisons with physical phenomenons made my heart ache. That's not how electrons work. Pressure of a gas is not calculated like that.
Form:
- It is really disorganized. While I see there were chapters but there wasn't any sense of progress, many ideas were repeated in different chapters and a lot of content were not really related to the name of the chapter they were being presented on.
- Oh boy, its font was awful. I mean the font looks nice and stylish for a blog post but there is a reason the print industry has settled on a very few fonts for books. Those "classic" fonts went through so much more refining and e.g. work with people with dyslexia and is designed to be less straining to the eye for long reads. Thanks to this book's whacky font, I was mostly distracted noticing the weird looking "y"s and I swear, the read felt way more than 226 pages and you will feel the pain too. The time it took me to read this, I usually read at least two or three books of the same size. Please, we, as the people in the software engineering industry, can just stick to what we are good at and leave other stuff of the experts in those fields?
- It has a lot of new and valuable information about open source. I've been a FLOSS enthusiast for fifteen years and some ideas in the book were new to me. I genuinely recommend this to people who are new to open source and want to understand it (with a big emphasize on that they should take every sentence of the book with a grain of salt).
- It feels like an oasis. I don't know any other book about open source. It's good at least someone is exploring this area.
- This made me laugh out loud: "If you don't think this causes spam, trust me: It's incredible what developers will do for a free T-shirt" (yes, it's true).
Now the negatives:
Content:
- The github bias was clear as a day.
- No mention of heartbleed and how the broken support of open source devs led to this
- Praising npm and the ecosystem around it as a success, specially emphasizing on the small package paradigm and "modular" and saying that's great. Really? After so many security incidents and supply chain attacks and many other non-security incidents?
- Suggesting many ideas (e.g. subscription-based system) while not bothering to mention how many of those are extremely corporate ideas in complete disagreement with the original FLOSS movement ideas and principals. It's fine to want those, to think about them, or even suggest them but at least mention its disagreement with "original" FLOSS ideas.
- As someone who studied physics in uni, the comparisons with physical phenomenons made my heart ache. That's not how electrons work. Pressure of a gas is not calculated like that.
Form:
- It is really disorganized. While I see there were chapters but there wasn't any sense of progress, many ideas were repeated in different chapters and a lot of content were not really related to the name of the chapter they were being presented on.
- Oh boy, its font was awful. I mean the font looks nice and stylish for a blog post but there is a reason the print industry has settled on a very few fonts for books. Those "classic" fonts went through so much more refining and e.g. work with people with dyslexia and is designed to be less straining to the eye for long reads. Thanks to this book's whacky font, I was mostly distracted noticing the weird looking "y"s and I swear, the read felt way more than 226 pages and you will feel the pain too. The time it took me to read this, I usually read at least two or three books of the same size. Please, we, as the people in the software engineering industry, can just stick to what we are good at and leave other stuff of the experts in those fields?
October 19, 2020
This book rekindled my feeling of love for software and programming. Eghbal writes with such care about projects and communities, and I learned a ton from this as a public GitHub peruser but noncontributor.
In terms of actions, my takeaways are that low quality contributions are sometimes worse than none, and maintainer attention (instead of the code itself) is the scarce resource of software production. Super fresh insights with a lot of applications outlined in the book.
In terms of actions, my takeaways are that low quality contributions are sometimes worse than none, and maintainer attention (instead of the code itself) is the scarce resource of software production. Super fresh insights with a lot of applications outlined in the book.
July 23, 2024
It was kind of a shallow overview, and I'm not sure who the audience is. It wasn't deep enough for me, as someone who has worked on open source. But maybe too
There is no thesis, it is kind of just an organized brain dump of what the author learned working at GitHub.
There were a couple of clarifying ideas -- that producing and consuming are separate, and don't both need to be fully open. Also, why projects gravitate to GitHub.
I would have liked to learn more about the Apache Foundation and the FSF. Those seem fundamental, but only lightly touched on.
There is no thesis, it is kind of just an organized brain dump of what the author learned working at GitHub.
There were a couple of clarifying ideas -- that producing and consuming are separate, and don't both need to be fully open. Also, why projects gravitate to GitHub.
I would have liked to learn more about the Apache Foundation and the FSF. Those seem fundamental, but only lightly touched on.
December 22, 2023
This might be useful if you have no clue about software engineering and free/libre open source software. However, if you're doing this for a living, you will probably not learn anything new (hence my 3-star rating is biased by my experience).
------------Some notes
# Many noobs vs a few experts
- <2% of contributions overall are from people who make just one commit.
- in ~85% of github projects, <5% of developers were responsible for 95+% of code and social interactions
So, the main problem is not in attracting contributors, but in managing their work effectively.
# ch1
- 45% of open source projects on github use the MIT license.
-
Bill Gates' definition of platform: if the sum of economic value of those who use X exceeds the value of the company that created X.
# ch2 structure of an open source project
## production models
### federation
High contributor growth
High user growth
ESRaymond's "bazaar"
<3% of open source projects are like that, e. g.: Linux, rust
They have processes, councils, voting,... -> to handle coordination issues.
### club
High contributor growth
Low user growth
There are fewer users overall, but they're more likely to be contributors
Ex: astropy, closure, haskell, erlang -> these are rather specialized tools, users are typically more qualified and intrinsically motivated to use and contribute.
Unlike the bazaar, this is more like a small town -> everyone knows everyone.
### toys
Few contributors, few users.
These are personal projects.
### stadium
Few contributors, lots of users.
A centralized structure, centered on a few maintainers, who decide on the behalf of users.
# ch3 roles, incentives and relationships
"I've never met people in cafes, but I never had to leave one because 3 billion people suddenly decided to walk in" Star Simpson
## Design principles that help avoid the tragedy of commons
1. Membership boundaries are clearly defined
2. The rules that govern the commons should match the actual conditions
3. Those affected by the rules can participate in modifying them
4. Those who monitor the rules are either community members or are accountable to it
5. Those who violate the rules are subject to graduated sanctions
6. Conflicts should be resolved within the community, using low cost methods
7. External authorities recognize the right of the community members to devise their own institutions
8. If the commons is a large institution, it is structured as multiple, nested layers of authority
Members should have skin in the game, i.e., have the intention to stay in the community for a while and be interested in its long term future.
What makes it work well
- intrinsic motivation
- tasks must be modular and granular (like in the Unix way)
- low coordination costs
- there's also extrinsic motivation (like reputation or recognition) but as a project matures, these gains flatten out - everyone already knows who you are
Analogy for maintainers - they're expected to always be there and provide updates and support. Imagine that a book author has to make tweaks to the book long after publishing it.
Contributors
- Casual
- active
Users
- active - these open issues and sometimes contribute, maintainers know about them
- passive - lurkers, maintainers have no clue who they are and how many of them are out there.
- some projects have some telemetry to quantify use cases, but it doesn't come without the pushback from some users
Costs of software
- creation
- distribution
- maintenance
Infrastructure costs for pypi: between 2 and 3 million USD /year!
Substitutability: how easy it is to switch from one component to another. For example, when leftpad was removed from npm, a functionally identical package was available within 1h.
# ch5 managing the costs of production
The freerider problem - if you cannot exclude someone from using a product, they'll use it without paying.
A tragedy of the commons can occur. For example - parks will get crowded, grass will be worn out, trashcans will overflow, etc. The solution is to support it via taxes, and through entrance fees.
But what government is supposed to handle this when it comes to distributed open source projects, with contributors all over the world?
Example: restriction on exporting crypto, enforced by the US government.
## The one-way mirror approach to production
People who request features (and do nothing else) create more workload for developers, just looking at the newly opened issue takes time and mental bandwidth. If there's an excess of this, especially from people who do not contribute or have skin in the game -> tragedy of the commons.
Something similar happened to Guido van Rossum and departure from BDFL. Lots of people with an opinion but little to no skin in the game consumed his mental bandwidth.
Alternative idea, treat production like a **one-way mirror**: anyone can see the code and use it, but not necessarily have direct contact with the developers.
As a book author stated: I want people to read my book, I hope they enjoy it, but I don't want to know what they think about it. :-)
## peer source
All projects are private repositories, which only trusted developers are invited to.
The rest could only download the binaries, and keep in mind that there's no accountability to them.
This is a bit like in private torrent trackers, which are invite-only.
## extractive and non-extractive contributions
Extractive: the energy needed to process the contribution exceeds the benefit it brings.
Examples of such contributions: comments, feature requests and questions.
Non-extractive contributions
- small and granular
- easy to review and understand
- require no additional input from maintenaners
- bigger ones that take more energy can still be worth it, if they bring great benefits
Examples of such contributions:
Translations seem to be Non-extractive, but as software evolves - documentation needs to be in sync.
- does the translator promise to keep it up to date?
- do they promise to find someone who will?
# managing a producer's attention
- reduce upfront costs
- make themselves less available
- distribute costs onto users
- increase total attention available
For example, a linter in the CI pipeline provides quick feedback to contributors at no additional cost to the maintainers' attention. Automated tests also help.
Choose a platform that provides features for automation, for example github has "dependabot"
Code style guides also raise the quality bar.
Templates and checklists.
## n=1, limit a producer's attention
Example about Lua. Someone asked if they can open a pull request for Lua, and the author said "yes, but I won't use your code. If I like the idea, I will implement it myself".
This way the project code is consistent, because it comes from the same mind.
Empower users to talk to each other and cooperate to solve their problems - thus the development team is less busy.
Ask contributors to work on their own fork first, this way their work can evolve separately from the project itself, until it matures.
# the role of money in open source
Funders
- institutions
- individuals
Companies tend to value
- code quality
- influence on a project's Roadmap
- brand association
Charge for new versions, give old ones for free.
Pay-to-play: this sometimes happens in federation style projects, big companies try pay to get a seat at the decision-making table, so to speak.
- The apache foundation specifically tries to combat it, by explicitly requiring members to represent themselves, not their employers
The elephant-factor: a measure of how much a project depends on a small set of corporate contributors.
Hacktoberfest - interesting idea, but it attracts casual committers, rather than long-term collaborators who stick around. Casual committers who make low-effort and low-value contributions are already here.
Pay for the work that contributors aren't otherwise incentivized to do.
Fund individuals rather than foundations. For example, would "leftpad" and its 17 lines of code really go out on a limb to start a non-profit foundation?
------------Some notes
# Many noobs vs a few experts
- <2% of contributions overall are from people who make just one commit.
- in ~85% of github projects, <5% of developers were responsible for 95+% of code and social interactions
So, the main problem is not in attracting contributors, but in managing their work effectively.
# ch1
- 45% of open source projects on github use the MIT license.
-
Bill Gates' definition of platform: if the sum of economic value of those who use X exceeds the value of the company that created X.
# ch2 structure of an open source project
## production models
### federation
High contributor growth
High user growth
ESRaymond's "bazaar"
<3% of open source projects are like that, e. g.: Linux, rust
They have processes, councils, voting,... -> to handle coordination issues.
### club
High contributor growth
Low user growth
There are fewer users overall, but they're more likely to be contributors
Ex: astropy, closure, haskell, erlang -> these are rather specialized tools, users are typically more qualified and intrinsically motivated to use and contribute.
Unlike the bazaar, this is more like a small town -> everyone knows everyone.
### toys
Few contributors, few users.
These are personal projects.
### stadium
Few contributors, lots of users.
A centralized structure, centered on a few maintainers, who decide on the behalf of users.
# ch3 roles, incentives and relationships
"I've never met people in cafes, but I never had to leave one because 3 billion people suddenly decided to walk in" Star Simpson
## Design principles that help avoid the tragedy of commons
1. Membership boundaries are clearly defined
2. The rules that govern the commons should match the actual conditions
3. Those affected by the rules can participate in modifying them
4. Those who monitor the rules are either community members or are accountable to it
5. Those who violate the rules are subject to graduated sanctions
6. Conflicts should be resolved within the community, using low cost methods
7. External authorities recognize the right of the community members to devise their own institutions
8. If the commons is a large institution, it is structured as multiple, nested layers of authority
Members should have skin in the game, i.e., have the intention to stay in the community for a while and be interested in its long term future.
What makes it work well
- intrinsic motivation
- tasks must be modular and granular (like in the Unix way)
- low coordination costs
- there's also extrinsic motivation (like reputation or recognition) but as a project matures, these gains flatten out - everyone already knows who you are
Analogy for maintainers - they're expected to always be there and provide updates and support. Imagine that a book author has to make tweaks to the book long after publishing it.
Contributors
- Casual
- active
Users
- active - these open issues and sometimes contribute, maintainers know about them
- passive - lurkers, maintainers have no clue who they are and how many of them are out there.
- some projects have some telemetry to quantify use cases, but it doesn't come without the pushback from some users
Costs of software
- creation
- distribution
- maintenance
Infrastructure costs for pypi: between 2 and 3 million USD /year!
Substitutability: how easy it is to switch from one component to another. For example, when leftpad was removed from npm, a functionally identical package was available within 1h.
# ch5 managing the costs of production
The freerider problem - if you cannot exclude someone from using a product, they'll use it without paying.
A tragedy of the commons can occur. For example - parks will get crowded, grass will be worn out, trashcans will overflow, etc. The solution is to support it via taxes, and through entrance fees.
But what government is supposed to handle this when it comes to distributed open source projects, with contributors all over the world?
Example: restriction on exporting crypto, enforced by the US government.
## The one-way mirror approach to production
People who request features (and do nothing else) create more workload for developers, just looking at the newly opened issue takes time and mental bandwidth. If there's an excess of this, especially from people who do not contribute or have skin in the game -> tragedy of the commons.
Something similar happened to Guido van Rossum and departure from BDFL. Lots of people with an opinion but little to no skin in the game consumed his mental bandwidth.
Alternative idea, treat production like a **one-way mirror**: anyone can see the code and use it, but not necessarily have direct contact with the developers.
As a book author stated: I want people to read my book, I hope they enjoy it, but I don't want to know what they think about it. :-)
## peer source
All projects are private repositories, which only trusted developers are invited to.
The rest could only download the binaries, and keep in mind that there's no accountability to them.
This is a bit like in private torrent trackers, which are invite-only.
## extractive and non-extractive contributions
Extractive: the energy needed to process the contribution exceeds the benefit it brings.
Examples of such contributions: comments, feature requests and questions.
Non-extractive contributions
- small and granular
- easy to review and understand
- require no additional input from maintenaners
- bigger ones that take more energy can still be worth it, if they bring great benefits
Examples of such contributions:
Translations seem to be Non-extractive, but as software evolves - documentation needs to be in sync.
- does the translator promise to keep it up to date?
- do they promise to find someone who will?
# managing a producer's attention
- reduce upfront costs
- make themselves less available
- distribute costs onto users
- increase total attention available
For example, a linter in the CI pipeline provides quick feedback to contributors at no additional cost to the maintainers' attention. Automated tests also help.
Choose a platform that provides features for automation, for example github has "dependabot"
Code style guides also raise the quality bar.
Templates and checklists.
## n=1, limit a producer's attention
Example about Lua. Someone asked if they can open a pull request for Lua, and the author said "yes, but I won't use your code. If I like the idea, I will implement it myself".
This way the project code is consistent, because it comes from the same mind.
Empower users to talk to each other and cooperate to solve their problems - thus the development team is less busy.
Ask contributors to work on their own fork first, this way their work can evolve separately from the project itself, until it matures.
# the role of money in open source
Funders
- institutions
- individuals
Companies tend to value
- code quality
- influence on a project's Roadmap
- brand association
Charge for new versions, give old ones for free.
Pay-to-play: this sometimes happens in federation style projects, big companies try pay to get a seat at the decision-making table, so to speak.
- The apache foundation specifically tries to combat it, by explicitly requiring members to represent themselves, not their employers
The elephant-factor: a measure of how much a project depends on a small set of corporate contributors.
Hacktoberfest - interesting idea, but it attracts casual committers, rather than long-term collaborators who stick around. Casual committers who make low-effort and low-value contributions are already here.
Pay for the work that contributors aren't otherwise incentivized to do.
Fund individuals rather than foundations. For example, would "leftpad" and its 17 lines of code really go out on a limb to start a non-profit foundation?
May 26, 2024
Read because I worked a bunch with open source transit software and ultimately really liked this. Great description of her career and a digestible intro to open source. Crazy how all of today’s transit standards are governed via GitHub! Motivated me to continue working on and improving transit data
November 23, 2021
For me, the most interesting aspect of the book is the paradigm shift that it describes. Not only is the majority of open source not produced by communities but individual programmers. But the consumption of open source has also changed, and there are much more users than contributors.
It was also interesting to read and realize that maintenance is the most costly part of an open source project. Especially as a project grows and as it attracts more users, the communication overhead through issues and pull request can quickly consume most if not all the time of a maintainer.
Finally, it is an interesting observation that successful open source developers share many similarities with content creators. They build reputation, and attract fans and sponsors to support their work. And they are not supported based on the work they do but their public persona.
What I am missing from the book, and what I would have expected based on the title, is a bit more guidance for open source developers on how to apply the lessons from the book. Especially how to set myself up for success as a solo dev. How can I take the insights from the book to set up the project in such a way that I can manage my attention? I have a lot of ideas now, but just a bit of guidance would've been nice.
It was also interesting to read and realize that maintenance is the most costly part of an open source project. Especially as a project grows and as it attracts more users, the communication overhead through issues and pull request can quickly consume most if not all the time of a maintainer.
Finally, it is an interesting observation that successful open source developers share many similarities with content creators. They build reputation, and attract fans and sponsors to support their work. And they are not supported based on the work they do but their public persona.
What I am missing from the book, and what I would have expected based on the title, is a bit more guidance for open source developers on how to apply the lessons from the book. Especially how to set myself up for success as a solo dev. How can I take the insights from the book to set up the project in such a way that I can manage my attention? I have a lot of ideas now, but just a bit of guidance would've been nice.
December 20, 2020
this book provides a summary of the social and economic characteristics of open-source communities + lots of interesting frameworks for describing those dynamics.
eghbal is a very clear writer and assumes no prior knowledge, which is both very helpful and can make parts a bit dry if you're already familiar with the topics -- i'd imagine that everyone will end up skimming some parts. this book is also quite specific to github culture, so i'd make sure you're excited about that before reading (somehow i didn't think this through lol).
eghbal is a very clear writer and assumes no prior knowledge, which is both very helpful and can make parts a bit dry if you're already familiar with the topics -- i'd imagine that everyone will end up skimming some parts. this book is also quite specific to github culture, so i'd make sure you're excited about that before reading (somehow i didn't think this through lol).
September 20, 2023
The title of this book suggests that by reading it you will learn about open source development, but in reality by reading it you will gain a much deeper understanding of how communities behave online. Eghbal's detail on the motivations, frustrations, and impact of open source developers offers a window into the factory of public works in the modern era, with implications from academic science to media. I can't recommend this book highly enough.
September 8, 2020
For technical people: It won't teach you anything new. But the last chapter is totally worth it.
For non-technical people: It will be an awesome read if you want to understand everything about OSS.
For non-technical people: It will be an awesome read if you want to understand everything about OSS.
December 28, 2021
Great overview of the world of open source software - history, current state and potential futures. The book also helped me understand the unique culture of open source. I enjoyed this thoroughly.
September 6, 2021
I liked the book when I picked it up. This is an interesting topic not covered by a wide range of authors. But the impression quickly deteriorated as I found Eghbal’s thoughts increasingly hard to follow. The material seems to come together in a stream of consciousness, and Eghbal went off on a tangent of bringing in concepts that she doesn’t fully understand.
For example, in Chapter 4 The Work Required by Software, Eghbal started with the idea that software requires maintenance, the issues generated by the need for maintenance, and active state vs static state. Then she introduced the idea of private goods vs club goods vs commons vs public goods, before venturing into viewing open source as physical infrastructure. From there she wandered off into valuing software, code as a living organism, maintenance costs, compensation for maintainers. These ideas are loosely grouped under “the work”, or rather, maintenance work, but they were neither adequately linked together nor sufficiently developed on their own. It is almost like Eghbal wanted to write a series of Twitter threads, and found a way to group these threads together to publish a book. By the way, Chapter 5 repeated the same themes of public vs private goods, maintainer compensation, among others. Readers are dragged into a similar state of confusion, all over again.
The book also borrows profusely from multidisciplinary resources without critically assessing the utility of those theories. For example, comparing maintainers with keystone species is one of those shallow engagements that just turned out to be wrong. It is easy to say maintainers are like wolves in the ecosystem - but where are the deers? Similarly, Eghbal cited Jane Jacobs’ The Death and Life of Great American Cities, in order to introduce Weaver’s “problems of simplicity, disorganized complexity, and organized complexity”. After a regurgitation of Weaver’s ideas in the context of city planning, Eghbal casually made a comment that software codes resemble organized complexity. Then the idea stopped right there. Readers are left in a state of utter confusion of why a blitz of Jane Jacobs was offered in the first place. Don’t get me wrong - Jane Jacbos’ book is a classic and she was a phenomenal writer. But how is this relevant at all to open source software?
Another example is borrowing from Eugene Wei’s idea of “status-as-a-service” as a potential way to compensate maintainers. While the idea itself is of course underdeveloped as it is just a blogpost, Eghbal decided to appropriate it anyways. Predictably, her thoughts quickly drifted to GitHub’s constraints in measuring status, before going on to another loosely related topic. There is no in-depth discussion of how status-as-a-service can be implemented, how it differs from traditional compensation models, the economics of such models...There are many ways to further the idea but she has done none of them. While on Twitter, these ideas could sound smart and attract eyeballs, extrapolating them into a book fully exposes how shallow these ideas really are.
If one has limited knowledge about open source, this book has some relevant information. But overall it is a failure and a big disappointment.
For example, in Chapter 4 The Work Required by Software, Eghbal started with the idea that software requires maintenance, the issues generated by the need for maintenance, and active state vs static state. Then she introduced the idea of private goods vs club goods vs commons vs public goods, before venturing into viewing open source as physical infrastructure. From there she wandered off into valuing software, code as a living organism, maintenance costs, compensation for maintainers. These ideas are loosely grouped under “the work”, or rather, maintenance work, but they were neither adequately linked together nor sufficiently developed on their own. It is almost like Eghbal wanted to write a series of Twitter threads, and found a way to group these threads together to publish a book. By the way, Chapter 5 repeated the same themes of public vs private goods, maintainer compensation, among others. Readers are dragged into a similar state of confusion, all over again.
The book also borrows profusely from multidisciplinary resources without critically assessing the utility of those theories. For example, comparing maintainers with keystone species is one of those shallow engagements that just turned out to be wrong. It is easy to say maintainers are like wolves in the ecosystem - but where are the deers? Similarly, Eghbal cited Jane Jacobs’ The Death and Life of Great American Cities, in order to introduce Weaver’s “problems of simplicity, disorganized complexity, and organized complexity”. After a regurgitation of Weaver’s ideas in the context of city planning, Eghbal casually made a comment that software codes resemble organized complexity. Then the idea stopped right there. Readers are left in a state of utter confusion of why a blitz of Jane Jacobs was offered in the first place. Don’t get me wrong - Jane Jacbos’ book is a classic and she was a phenomenal writer. But how is this relevant at all to open source software?
Another example is borrowing from Eugene Wei’s idea of “status-as-a-service” as a potential way to compensate maintainers. While the idea itself is of course underdeveloped as it is just a blogpost, Eghbal decided to appropriate it anyways. Predictably, her thoughts quickly drifted to GitHub’s constraints in measuring status, before going on to another loosely related topic. There is no in-depth discussion of how status-as-a-service can be implemented, how it differs from traditional compensation models, the economics of such models...There are many ways to further the idea but she has done none of them. While on Twitter, these ideas could sound smart and attract eyeballs, extrapolating them into a book fully exposes how shallow these ideas really are.
If one has limited knowledge about open source, this book has some relevant information. But overall it is a failure and a big disappointment.
March 12, 2021
This is an amazing book!!! It provides a deep and thorough analysis of open source motivations and intriguing predictions of possible creator-style funding models from institutions and individuals.
I think the author strongly leaned on the creator model model as we are now seeing that model taking off in spades for many creators at large. However, I wonder if there is something different about open source software development. Yes, it does is seems plausible to support rock star open source prominent developers doing live coding sessions and to see what they code up next. I will love to see more and more things like github/sponsors and gitcoin grants+leagues. However, I think we should still look for more opportunities to fund open source, given its immense value and how underfunded it is now.
It seems a bit different when a funder to subscribes as a Patreon for a podcaster or artist who produces writing works, or visual arts, or video guides. Funders who are corporations or open-source developers institutions, also ultimately care are their use of quality open source in their livelihood and products in many commercially monetized uses!! I wonder if open source funding can also fruitfully capture some portion of the value of the "use" of open source. It's really tough, of course, as money in open source always raises issues that Ms. Eghbal correctly analyzes about assessing value derived and substitutability for the multitudes of open source libraries typically composed into products. Still, it seems like a worthy goal to strive for.
After all, cloud providers are taking in over $90B in revenue annually at the end of 2020 and benefit massively from the open-source ecosystem that runs on it. It only seems fair to have some funding kick into open source more directly from that stream of revenue. This book gives a lot of food for thought on the tricky minefield that would need to be tackled in any such system in order to avoid harming the delicate balance of incentives that drive open source creators.
I think the author strongly leaned on the creator model model as we are now seeing that model taking off in spades for many creators at large. However, I wonder if there is something different about open source software development. Yes, it does is seems plausible to support rock star open source prominent developers doing live coding sessions and to see what they code up next. I will love to see more and more things like github/sponsors and gitcoin grants+leagues. However, I think we should still look for more opportunities to fund open source, given its immense value and how underfunded it is now.
It seems a bit different when a funder to subscribes as a Patreon for a podcaster or artist who produces writing works, or visual arts, or video guides. Funders who are corporations or open-source developers institutions, also ultimately care are their use of quality open source in their livelihood and products in many commercially monetized uses!! I wonder if open source funding can also fruitfully capture some portion of the value of the "use" of open source. It's really tough, of course, as money in open source always raises issues that Ms. Eghbal correctly analyzes about assessing value derived and substitutability for the multitudes of open source libraries typically composed into products. Still, it seems like a worthy goal to strive for.
After all, cloud providers are taking in over $90B in revenue annually at the end of 2020 and benefit massively from the open-source ecosystem that runs on it. It only seems fair to have some funding kick into open source more directly from that stream of revenue. This book gives a lot of food for thought on the tricky minefield that would need to be tackled in any such system in order to avoid harming the delicate balance of incentives that drive open source creators.
August 23, 2022
I kinda liked this book, and I've recommended it to a few people, but this is one of those books where I have a lot of trouble discerning whether there's a good audience for it. I think Eghbal does an OK job of trying to explain the subcultures she's talking about but also get into the meat of some issues that are very much inside baseball. I guess it's aimed at mainly programmers who use open source libraries, but don't participate in the open source community?
For me, a lot of what she's talking about is simply obvious because I've seen most of it in my day-to-day life. For people not like me, I'm not sure if there's enough context to really understand what's going on.
The most useful information I think I got from here was about some of the dynamics of open source projects. Eghbal lays out a pretty good case for why in a lot of cases getting more participation in a project can be problematic, since dealing with a flood of drive-by contributors can really soak up the time of the small number of maintainers whose time would be better spent maintaining the software directly. There are some interesting and tricky dynamics at play with regards to access, attention and money, and Eghbal does a good job exploring the space. Unfortunately I don't think there are good solutions to a lot of the problems (yet), and there is approximately zero chance that a book like this will be read and understood widely enough to make much of a dent in the expectations mismatch (e.g. "These maintainers are such jerks, I opened an issue/PR and it was closed because of XYZ. Open source is a joke." — the general public thinks that projects are limited by the time it takes to implement features and bugfixes, but maintainers know that these are usually not the bottlenecks in maintenance).
Despite my generally pessimistic view that this book is probably not compelling enough for the people who need to read it (the general public) and not focused enough for the people more likely to take lessons from it (maintainers), I do hope that more books like this are written in the future.
For me, a lot of what she's talking about is simply obvious because I've seen most of it in my day-to-day life. For people not like me, I'm not sure if there's enough context to really understand what's going on.
The most useful information I think I got from here was about some of the dynamics of open source projects. Eghbal lays out a pretty good case for why in a lot of cases getting more participation in a project can be problematic, since dealing with a flood of drive-by contributors can really soak up the time of the small number of maintainers whose time would be better spent maintaining the software directly. There are some interesting and tricky dynamics at play with regards to access, attention and money, and Eghbal does a good job exploring the space. Unfortunately I don't think there are good solutions to a lot of the problems (yet), and there is approximately zero chance that a book like this will be read and understood widely enough to make much of a dent in the expectations mismatch (e.g. "These maintainers are such jerks, I opened an issue/PR and it was closed because of XYZ. Open source is a joke." — the general public thinks that projects are limited by the time it takes to implement features and bugfixes, but maintainers know that these are usually not the bottlenecks in maintenance).
Despite my generally pessimistic view that this book is probably not compelling enough for the people who need to read it (the general public) and not focused enough for the people more likely to take lessons from it (maintainers), I do hope that more books like this are written in the future.
Displaying 1 - 30 of 115 reviews