[FM Discuss] residency, and floss for $

Julian Oliver julian at selectparks.net
Wed Sep 5 02:15:34 PDT 2007

..on or around Wed, Sep 05, 2007 at 10:19:05AM +0200, adam hyde said:
> >but that adds a social problem if people feel like 
> > their contribution was undervalued and get mad. I'll admit though that I 
> > haven't thought about this at length or looked to see if anyone else has 
> > come up with workable models; do you have any ideas on that?
> I think there is a chance that people get mad. I don't know what to do
> about it but do as much as possible to make the process fair, and then
> accept that people can and do often see it as unfair. I think this
> process will always have a component of fallibility but the point is to
> be as clear and communicative as possible about what is trying to be
> achieved and then be as fair as you think you can.
> As for the clear communication - I think perhaps it would be interesting
> to think about how to best communicate the process before it starts.
> Would it be wise, for example, to publish a 'difficulty' rating for each
> chapter and this rating would then help weight the final calculations? 

this all sounds like pretty hairy territory to me. the moment you start
coupling qualitative or contextual evaluations of contributions -
whether automated or not - with money you're opening up a can of worms. 
some will question that their contribution is 'worth less' than another's 
and claim bad/unfair/biased judgement on the part of FM.

one thing i'd try and avoid, let alone provide a context for, is a basis 
for volunteers to argue the economic worth of their contributions.

instead, the value of a contribution should (ideally) be evaluated based
on the actual work it does in action, ie by the users of that contribution.
a contribution is only ever as valuable as it is useful.

some way of publically communicating that value back to the individual 
contributor would go further than money i think. i don't know how that's
possible however but some sort of reader-rating system comes to mind.

it's perhaps worth looking at the fiasco surround Dunc-Tank - a group
setup to pay select developers to fix bugs and contribute features
deemed critical to an upcoming release. 

at the least it's an interesting tale of free-software, motivation and money:



> > >   
> > 
> > I think the big difficulty is that volunteers don't like to feel like 
> > they're "working for free" when someone else is getting paid to do the 
> > same thing.  I'm not sure of how exactly to handle it best, but it seems 
> > like a way this might naturally work out in FLOSSmanuals is that the 
> > paid people would have more responsibility.  For example, a paid person 
> > might have deadlines, or they might be responsible for ensuring a manual 
> > gets finished (writing the parts nobody else wants to, etc.), doing 
> > editing/integration, meeting/negotiating with sponsors, etc.  The 
> > volunteer person, of course, would just write what they feel like when 
> > they feel like, though of course they would still coordinate with the 
> > other writers as good project citizens.
> souns like a good clear distinction to me. Perhaps Maintainers get paid
> (where possible) but also have deadlines etc. This is what I was gettign
> at with the post about added-value advertising. Each maintainer could
> take some of the income from the ads for the manual they maintain.

i agree with you both here. perhaps it is easy enough to establish an
economically arguable difference between creating and maintaining a
manual, and contributing to it.

> > 
> > Things should be fun and based on mutual agreement for both volunteer 
> > and paid writers (making paid writers do more unnecessary work isn't a 
> > solution), but it might smooth things over if the paid writers clearly 
> > have more responsibilities... then a volunteer is less likely to think, 
> > "wtf, that guy's getting $500 for the same thing I'm doing free; where's 
> > my $500?"
> yep, good idea. In the situation of maintainers being paid the role is
> clear but should be written down. It would be something like:
> * structure the manual
> * ensure chapters reflect current software version
> * look for new contributers
> * keep the edit homepage up to date
> * manage the print-on-demand 
> * update the published manual as necessary

while this looks good, how do you propose dealing with the event of someone
abusing the opportunity or fail to meet manual quality/content criteria?

for instance, if someone were to start 10 new 5 page manuals for some unpopular 
and/or trivial software and nominate themselves the maintainer, would you 
reserve the right to _not_ publish their contribution?

an unlikely event perhaps,


emails containing HTML will not be read.

More information about the Discuss mailing list