Sebastian at SSpaeth.de
Wed Mar 19 12:16:14 GMT 2008
Richard Fairhurst wrote:
> Gervase Markham wrote:
>> Paying bounties or other rewards within a volunteer project is a large
>> can of worms. Some projects manage it, others go down in flames. Apache
>> has refused to pay _anyone_ for years for this reason, although I think
>> now they are getting around to employing a sysadmin (who won't code). It
>> depends hugely on the dynamics of your project.
> I suspect the dynamics may be right for OSM.
I tend to agree, but see my counter-example of the frenetproject.org.
If we, e.g. pay TomH or JonB (which would make most sense), people will
be even more likely to abstain from learning ruby and improving the
server as they can request it and wait for the "main guys" to do this.
This might not even be the worst thing. But I agree with Gervase here:
This is a tricky issues and requires some thought. Potentially it
reduces outside code contributions even more. In some cases it might
also help, e.g. musicbrainz.org only survived because the main guy could
> features. Some of them are little things that can be ticked off by
> individual developers when they get a moment: most of my Potlatch trac
> list comes into this category, for example.
See, this requires some decisions already: do you go for a small bounty
for a trac ticket thing? Or do you hire one or two guys for a few
months. Again, I am not against it, but it does require serious thinking.
> OSM's _primary_ output is its data, not its code, and that's the
> difference from Apache. All the other stuff we do is really cool, but
> it's essentially there to facilitate the data.  If bounties for
> developers means fewer obstacles for mappers, that's a win.
If that is OSMF's stance, than it could make sense to go that way. We
might just have to live with it, that volunteer contributions *could* be
reduced to map data.
More information about the dev