notes-books-producingOss

Notes on Producing Open Source Software: How to Run a Successful Free Software Project, by Karl Fogel

"The transience, or rather the potential transience, of relationships is perhaps the single most daunting task facing a new project. What will persuade all these people to stick together long enough to produce something useful? The answer to that question is complex enough to occupy the rest of this book, but if it had to be expressed in one sentence, it would be this:

    People should feel that their connection to a project, and influence over it, is directly proportional to their contributions." -- http://producingoss.com/en/producingoss.html

" The site's appearance signals whether care was taken in organizing the project's presentation. Humans have extremely sensitive antennae for detecting the investment of care. Most of us can tell in one glance whether a web site was thrown together quickly or was given serious thought. This is the first piece of information your project puts out, and the impression it creates will carry over to the rest of the project by association. "

" Although this is not the place for a general treatise on web design, one principle is important enough to deserve mention, particularly when the site serves multiple (if overlapping) audiences: people should have a rough idea where a link goes before clicking on it. For example, it should be obvious from looking at the links to user documentation that they lead to user documentation, and not to, say, developer documentation. "

" Running a project is partly about supplying information, but it's also about supplying comfort. The mere presence of certain standard offerings, in expected places, reassures users and developers who are deciding whether they want to get involved. It says that this project has its act together, has anticipated the questions people will ask, and has made an effort to answer them in a way that requires minimal exertion on the part of the asker. By giving off this aura of preparedness, the project sends out a message: "Your time will not be wasted if you get involved," which is exactly what people need to hear. "

• "Choose a Good Name"
  • "Gives some idea what the project does, or at least is related in an obvious way, such that if one knows the name and knows what the project does, the name will come quickly to mind thereafter."
  • "easy to remember" (for a (possibly non-native) English speaker)
  • "not the same as some other project's name, and does not infringe on any trademarks."
  • "If possible, is available as a domain name in the .com, .net, and .org top-level domains"
• "Have a Clear Mission Statement"
• "Once they've found the project's web site, the next thing people will look for is a quick description, a mission statement, so they can decide (within 30 seconds) whether or not they're interested in learning more. This should be prominently placed on the front page, preferably right under the project's name."
• "The mission statement should be concrete, limiting, and above all, short."
• "The front page must make it unambiguously clear that the project is open source"
• "Features and Requirements List. There should be a brief list of the features the software supports ((list of "features")) (if something isn't completed yet, you can still list it, but put "planned" or "in progress" next to it), and the kind of computing environment required to run the software ((list of "requirements"."
• "Development Status"
  • "and project's near-term goals and needs (for example, it might be looking for developers with a particular kind of expertise)." "can also give a history of past releases, with feature lists, so visitors can get an idea of how the project defines "progress" and how quickly it makes progress according to that definition."
  • "Don't be afraid of looking unready, and don't give in to the temptation to hype the development status....one of the worst things a project can do is attract users before the software is ready for them"
• downloads
  • build and installation methods "should be as convenient, standard, and low-overhead as possible...That sounds obvious, but many projects don't bother to standardize their installation procedures until very late in the game, telling themselves they can do it any time: "We'll sort all that stuff out when the code is closer to being ready." What they don't realize is that by putting off the boring work of finishing the build and installation procedures, they are actually making the code take longer to get ready—because they discourage developers who might otherwise have contributed to the code..Boring work with a high payoff should always be done early, and significantly lowering the project's barrier to entry through good packaging brings a very high payoff."
  • "When you release a downloadable package, it is vital that you give a unique version number to the release"