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?

Improve this question
4

2 Answers 2

Reset to default
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.
Improve this answer
2
  • What about potential legal problems? How does one make sure that implementation doesn't inadvertently contain a patented algorithm?
    – Den
    Mar 3, 2015 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 3, 2015 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.
Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.