As the administrator of an open source project I often struggle with the challenge of good documentation. Often developers just want to throw code in the CVS. A project administrator can spend more time writing documentation and weeding out bug reports than that do writing code.
Yeah; that can feel like being a glorified janitor. Especially since it feels like you're the one that has to have a model-in-mind of all the code and understand the implications of all new commits and how they might touch things unconsidered. A former employer made a comment that "there are no evergreen projects". That comment kind of wraps up a bunch of ideas: that stable product isn't really about software being open source or not open source but rather that there is some kind of ongoing attention being paid; that there is a machine for ratcheted quality improvement. What incentives do the developers have to produce their best possible work? Is there sufficient penalty or punitive measures for making bad commits? It seems like self-induced public pride or embarrassment is good enough; a vibrant online social forum where developers are maintaining a conversation helps make people put that little bit of extra effort in. Another incentive is the licensing model; can developers take their work home and commercialize it or recycle it? We often conflate GPL and BSD but they are radically different; one posits software as an asset that should never suffer being behind lock and key, the other as a liability that everybody should spread the burden of. It might just simply mean that you need to express the highest expectations that you have; or to find a way to have others articulate those same ideals that are getting you to do the grunt work. It may even mean being willing to boot people out of the source tree for a while or permanently if they are making bad commits or if they are disruptive. Most software; free or commercial is built under deadline; with people who are only paying partial attention, who are trying to muster enough will and focus to make a successful commit. Teams optimistically measure their members at their best and set schedules and policy based on that; not say designing team process based on seeing people after a night of hard-drinking or during a divorce or the like. At best a person writes reams of flawless code; considers all edge cases and integrates it smoothly; fixing several unrelated bugs along the way that they happen to notice. More usually you need a couple of people walking over the same code; unit tests, bugtrac and a lot of general rigor. A successful process is one that you can walk away from for a few weeks, and come back and it is still running. Not to laud OpenBSD but they do have a rigorous peer review process and happily freeze commit privileges for people for even small errors. There is a high expectation of quality. Smaller deliverables and a rigid 6 month release schedule also help them. Incidentally; the work in the geo community is surprising; projects like geoserver, postgis and openlayers are of unusually high quality. There might be something to learn there. At a slight right-angles to the above; I suspect IRC is the secret engine of the net... ongoing persistent conversation is where a group begins to improve its awareness of itself and its aspirations... everything else; goal setting, tactical planning, falls out of a discussion where all the participants are bought in and have instilled their point of view. Conversation is almost the opposite of email in fact. I often witness email queries that go unanswered or left to lone staffers; online lost notes in bottles; when those kinds of same comments made in a conversational forum would at least spark some sense of life and engagement. - a _______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking
