While our community team was doing our annual retreat this year, we
spent 40 minutes looking at a variety of open source projects to see
what sort of patterns we could find; here are a few things we noticed
and some recommendations we made based on those very shallow looks. Not
sure where best to place them in the book, but Karsten said to send them
to this list. :)
--Mel
--
* Small projects need to stick with one, canonical conversation
location when they start, and grow in response to capacity instead of in
anticipation of it (think of speccing out office space & departments
for a startup of 5 people).
** Don't increase mailing lists by rote.
** Splitting in to many different tools (Redmine, Fedora Hosted, github,
etc.) means the conversation and community is split. "Engineering word
of mouth about how to start up a project."
** Use one location (mailing list)
* These details do matter, even if you think they don't. :) Think about
how businesses must grow and change with size and age through various
distinct phases -- not all open source projects can run the same way.
* TTM pressure on the developers?
** May make conversations go quiet.
* Picking the best tool for each task instead of reinventing
Show replies by thread