Volker and I attended froscon  on the weekend, and found an
interesting talk regarding management of open source projects which I
would like share with you .
Here are some random notes I took:
- Marketing/communication: twitter, facebook, ...
- discussions: produces feedback, ...
prefer references ("testimonials") from users over "bragging" by the
team --> we already have collected many use cases that should be put
on a wiki and linked from the front page.
- articles in magazines (c't ;-)), blog posts, ...
- documentation as a book ;-)
- Froscon or other OS conferences: talk/booth?
- FAQ where each item can be linked directly (from doc map or wiki)
- domain experts needed (looks like we're in good shape)
- localized resources --> our wiki is already multi-language capable!
- two-way mirroring between a mailing list (technical) and a forum
(for users) --> more or less what we have
- apply for google SoC?
- user -> contributor?
- usually "scratch your own itch"
- communicate explicitly what features/fixes Freeplane needs ("call to
action"), so that contributors steer in the right direction
- provide a vision and priorities
- provide tiny changes for contributors to get started. This way,
prospective devs learn their way around including setting up dev
environment (this is actually what we do to support Nnamdi/nnako)
- provide clear patch rules (e.g. most clean code rules)
- Important: provide feedback ("thanks!!!") to contributors!
- get funding, see ASF (not really relevant for freeplane)
- communication: Isabell discusses several media along with its
advantages and disadvantages
- some advantages of meeting in person or in a video chat
- web forum, ML, issue tracker, wiki, web page, ...
--> use the right tool for the task!
- one canonical place for documentation?
- if you are not sure that you will finish a task, make sure you don't
block others from working on it
- project growth --> take care of the non-full-time devs (not for
- handling trolls/"poisonous people" ("jeff"?):
- well-defined rules for communication in the community are helpful
- take a step back and then formulate a professional reply (Dimitry
does that very well!)
- in case: prepare your exit from the project well enough
i.e. hand over! delegate!
- many books on the topic, search for "building successful online
communities for open source projects"
If you agree with me in that this is useful, I would post this
in the open discussion forum.
There was also a keynote about caring for open source users ,
but I do not consider it very informative.
The only idea I got from that talk is that we could use slack for
developer communication (can it handle audio communication as well?).