1/ Eric Raymond's paper "The Cathedral and the Bazaar" is an excellent primer on how to run an open source software project and one of the founding texts of the open source movement. It's also incredibly good advice for writing a book.
2/ Raymond uses a helpful metaphor of building a cathedral to talk about "closed source" development and building a bazaar as the metaphor for open source.
3/ The paper was influential in convincing Netscape to open source their code in 1998. 20 years later, that software is called Mozilla and is still one of the three largest browsers in the world. Here's some highlights...
4/ Good programmers know what to write. Great ones know what to rewrite and reuse. (This is also true for writers. Nearly every good piece of writing is just remixing existing ideas.) 
5/ When you start an open source project, plan to throw the first version away. You don't actually understand the problem until the first time you try to implement a solution.
6/ When you start writing a book, give yourself permission to write a shitty first draft. You'll figure out what you're trying to say.
7/ Treating your users as co-developers is the least-hassle route rapid code improvement and effective debugging. Treating readers as co-writers and taking their feedback seriously will debug your arguments.
8/ Release early, release often and listen to your customers - even for major projects like the Linux Kernel or a book, you will end with a stronger project if you release aggressively.
9/ When he was developing Linux, Linus Torvalds sometimes released multiple times per day which kept his users rewarded by constantly seeing improvements he made based on their work.
10/ I think this is why so much of crypto happens on Twitter. The speed at which the industry moves is well-suited for micro-blogging which encourages releasing early and often. (I.e. the medium is the message)
11/ Given a large enough beta-tester and co-developer base, almost all bugs are shallow.
12/ One of the reasons this is true is because you are able to form a marketplace - one user can identify a problem and someone else can understand how to fix it.
13/ The Delphi Effect - the averaged opinion of a mass of equally expert or ignorant observers is surprisingly effective for taming highly complex projects.
14/ The corollary to the Delphi Effect is probably Joy's Law
15/ If you treat beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
16/ The next best thing to having good ideas is recongizing good ideas from your users. Sometimes the latter is better.
17/ Often, the most striking and innovative solutions come from realizing that your conception of the problem is wrong and needs reframing.
