How can I keep people involved and motivated to work on a project that doesn't involve direct monetary benefit? What specific strategies do open source projects tend to use to keep core developers involved?

Partly this is a general "what strategies reliably motivate most open-source developers", but it's also about "how can you prevent people from forgetting they're involved at all? What specific tactics do project leaders use to remind people that they're part of something?".

At least in my own case, my largest problem with projects is that I have hundreds of barely started, and tens of half-finished things that I just completely forget about / put off, but that I do really want to see completed. While this arguably isn't specific to open source, to me at least it's the largest impediment.

  • On the one hand, this is a really broad problem statement. On the other hand, I think there's an underlying question here that's practical and has the potential to be reasonably scoped. Can you tighten it up some?
    – Air
    Jun 23, 2015 at 20:59
  • @Air I'll tighten it up when I get off work. I agree it should be more specific. Or, if anyone else thinks of a more incisive phrasing / question that gets to the same core idea, I welcome edits. Jun 23, 2015 at 21:19

2 Answers 2


One of the biggest incentives is to create well defined goals. With that, people will want to work towards something. With goals, people will understand their job, as well as what they would like to accomplish.

Now, this one may sound slightly ironic, but to not lose momentum, you need to keep activity from a fair number of contributors. If someone feels as if they are the only one working on something, and they don't understand what they're doing, their objective, their audience... it might be discouraging.

Another option, could be to gamify it a little bit, similar to how we run here within the Stack Exchange community.


One aspect about keeping momentum is to always keep current on the latest features, and to ensure you support the people who are most dynamic in the areas of interest.

I found this with JDOM (Java XML library - it is unfortunately a good example of how to stifle the momentum). A lesson learned there is that you have to ensure you keep reasonably relevant with the latest systems.

JDOM ensured that it kept compatibility with legacy systems, including Java all the way back to Java 1.2. This makes sense from a code maturity and legacy support basis, but it made adopters of Java 1.5 with generics a real problem. JDOM was too late to support the newer Java versions, and as a result, it lost momentum.

Keep your code relevant, watch trends, and attract people who are developing things, not using things.

This means continuously building and supporting new features, probably while maintaining older versions to support legacy folk too.

  • Why unfortunately a good example?
    – Zizouz212
    Jun 23, 2015 at 23:36

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