The book is about using open source and getting smart people outside of your organization to help do your work. I’m just going to quote some parts and leave it to you to see if/how they could be applicable to you.

Something that surprised me was the idea that “open source” is not as new as Linux. Goldman and Gabriel write,

“On Guy Fawkes Day, 1857, Richard Chenevix Trench, addressing the Philological Society, proposed the production of a new, complete English dictionary based on finding the earliest occurrences of each of the English words ever in printed use. That is, the dictionary would be constructed by reading every book ever written and noting down exactly where in each book a significant use of every word occurred; these citations would be used to write definitions and short histories of the words’ uses. In order to do this, Trench proposed enlisting the volunteer assistance of individuals throughout English-speaking countries by advertising for their assistance.

Over a period of 70 years, many hundreds of people sent in over 6 million slips with words and their interesting occurrences in thousands of books. This resulted in the Oxford English Dictionary , the ultimate authority on English, with 300,000 words, about 2.5 million citations, and 8.3 citations per entry in 20 volumes.

Compare this with the best effort by an individual–Samuel Johnson, over a 9-year period, using the same methodology and a handful of assistants called amanuenses , produced a two-volume dictionary with about 40,000 words and in most cases one citation per entry. As we look at these two works, Johnson’s dictionary is a monument to individual effort and a work of art, revealing as much about Johnson as about the language he perceived around him, while the OED is the standard benchmark for dictionaries, the final arbiter of meaning and etymology” (46).

Other excerpts I want to share relate to the notion that “we” the “select few” in the “inner circle” know best how to innovate.

“R&D spending profiles suggest that it is less and less common for innovative people to be found at large companies with virtual monopolies in specific technology areas. Not all the smart people work for you, you cannot afford to try to create all the innovations yourself, and you cannot provide enough triggers internally to find the stunning new product idea. More and more the game is about being connected…” (28).

“A very bad problem occurs when the internal developers do not have respect for the outside developers. If any member of the core team thinks of the outside developers as bozos who should be ignored, then you can be sure that the community will pick up on that attitude and react negatively. You should remember that there are more smart people outside your company than inside it, and one major reason for making your project open source is to be able to engage with such people as much as possible. In an email discussion about a project where the core developers were not engaging with the community, Alan Cox, one of the primary Linux kernel developers, put it like this: “Give feedback and you get more than repaid. Ignore people and you lose them forever.”

This problem can often be seen when core developers refuse to engage with outside developers in design discussions on the project’s mailing lists–often the core developers don’t even read the public mailing lists. Refusing to listen to community concerns hurts the project because it both kills a sense of community and results in developing the wrong product. Keep in mind that approximately half of all software projects fail, not for technical reasons but because they produce a result that does not match the needs of the target audience. Feedback from the community in an open-source project increases the probability that what is produced is what is wanted. Make sure you listen to what your community members say; they are probably right” (p. 261).

Finally, as with Anderson’s Free, there are suggestions about how to make money on open source:

“You cannot charge people to use code that they are writing or have written. That means that you cannot simply take the code and charge money directly for it. You need to choose a business model that supports open source. The following are some classic open-source business models:

•    Bundle open-source software with perhaps some other software and with support, charging for the bundle and for additional testing and quality.
•    Add value in the form of additional modules or surrounding software and sell that additional software bundled with the open-source software.
•    Provide a service based on the open-source software, such as a subscription service that updates customers’ sites with tested and assured code.
•    Sell consulting services that leverage the open-source software.
•    Sell ancillary things such as books, T-shirts, and mugs.
•    Sell hardware that runs the open-source software particularly well.
•    Sell software that uses the open-source software as a platform

…Ubiquity, winning over hearts, thousands of eyes looking over the code, better platform security, and getting additional outside help are some of the reasons to do open source” (37).