53

To start an open-source project is not just to throw up the source code on some public repository and then being happy with that. You should have technical (besides user) documentation, information on how to contribute etc.

If creating a checklist over important things to do, what would you include on it?

Ryathal
  • 13,317
  • 1
  • 33
  • 48
Anto
  • 11,157
  • 13
  • 67
  • 103
  • 1
    +1 Good Question. May I recommend: http://gawande.com/the-checklist-manifesto – JeffO Feb 24 '11 at 18:33
  • 2
    I recommend Karl Fogel's (one of the original subversion authors) book *Producing Open Source Software- how to run a successful free software project* It's an O'Reilly book. – Michael Feb 24 '11 at 19:10
  • [Producing Open Source Software by Karl Fogel](http://producingoss.com/) should help you with that. The book is available entirely online. – Coyote21 Feb 25 '11 at 00:23
  • http://stackoverflow.com/questions/11248363/the-purpose-of-starting-an-initial-comment-with-in-javascript-and-css-files – morewry Nov 17 '15 at 17:50

2 Answers2

36

The most important thing is:

  • use the project yourself and get it into a useful state where you enjoy using it. be sure the project works and is useful.

Things I'd put in the early priorities are:

  • have a simple "what is it?" web site with links to some discussion forum (whether email or chat) and to the source code repository
  • be sure the code compiles and usually works, don't commit work-in-progress or half-ass patches on the main branch that break things, because then other people's work would be disrupted
  • put a license file in the code repository with a well-known license, and mark the copyright owner (probably you, or your company). don't omit the license, make up a license, or use an obscure license.
  • have instructions for how to contribute, say in a HACKING file or include in your README. This should include where to send patches, how to format patches, code indentation rules, any other important conventions of the project
  • have instructions on how to report a bug
  • be helpful on the mailing list or whatever your forums are

After those priorities I'd say:

  • documentation (this saves you work on the mailing list... make a FAQ from your list posts is a simple start)
  • try to do things in a "normal" way (don't invent your own build system or use some weird one, don't use 1-space indentation, don't be annoyingly quirky in general because it adds learning curve)
  • promote your project. marketing marketing marketing. You need some blogs and news sites and stuff like that to cover you, and then when people show up interested, you need to talk to them and be sure they get it working and look at their patches. Maybe mention your project in the forums for related projects.
  • always review and accept patches as quickly as humanly possible. Immediately is perfect. More than a couple days and you are losing lots of people.
  • always reply to email about the project as quickly as humanly possible.
  • create a welcoming/positive/fun atmosphere. don't be a jerk. say please and thank you and hand out praise. chase off any jackasses that turn up and start to poison the community. try to meet people in person when you can and form bonds.
Havoc P
  • 918
  • 6
  • 11
  • What about potential legal problems? How does one make sure that implementation doesn't inadvertently contain a patented algorithm? – Den Mar 03 '15 at 14:15
  • It isn't possible to determine that, unfortunately. Given a chunk of code there's no way to know what search terms you'd need to locate the relevant patent(s), which is one reason software patents are such a problem. Sometimes you know there's a patent that applies, but I've never heard of a way to be confident that there *isn't* a patent that applies. Hard to prove a negative. Patents are a big enough topic that they should probably be their own question(s) ... – Havoc P Mar 03 '15 at 18:02
17

For starters, Lower the barrier to entry, this means:

  • make it easy to install,
  • make it easy to modify,
  • make it easy to find your project,
  • just make everything you'd want to do easy.

How?

  • Give an answer to every question you can think of in your documentation,
  • Create an easy to use build system,
  • Clean up your code, nobody likes working on spaghetti code,
  • Make something that people have a need for.
dan_waterworth
  • 7,287
  • 2
  • 34
  • 45