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

2. Who am I? I'm known as JonTheNiceGuy

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!

8. 3^h 4 reasons why you are here You're a FLOSS developer who's about to start a new project

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!

11. You're bored and there are no other talks more interesting (no-one expects the spanish inquisition!) All good reasons. Thanks for being here!

12. Why am I talking about this? I've been involved in Free Software since 1999, when I first started actively pushing Linux solutions on people around me.

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!

15. What's my pedigree? I used Linux for the first time in 1996

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

23. Getting Started Have you checked no-one's done this before?

24. Pick a license

25. Select your hosting method

26. Pick your tools

27. Advertise

28. …

29. Profit?

30. Is anyone else doing this? There are over 400,000 registered projects on SourceForge and Google Code and unknown thousands elsewhere on the web

31. If you can, then try and work with an existing project that does nearly what you want rather than start a new one, But... If it's not in the "right" language for you

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. Pick your License. The main ones are: AGPL, GPL, LGPL, BSD AGPL requires every used change to be re-released as AGPL. This may or may not include themes, depending on who you speak to.

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. BSD requires attribution any time the code is made available. For a more complete list, see http://www.opensource.org/licenses

38. Pick your hosting Will you be self-hosting or using a hosted service?

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

40. Hosted services makes it easier at the beginning of a project to just concentrate on the coding. BUT many hosted services have an overwhelming array of options.

41. Your choice of hosting and the software driving that will define your Version Control Software. This will be the main area I'm focusing on in this talk!

42. Host Externally or Locally? Going the hosted route?

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

49. Sourceforge Sourceforge is considered to be the original “forge” resource for Open Source developers

50. For various reasons, many developers and projects mistrust Sourceforge. There are concerns that it's source code was Closed, then Free Software, then Closed again. It provides mailing lists, ticket trackers, forums, and a wide range of other support tools.

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

52. Some say there are too many options!

53. Looking at Launchpad

54. Launchpad Launchpad is primarily used by Canonical for the Ubuntu project

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

60. Google Code Google Code was released by Google and now hosts all of their Open Source code... which doesn't include the code for 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

66. Github Github is a service offering paid and free hosting for Git based repositories.

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

71. Gitorious Much like GitHub, Gitorious provides services strongly tied to the Git version control system.

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

75. Trac Trac is not available as a hosted solution.

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!

80. Horde Chora + Whups + Wicked Horde is more well known as a webmail or groupware suite.

81. To support the Horde development process, the Horde developers wrote a series of Horde modules for project management Chora provides access to CVS, Subversion and Git version control systems

82. Whups is the ticket tracking system for Horde

83. Wicked is the Wiki system. Horde is a PHP framework, but these modules don't currently integrate well together.

84. Savane Savane was originally called “Savannah” and was the code which drove Sourceforge, before it became Closed Source.

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.

89. Version Control Software I just wanted to briefly touch on Version Control Software.

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. Centrally Managed VCS Visual Source Safe is the tool built for Visual Studio. It's very hated. With many good reasons.

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. Distributed Version Control A distributed Version Control system will allow many developers to work off-line from each other or the central store.

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. Configuration? I had also planned to provide some configuration guidelines for your projects... but this got FAR too big for that! However, whatever you're using, turn off the modules or sections you aren't yet using! It's too confusing, for you, your developers and users! You can always turn them on again later!

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. Any Questions? Obviously this talk was pretty high level, and I've not used everything I've shown you, but I hope I've given you something to use the next time you're creating a new text editor, a new microblogging service, or simply have developed an improved way of putting pictures of your cat online.

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