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.

1. Resources for FLOSS Projects By Jon “The Nice Guy” Spriggs Presented first at OggCamp '10

3. I'm a Firewall Engineer by day

4. I write mediocre PHP projects by night

5. I've started around 10 Open Source Projects

6. You're likely not to have ever used any of them

7. Except one – perhaps!

9. You're a FLOSS developer who's started a project before and wants to know what else is out there

10. You've heard of me (Hi mum!) and want to hear me talk!

13. I first started contributing to Free Software in 2001 when I released some re-written code for PHP-Nuke on my personal website.

14. Sometimes it's not clear what sites and services bring what value, and why you should use them. I should know!

16. I installed Linux for the first time in 1999

17. I used FLOSS with my peers in 2000

18. I wrote my first GPL released code in 2002

19. I created my first Sourceforge project in 2004

20. I hosted my first self hosted project in 2007

21. My first Google Code project was in 2008

22. I used Launchpad for the first time in 2009

24. Pick a license

25. Select your hosting method

26. Pick your tools

27. Advertise

28. …

29. Profit?

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.

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.

39. Self hosting is better for larger projects, or for non-public development.

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

45. Self Hosting?

46. Your main choices are: Trac, Savane or Horde Chora+Whups+Wicked.

47. For more options see http://en.wikipedia.org/wiki/Forge_(software)

48. Looking at Sourceforge

51. It hosts CVS, SVN, Bazaar, Git and Hg services

52. Some say there are too many options!

53. Looking at Launchpad

55. It was initially closed source, but was opened up a while ago.

56. It offers ticket trackers (including upstream linking), blueprints, FAQ pages and translations

57. It offers only Bazaar version control software.

58. I consider it to be the most complex and enterprise focused of all of these services.

59. Looking at Google Code

61. It offers native ticket tracking, limited (admin-only) access wiki and downloads.

62. It provides easy links to other Google products – Groups, Blogger, Analytics

63. It offers Subversion and Mercurial Version Control Software

64. I believe it to be the least complex hosted service.

65. Looking at Github

67. It offers a ticket tracker, a download service and a wiki.

68. It only provides access to Git Version Control systems.

69. I have not used this service for any of my projects, but many developers outside the Free Software world strongly recommend it.

70. Looking at Gitorious

72. Unlike all of these other services, it doesn't appear to offer any ticket tracking services, or, infact, anything but a wiki.

73. It is an open source service, released under the AGPL.

74. Looking at Trac

76. It's based on the Python language, and originally was designed to provide a friendly front-end to Subversion.

77. Over the years, it now supports many of the common version control systems.

78. It has very many plugins which allow it to be extended very easily.

79. For many years, this was my only method of hosting code I wrote and released!

82. Whups is the ticket tracking system for Horde

85. Savane is now a GNU project and drives the GNU Savannah web service.

86. It is very similar to the Sourceforge website.

87. It offers access to CVS, Subversion and Arch version control systems.

88. Again, I have never used this service.

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.

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.

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.

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?

105. Please feel free to ask any questions now, elsewhere today, or on email, Google Talk (XMPP) or MSN to jon@spriggs.org.uk