What do you think?
Rate this book
Producing Open Source Software
The corporate market is now embracing free, "open source" software like never before, as evidenced by the recent success of the technologies underlying LAMP (Linux, Apache, MySQL, and PHP). Each is the result of a publicly collaborative process among numerous developers who volunteer their time and energy to create better software.
The truth is, however, that the overwhelming majority of free software projects fail. To help you beat the odds, O'Reilly has put together "Producing Open Source Software," a guide that recommends tried and true steps to help free software developers work together toward a common goal. Not just for developers who are considering starting their own free software project, this book will also help those who want to participate in the process at any level.
The book tackles this very complex topic by distilling it down into easily understandable parts. Starting with the basics of project management, it details specific tools used in free software projects, including version control, IRC, bug tracking, and Wikis. Author Karl Fogel, known for his work on CVS and Subversion, offers practical advice on how to set up and use a range of tools in combination with open mailing lists and archives. He also provides several chapters on the essentials of recruiting and motivating developers, as well as how to gain much-needed publicity for your project.
While managing a team of enthusiastic developers -- most of whom you've never even met -- can be challenging, it can also be fun. "Producing Open Source Software" takes this into account, too, as it speaks of the sheer pleasure to be had from working with a motivated team of free software developers.
The truth is, however, that the overwhelming majority of free software projects fail. To help you beat the odds, O'Reilly has put together "Producing Open Source Software," a guide that recommends tried and true steps to help free software developers work together toward a common goal. Not just for developers who are considering starting their own free software project, this book will also help those who want to participate in the process at any level.
The book tackles this very complex topic by distilling it down into easily understandable parts. Starting with the basics of project management, it details specific tools used in free software projects, including version control, IRC, bug tracking, and Wikis. Author Karl Fogel, known for his work on CVS and Subversion, offers practical advice on how to set up and use a range of tools in combination with open mailing lists and archives. He also provides several chapters on the essentials of recruiting and motivating developers, as well as how to gain much-needed publicity for your project.
While managing a team of enthusiastic developers -- most of whom you've never even met -- can be challenging, it can also be fun. "Producing Open Source Software" takes this into account, too, as it speaks of the sheer pleasure to be had from working with a motivated team of free software developers.
302 pages, Kindle Edition
First published October 7, 2005
30 people are currently reading
405 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 - 28 of 28 reviews
July 27, 2017
This is a great book for anyone interested in understanding, collaborating or managing the production of open source software -my only regret is not having read it ten years ago. It is true that some sections and references of the first edition are now outdated but fortunately, Fogel recently wrote a second open access edition (2017) of this book. In the ten or so years between the two editions, Fogel worked as a consultant on several open source software projects including several projects with government participation. As he points out in his introduction:
The first edition’s appendices on free version control systems, free bug trackers, example instructions for reporting bugs, and a funny and pertinent post by Poul-Henning Kamp (“Why should I care what color the bikeshed is?�) based on Northcote’s Parkinson’s 1957 so-called “law of triviality� which claims that members of an organization give disproportionate weight to trivial issues have been eliminated and replaced by an appendix which provides the standard summary and the full legal version of the Creative Commons Attribution-ShareAlike 4.0 International License..
The introduction (chapter one) provides a brief outline of key concepts (open-source, free, libre software) and the history of open source software (OSS). The first edition was fresher and cheekier. Compare the titles to the chapter 5 in the first edition (“Money�) to the title for the same chapter in the second edition (“Participating as a Business, Non-Profit, or Government Agency�); compare the opening sentence of the introduction in the first edition with its attention grabbing:
The second chapter, Getting started in on how to start an open source software project, from tips on naming the project to hints on where to host the project. In the second edition Fogel immediately gets down to brass tacks:
Fogel clearly states the importance of Chapter 3 (Technical Infrastructure):
Chapter 4 (Social and Political Infrastructure) covers the political structure of the project, that is to say whether the OSS organization is built around so-called “benevolent dictators� (a la Linux) or a consensus-based democracy. This is a very interesting chapter, which has changed very little from the first to the second edition -a short but very pertinent section, Joining or Creating a Non-Profit Organization has been added. I cannot resist quoting the first two paragraphs of this chapter:
Chapter 6 (Communications) is one of the best chapters in the book and has certainly aged well. It provides advice on how to build and maintain an appropriate written culture taking particular pains with topics such as how to distinguish between terseness and rudeness, how to deal with rudeness, handling difficult people, unproductive discussion threads, publicity, the proper use of forums, and invaluable advice on how to report on security vulnerabilities and their fixes.
I particularly enjoyed the clarity and preciseness of chapter 7 (Packaging, Releasing, and Daily Development) -it also has the robust imprint of the trenches about it.
Managing volunteers (chapter 8) has become Managing participants, which is politically more correct -not everyone involved in an OSS project is a volunteer- but Fogel does not really add much to the first edition’s chapter. He briefly but effectively singles out several key roles: patch manager, translation manager, documentation manager, and issue manager. The author warns the reader that the chapter is a grab-bag of techniques, but even so, I consider it is well pulled together.
The last chapter is on legal matters and is a nice, brief overview of this key topic.
As I wrote previously, I miss the appendices on free version control systems and free bug trackers, eve though I understand that the number of such tools has grown a lot, and that such lists can quickly become outdated. However, Fogel adds quite a number of up to date references throughout the book which probably have just as short a half life�
Fogel’s book is still very much worth reading, and if you are not very familiar with OSS projects or Fogel's first edition, I recommend you go straight to the second edition. If you are familiar with the first edition and have been working on OSS projects, I would recommend cherry picking the new sections -there are some nice new nuggets of advice, but in my opinion, in general they do not snap together as well as they did in the first edition.
One of the great surprises for me in preparing the second edition of this book was realizing that, on the whole, experience indicates that governments are less suited to participating in free software projects than for-profit corporations are, with non-profits somewhere in between the two. There are many reasons for this (see the section called “Governments and Open Source�), and the problems are certainly surmountable, but it's worth noting that when an existing organization � particularly a hierarchical one, and particularly a hierarchical, risk-averse, and publicity-sensitive one � starts or joins an open source project, the organization will usually have to make some adjustments.Both editions are organized into 9 chapters, titled:
- 1. IntroductionIn the first edition more space is devoted to Technical Infrastructure (42 pages), Communications (42 pages), and Managing Volunteers (40 pages); in the second edition more space is devoted to Technical Infrastructure (36 pages), Participating as a Business, Non-Profit, or Government Agency (33 pages, up from Money’s 22 pages in the first edition), Communications (30 pages), and Managing Participants (27 pages).
- 2. Getting started
- 3. Technical infrastructure
- 4. Social and political infrastructure
- 5. Money [extensively rewritten and expanded in the second edition, and retitled as “Participating as a Business, Non-Profit, or Government Agency”].
- 6. Communications
- 7. Packaging, releasing and daily development
- 8. Managing volunteers [renamed Managing participants in the second edition, in order to underscore that not only volunteers work on open source projects]
- 9. Licenses, copyrights, and patents [Retitled “Legal matters: licenses, copyrights, trademarks, and patents in the second edition]
The first edition’s appendices on free version control systems, free bug trackers, example instructions for reporting bugs, and a funny and pertinent post by Poul-Henning Kamp (“Why should I care what color the bikeshed is?�) based on Northcote’s Parkinson’s 1957 so-called “law of triviality� which claims that members of an organization give disproportionate weight to trivial issues have been eliminated and replaced by an appendix which provides the standard summary and the full legal version of the Creative Commons Attribution-ShareAlike 4.0 International License..
The introduction (chapter one) provides a brief outline of key concepts (open-source, free, libre software) and the history of open source software (OSS). The first edition was fresher and cheekier. Compare the titles to the chapter 5 in the first edition (“Money�) to the title for the same chapter in the second edition (“Participating as a Business, Non-Profit, or Government Agency�); compare the opening sentence of the introduction in the first edition with its attention grabbing:
Most free software projects fail.to the more stolid opening to the second edition’s introduction:
Free software � open source software � has become the backbone of modern information technology. It runs on your phone, on your laptop and desktop computers, and in embedded microcontrollers for household appliances, automobiles, industrial machinery and countless other devices that we too often forget even have software. Open source is especially prevalent on the servers that provide online services on the Internet. Every time you send an email, visit a web site, or call up some information on your smartphone, a significant portion of the activity is handled by open source software.I miss the note of impertinence even as I acknowledge the truth -and even the need for the more stolid note on the importance of open source software. Still both introductions work and quickly set the tone for the book’s emphasis on the useful, practical and uncluttered rather than historical detail or theoretical frameworks.
The second chapter, Getting started in on how to start an open source software project, from tips on naming the project to hints on where to host the project. In the second edition Fogel immediately gets down to brass tacks:
Starting a free software project is a twofold task. The software needs to acquire users, and to acquire developers.This immediately draws attention to the key issue in this stage. The first edition needs five previous paragraphs to reach the same sentence -the second edition can be tighter than the first. Fogel has also taken care to update references; for example the first edition’s references to freshmeat.com as a directory for OSS is replaced by references to , , , and the Free Software F Foundation at . I recommend you pay particular attention to the section Setting the tone, whose key recommendations are (1) hold open discussions on the project and avoid private ones, (2) nip rudeness in the bud, (3) adopt a code of conduct, and (4) practice conspicuous code reviews. The main addition to the second edition is a timely new section on Opening a Formerly Closed Project.
Fogel clearly states the importance of Chapter 3 (Technical Infrastructure):
Free software projects rely on technologies that support the selective capture and integration of information. The more skilled you are at using these technologies, and at persuading others to use them, the more successful your project will be.Fogel correctly moves the section on on web sites for OSS projects from last to first place, and breezily covers mailing lists, version control, bug tracking, IRC/Real-time chat systems, and wikis -remember wikis were new and uncharted territory in 2006. Quite rightly, in the second edition sections -albeit very brief ones- are added on Q&A forums, translation infrastructure, and social networking services.
Chapter 4 (Social and Political Infrastructure) covers the political structure of the project, that is to say whether the OSS organization is built around so-called “benevolent dictators� (a la Linux) or a consensus-based democracy. This is a very interesting chapter, which has changed very little from the first to the second edition -a short but very pertinent section, Joining or Creating a Non-Profit Organization has been added. I cannot resist quoting the first two paragraphs of this chapter:
The first questions people usually ask about free software are "How does it work? What keeps a project running? Who makes the decisions?" I'm always dissatisfied with bland responses about meritocracy, the spirit of cooperation, code speaking for itself, etc. The fact is, the question is not easy to answer. Meritocracy, cooperation, and running code are all part of it, but they do little to explain how projects actually run on a day-to-day basis, and say nothing about how conflicts are resolved.The difference between the two editions as regards the book’s fifth chapter is clearly set out in the title, Money versus Participating as a Business, Non-Profit, or Government Agency and the opening sentences in the first edition:
This chapter tries to show the structural underpinnings successful projects have in common. I mean "successful" not just in terms of technical quality, but in terms of operational health and survivability. Operational health is the project's ongoing ability to incorporate new code contributions and new developers, and to be responsive to incoming bug reports. Survivability is the project's ability to exist independently of any individual participant or sponsor � think of it as the likelihood that the project would continue even if all of its founding members were to move on to other things1. Technical success is not hard to achieve, but without a robust developer base and social foundation, a project may be unable to handle the growth that initial success brings, or the departure of charismatic individuals.
This chapter examines how to bring funding into a free software environment.and in the second edition:
This chapter examines how to use money and organizational capacity constructively in a free software environment. It also discusses some of the adjustments your organization may need to make as it gets involved in free software projects.However in the second edition, Fogel provides a caveat that applies to both editions:
This chapter is not primarily about how to find funding sources for your open source project, though Ihope it will usefully inform that topic.The chapter is more about the tensions, challenges and opportunities that arise when funding is sought for or made available for an OSS project, some developers are paid for their contributions or for profit companies or government agencies sponsor or otherwise participate or become involved in an OSS effort. In my opinion it is one of the most interesting chapters in the book and one whose contents have most changed in line with the evolving nature of corporate involvement -as can be exemplified by some of Google’s projects:
Google's Android operating system is a classic example: Google maintains its own copy of Android, which it governs as it pleases, and from time to time merges changes between that copy and the Android Open Source Project (). Essentially, Google is on a very long copy-modify-merge loop with respect to the open source project, and vice versa. It is in neither side's interests to permanently diverge from the other.Whereas some kinds of involvement have continued to thrive (e.g. sharing the burden of development, augmenting services, supporting hardware sales, undermining a competitor, brand management, dual licensing, and donations), some new ways have also either risen or become more popular (e.g. establishing a standard, creating an ecosystem). I must admit however that many of the new sections added to this chapter in order to accommodate the involvement of government agencies seemed rather disjointed, in spite of some excellent nuggets of advice. The addition of some very sensible rules of thumb in a new section titled Evaluating Open Source Projects is particularly welcome, but seems rather out of place -shouldn’t it have been added to chapter 2 (Getting started)?
Chapter 6 (Communications) is one of the best chapters in the book and has certainly aged well. It provides advice on how to build and maintain an appropriate written culture taking particular pains with topics such as how to distinguish between terseness and rudeness, how to deal with rudeness, handling difficult people, unproductive discussion threads, publicity, the proper use of forums, and invaluable advice on how to report on security vulnerabilities and their fixes.
I particularly enjoyed the clarity and preciseness of chapter 7 (Packaging, Releasing, and Daily Development) -it also has the robust imprint of the trenches about it.
Managing volunteers (chapter 8) has become Managing participants, which is politically more correct -not everyone involved in an OSS project is a volunteer- but Fogel does not really add much to the first edition’s chapter. He briefly but effectively singles out several key roles: patch manager, translation manager, documentation manager, and issue manager. The author warns the reader that the chapter is a grab-bag of techniques, but even so, I consider it is well pulled together.
The last chapter is on legal matters and is a nice, brief overview of this key topic.
As I wrote previously, I miss the appendices on free version control systems and free bug trackers, eve though I understand that the number of such tools has grown a lot, and that such lists can quickly become outdated. However, Fogel adds quite a number of up to date references throughout the book which probably have just as short a half life�
Fogel’s book is still very much worth reading, and if you are not very familiar with OSS projects or Fogel's first edition, I recommend you go straight to the second edition. If you are familiar with the first edition and have been working on OSS projects, I would recommend cherry picking the new sections -there are some nice new nuggets of advice, but in my opinion, in general they do not snap together as well as they did in the first edition.
October 10, 2016
Karl gives here advices on running open source software projects, and illustrates his ideas with stories from the development of Subversion (the source control system), as he was one of the main developer. I found the text easy to read, providing interesting thoughts about what make open-source projects special.
Yet, in my opinion, the book suffer several issues. First, it is out-of-date. The text definitely needs to be freed from advices on what bug tracker or source control system to use. These changes as times passes by and are simply irrelevant by now. Then, the book talks about large open source projects with hundred of committers, while in my experience, most open source projects are smaller endeavours and I am not sure all advices apply equally on both small and large projects.
Yet, if you have no idea what help open source projects, this book may still give you some hints.
Yet, in my opinion, the book suffer several issues. First, it is out-of-date. The text definitely needs to be freed from advices on what bug tracker or source control system to use. These changes as times passes by and are simply irrelevant by now. Then, the book talks about large open source projects with hundred of committers, while in my experience, most open source projects are smaller endeavours and I am not sure all advices apply equally on both small and large projects.
Yet, if you have no idea what help open source projects, this book may still give you some hints.
Read
October 15, 2008This book was quite helpful. I'm glad to have bought the treeware version instead of just relying on the web. Brought it on the train with me and marked all over it, just not something you can do easily enough with electronics.
What I particularly appreciated about this book is that it points out the kinds of things that could go silently wrong, that is, mistakes that manifest in a series of non-events, like people not using your software, or people not contributing any patches, or people not participating in your mailing lists. You can't tell something has gone wrong, because nothing has happened...
What I particularly appreciated about this book is that it points out the kinds of things that could go silently wrong, that is, mistakes that manifest in a series of non-events, like people not using your software, or people not contributing any patches, or people not participating in your mailing lists. You can't tell something has gone wrong, because nothing has happened...
March 20, 2013
Karl is a wonderful colleague and friend and a brilliant mind. The tenets that he outlines here can be applied not only to open source projects but all sorts of projects, communities, and organizations that want to be structured yet open, productive and efficient yet thoughtful and agile. I have learned (and continue to learn) so very much from Karl and I urge anyone who is curious about open source and how the best open source projects work and grow, to read this book.
July 9, 2011
This book is great for learning about the open source movement. It gives a good description of how random people work together to make free software. It gives lots of details that are also helpful for any general collaborative project. I got this as a surprise from the summer of code.
Want to read
November 7, 2008October 23, 2011
Great book not only for people looking into starting an open source project but even for managers interested in the ins and outs of interacting with the opensource community.
Want to read
September 9, 2016Available as a free ebook in many languages .
January 22, 2016
A very very enlightening book for those who want to get the big picture about open source project management. Totaly recommended for project managers and leaders.
December 2, 2024
A surprisingly frank book on software development with a focus on open-source software. The writing style is such that most of the time each section reads like a story of what was once a checklist. Also the whole book routinely suffers from verbosity and this is evident during the ocassional platitude, such as "the payoff can be huge" or "documentation is essential".
Other omissions, shortcomings or inaccuracies:
* The numerous sections on communication and team development are massive and overbearing.
* There is relatively little on code style standards or source code documentation.
* The recurring sections on licenses treat the the business-type licenses (eg MIT) in a relatively cursory manner. It is not discussed for example that using these licenses opens the organisation up to litigation, either inward or outward.
* Continuous integration is conflated with build farms; the former is a process, the latter a technical implementation.
* No mention is made on the choice of computer architectures that the open source software should support.
* The closed source nature and hence the implications of the use of some of the commercial software vendors is not mentioned, such as terms of use and privacy issues. Github for example has since the acquisition by Microsoft seen many projects being hosted elsewhere, as the project teams felt it violated their established team ground rules.
* Open source, but not openly developed are projects such as SQLite and Lua, but relatively little of the book applies to these projects.
* The section "Sponsoring Conferences, Hackathons, and other Developer Meetings" links to "Conferences, Hackfests, Code-a-Thons, Code Sprints, Retreats" and vice versa, but neither gives much information.
Second edition (2023) freely available on the internet.
Other omissions, shortcomings or inaccuracies:
* The numerous sections on communication and team development are massive and overbearing.
* There is relatively little on code style standards or source code documentation.
* The recurring sections on licenses treat the the business-type licenses (eg MIT) in a relatively cursory manner. It is not discussed for example that using these licenses opens the organisation up to litigation, either inward or outward.
* Continuous integration is conflated with build farms; the former is a process, the latter a technical implementation.
* No mention is made on the choice of computer architectures that the open source software should support.
* The closed source nature and hence the implications of the use of some of the commercial software vendors is not mentioned, such as terms of use and privacy issues. Github for example has since the acquisition by Microsoft seen many projects being hosted elsewhere, as the project teams felt it violated their established team ground rules.
* Open source, but not openly developed are projects such as SQLite and Lua, but relatively little of the book applies to these projects.
* The section "Sponsoring Conferences, Hackathons, and other Developer Meetings" links to "Conferences, Hackfests, Code-a-Thons, Code Sprints, Retreats" and vice versa, but neither gives much information.
Second edition (2023) freely available on the internet.
July 12, 2019
This is an excellent overview of how open source actually works, although definitely skewed towards developers. I liked the frequent use of "she" as a generic term to refer to a (theoretical) developer—although it often switches back to "he" when referring to actual people, for reasons that are probably obvious to anyone who's ever been involved in open-source projects or attended a tech conference.
I would have preferred more of a focus on the interpersonal dynamics and social etiquette of open-source work, and fewer lengthy diatribes about whatever a reply-to is on a mailing list.
I would have preferred more of a focus on the interpersonal dynamics and social etiquette of open-source work, and fewer lengthy diatribes about whatever a reply-to is on a mailing list.
November 9, 2018
This is a decent overview of the components and tools required to run an free software project. Many of the concepts apply to software projects in general, but the focus is free, collaborative projects. It is pretty complete and provides a good set of requirements and expectations for running a software project.
May 16, 2024
Me gustó. El autor siempre contrasta lo que afirma con su experiencia como desarrollador y gestor de proyectos de software libre, lo cual resulta enriquecedor. Las partes sobre infraestructura están obviamente desactualizadas y pueden ser omitidas.
August 23, 2018
Most probably a great book for its time. At this point it’s so outdated that it focus more on things that are irrelevant than bringing something useful.
September 29, 2023
a good and comprehensive view of the technical and social problems that must be dealt with to run an effective free/open source project, clearly based on the author's extensive, hands-on experience.
he covers everything from making the basic decisions about infrastructure, policies and management style, through to the process of dealing with day-to-day issues of developer communication, managing commits, providing useful documentation and rolling releases. he keeps a grounded view of things, acknowledging that even for those projects that do grow beyond the original developer, the extra users and contributors bring their own issues to deal with. it's particularly good at offering diagnostics and solutions for common but subtle problems, such as unproductive conversations sucking up contributor time and good-will.
i made the mistake of reading an old version (2005, last updated in 2011 or so), instead of the second edition that was released about 2 weeks before i started. unsurprisingly, the former is in many ways wildly out of date now, covering a lot of technology that's been superseded. that's not toooo much of a problem, given how much of it transcends specific technology, but it's still a bit of a nostalgia trip at times. (a quick read of the new edition shows these problems have been comprehensively dealt with.)
my only real complaint is that it feels a bit too geared towards very large projects -- while those are the most obvious beneficiaries of a book like this, and it's helpful to be shown the bigger picture when starting out, a lot of it will be overkill for the vast majority of projects. that said, i still found it very enlightening from an end-user perspective, despite my only ever having made passing contributions to particularly large projects (and not currently being a contributor to *any* FOSS projects -- boo!).
he covers everything from making the basic decisions about infrastructure, policies and management style, through to the process of dealing with day-to-day issues of developer communication, managing commits, providing useful documentation and rolling releases. he keeps a grounded view of things, acknowledging that even for those projects that do grow beyond the original developer, the extra users and contributors bring their own issues to deal with. it's particularly good at offering diagnostics and solutions for common but subtle problems, such as unproductive conversations sucking up contributor time and good-will.
i made the mistake of reading an old version (2005, last updated in 2011 or so), instead of the second edition that was released about 2 weeks before i started. unsurprisingly, the former is in many ways wildly out of date now, covering a lot of technology that's been superseded. that's not toooo much of a problem, given how much of it transcends specific technology, but it's still a bit of a nostalgia trip at times. (a quick read of the new edition shows these problems have been comprehensively dealt with.)
my only real complaint is that it feels a bit too geared towards very large projects -- while those are the most obvious beneficiaries of a book like this, and it's helpful to be shown the bigger picture when starting out, a lot of it will be overkill for the vast majority of projects. that said, i still found it very enlightening from an end-user perspective, despite my only ever having made passing contributions to particularly large projects (and not currently being a contributor to *any* FOSS projects -- boo!).
Read
September 29, 2013This book gives exactly what it advertises. It is a detailed look at how to start and manage an open source projects covering issues from version control and email to hosting to people management to working with companies that want to support your project. As such, the book is very useful, but not the most exciting of reads. It is a book that is best read right before you start running an open source project. The chapters are fairly independent, making them easy to reread when you need help with a particular issue.
Now I want to go start a project!
Now I want to go start a project!
December 23, 2010
Don't let the title fool you! While about half the book is specific to (and immensely useful in) running an open-source project, the other half applies to any sort of intentional community. Reflecting the author's experience during the initial creation of the Subversion Version Control System (in which he was a principal community leader and tone-setter), this book has helped me create communities many times, on many topics.
September 10, 2016
The main thing I learned about this book was it's baseline : *most open-source project fails*. It helps me to fail my open source project better.
This is interesting in theory, but not very practical. You can find good advises though.
This is interesting in theory, but not very practical. You can find good advises though.
This entire review has been hidden because of spoilers.
March 8, 2009
It felt a bit dated, but maybe that's just me.
August 22, 2011
If you are starting an Open Source project, or new to contributing to an Open Source project this is a must read.
February 12, 2012
A solid, detailed primer on the nuts and bolts of open source projects.
March 30, 2013
A should-read book on licensing and pricing for the knowledge worker, manager, executive, or entrepreneur.
August 19, 2013
Very good balance between ovierview and practical advise.
Not only suitable fpr open source, but containts also learnings fpr other software projects.
Read it!
Not only suitable fpr open source, but containts also learnings fpr other software projects.
Read it!
July 21, 2016
A handbook for what the title speaks about. Written in a style to be understand to newbies too.
October 17, 2016
A little too verbose for my taste. Still, very insightful at times. If I ever find myself running or starting a substantial free software project, I know where to look for pointers.
February 19, 2014
Generally useful, out of date in parts but still worth thinking about.
April 6, 2017
This is a pretty good book, about the product management side of open source development. This book has very little to do with programming. It's mostly about people. How to manage them and how to get along with them, given the unique challenges of collaborating via email and chat. I found this interesting, although I knew most of it already. It talks about infrastructure, money, communication, packaging and releases, and licensing.
Probably the most interesting part is the discussion of "painting the bike shed." Apparently, there's this effect in management, where people will rubber stamp big decisions while bickering endlessly over trivial ones, like what color to paint the bike shed. People like to feel competent, so they'll all chime in on something they know something about, but on the big decisions they stay quiet because they assume someone else knows what they're doing.
One gripe I had about the book is that he tends to get bogged down in rare corner cases. What if someone says such-and-such? Well, then you should say this. But then, what if they say something else? etc. Also, I'd have liked to see better coverage of open source licenses. That's one of the most important and all-pervasive issues in open source management, and it felt like he glossed over it. For example, he mentions some licenses are compatible with GPL and some aren't, but says nothing about why. More importantly, he's also silent on what kinds of projects are best served by which licenses, aside from the obvious, that libraries should prefer LGPL over GPL.
But otherwise, it was an interesting read. I'd recommend it to anyone who wants to get involved in open source development.
Probably the most interesting part is the discussion of "painting the bike shed." Apparently, there's this effect in management, where people will rubber stamp big decisions while bickering endlessly over trivial ones, like what color to paint the bike shed. People like to feel competent, so they'll all chime in on something they know something about, but on the big decisions they stay quiet because they assume someone else knows what they're doing.
One gripe I had about the book is that he tends to get bogged down in rare corner cases. What if someone says such-and-such? Well, then you should say this. But then, what if they say something else? etc. Also, I'd have liked to see better coverage of open source licenses. That's one of the most important and all-pervasive issues in open source management, and it felt like he glossed over it. For example, he mentions some licenses are compatible with GPL and some aren't, but says nothing about why. More importantly, he's also silent on what kinds of projects are best served by which licenses, aside from the obvious, that libraries should prefer LGPL over GPL.
But otherwise, it was an interesting read. I'd recommend it to anyone who wants to get involved in open source development.
Displaying 1 - 28 of 28 reviews
Can't find what you're looking for?
Get help and learn more about the design.