[Geowanking] Bad news for those who wanted to seelocation-basedapps on the iPhone...
anselm at gmail.com
Fri Jan 26 11:18:05 PST 2007
> 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
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
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
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.
More information about the Geowanking