The document discusses resources for open source software projects, including version control systems like Git, SVN, and Mercurial, and hosting services like SourceForge, Launchpad, Google Code, and GitHub. It provides an overview of each option and recommends choosing a hosting service or self-hosting based on the size of the project. Distributed version control systems are preferred over centralized ones. The document also stresses the importance of configuration and community engagement.
32. or if it's not licensed "appropriately"
33. or even if you just can't get through to someone involved in that project then you could consider forking the existing project, or start a new, yet similar, project.
34.
35. GPL requires every sold or supplied change to be re-released as GPL, and that anything which uses it at compile time is also GPL licensed.
36. LGPL requires every sold or supplied change to be re-released as LGPL. Compile-time linked files do not need to be LGPL licensed.
37.
38.
39. Self hosting is better for larger projects, or for non-public development.
40.
41.
42.
43. Your main choices are: Sourceforge, Launchpad, Google Code, Github, Gitorious
44. For more options, see http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities
90. If you are developing anything collaboratively, then you should use some form of Version Control Software – whether it's centrally stored, such as CVS, Visual Source Safe or Subversion, or if it's distributed, like Bazaar, Git, Mercurial (Hg) or svk.
91. Even if you're developing something in isolation, Version Control Software can help you recover from disasters in your code and help you to document thought processes.
92.
93. CVS is the successor to the single-system RCS. Both of these have been phased out by MOST projects. It's very easy to get in a tangle with CVS.
94. SVN is what most people use for centrally managed Version Control. Most of the Distributed Version Control systems will integrate with SVN because of it's popularity.
95.
96. By developing against a locally held version of the repository, small incremental changes can be rapidly committed, reversed and patched before finally making those changes available to all the other developers.
97. Most developers still work on-line, even though they are able to work off-line and will store their finished changes on a central server.
98. I find it more logical to work with a distributed VCS now than a central VCS.
99. My last two projects were totally managed using a distributed VCS.
100.
101. Whatever is left after that, make sure all the configuration makes sense to you! There's nothing worse than trying to submit a ticket about a web application, and trying to decide whether the issue is due to it being a Linux, Windows or Mac box! Likewise, if you're not using version numbers, don't ask your users to include the release version they're using!
102. Make any data about your project as open as possible – use mailing lists for code commits, new tickets and wiki changes.
103. If you can cope with the workload – blog, tweet or dent about it at every RELEVANT opportunity! Software houses do, why shouldn't you?
104.
105. Please feel free to ask any questions now, elsewhere today, or on email, Google Talk (XMPP) or MSN to jon@spriggs.org.uk