Better Open Source Code Just With Volunteers?

   
   
   
   
   

I pose an interesting question to the esteems Open Source software development community: Do you get better FOSS code, more functional software if the developers are paid or unpaid? I ask this because Nicholas Negroponte put forth a very counter-intuitive suggestion in The Sugar daddy for future generations on why the OLPC refocusing was actually beneficial to Sugar software development:

olpc windows xo
Negroponte selling OLPC
"OLPC should have trimmed sooner," he says. "We have since grown stronger. Almost all the cutbacks were in engineering staff related to the in-house support of Sugar, which is far better done in the community. In fact, paying people to do it from within created a degree of control that was unsuitable for real open-source development."

Personally, I don't see the logic to expecting better Open Source software outcomes without paying a core team to lead its development. No matter the size of the community, if the software is integral to your mission, you need to have some degree of control, and a paycheck is usually the best leverage for that control.

But I'm willing to be swayed into thinking that you can get better Open Source development from volunteers than employees, if there are good examples of this or if you feel that Sugar will be better lead by the community's "Open Source fundamentalists" than OLPC or even Sugar Labs.

So, what's your opinion? Do you get better FOSS code, more functional software if the developers are paid or unpaid?

Related Entries

12 Comments

Open Source software developers typically do it because they like to program and have an itch to scratch. Along these lines I think get the best coders for OLPC development would be good software engineers who have kids using the machines; writing something cool for them and seeing them use and enjoy it is a powerful motivator. The main problem with this is that if you have young children you generally don't have enough time to write software in the off hours, so this type of worker (speaking from experience) will only have time to contribute if you can pay them.

if you have underpayed or unpaid developers then you get what *they* want to code and at the pace that they want to code (as a free project on the side). As simple as that.
Sometimes that might align with your goals as an organization. But not necessarily so.


There are a lot of facets to this question. There is, for example, a big difference between a "paid" developer working for Red Hat on the Linux kernel, a "paid" Google SoC developer, and a "paid" developer working essentially as a contractor directly for an organization that has decided they want to have a certain piece of software written, which will also be open source.

Sugar originally was more or less in the first category, and at that point, you're still open to every issue any company trying to hire developers to write a piece of software (particularly a piece of software to be used by a third party), plus some additional complications from trying to create and maintain the extra infrastructure for open source collaboration.

And in particular, when you've got a big philanthropic educational software project, it is hard to keep focused and keep the scope under control.

Well, just my two cents, but I think this is nonsense. Everyone has to get paid at some point. If you don't pay your developers then either they have a full-time job that takes precedence, or they are students and their schoolwork takes precedence (happily, in some cases the volunteer work IS a big part of their the school work). In my experience, which admittedly doesn't go much beyond my own work, software made this way tends to be somewhat unpolished and lack sufficient documentation. I suppose this is either because polishing and documenting are tasks considered boring, or just because the developers don't have time to do it all.

Of course, unpaid developers only do work that they choose to do. If OLPC the organization wants something done that no one in the community is willing to take on, how will it get done? Another thing: volunteers may vanish at any time. I've seen so many conversations on internet forums suddenly stop because for whatever reason, one party just stopped replying. Isn't this a problem?

It's impressive how much volunteers can do, but if any work is considered essential, it just makes sense to hire people.

Unfortunately for OLPC people for the most part must gain something for working, even if the work is fun or for college. Without paying people for work people must to find other methods of gaining something for working on sugar. I would contend that the rather small market base and rather unfinished OS that OLPC works with will be insufficient to motivate people to work. If a person puts in free time to an open source project then they want exposure that can be used for finding a new job or showing off accomplishments.

I would also contend that as a developer looking for a project to code I would not only consider the market base but the longevity of company my work would benefit. At the moment I have serious doubts about OLPC, lets face it the hardware while novel is extremely behind its competitors and the size is too small. (yes I know it is for children but the market place has moved to 92% keyboards and 10in screens that better fit all users.) In addition to the hardware issues sugar is not ready to compete in the market place, and has very limited activities.

I know this is harsh but I do own a XO-1 and at first I tried using it myself for college, but the software was too unreliable and in the case of write unnecessarily crippled (no spell check without a hack). I tried to get my 4 year son to use the machine and on occasions he uses TamTam but he prefers my XP desktop for all the educational software it has that is not available for the XO-1. Now I use my XO-1 as an Ereader (I wish I could get it to bookmark pages) which it doesn’t do well.

What will people gain by working on sugar or activities for sugar?

Assuming that they can afford it, people volunteer for 4 reason in general.
When there is a big compelling worthy goal that strikes some fundamental aspect like national pride. When there is imminent and wide recognition of their [u]individual[/u] contribution. When they expect some "return" for their volunteering (stronger CV, priority hiring), and just because their problem-free good persons. A FLOSS approach to Sugar development should count mostly to the latter. To have these people work effectively, not only you need a clear idea of what you want to do, but also to have it broken down to individual chunks that they are appealing by themselves even though they only make sense incorporated in the big picture (like high energy physicists preparing a cyclotron experiment).
I think that none of the above applies to Sugar development. So NO, sugar as an innovative platform for early childhood education focusing on a unique hardware, can not be developed just by Open Source efforts. At least not to a level approaching the current stated goals in any meaningful way.

If I can refocus the commentary a bit. I'm not wondering about the passion and contribution of volunteers - I ran Geeckorps, the Peace Corps for Geeks and know their passion and problems quite well.

What I am wondering about is specific to Open Source software - will volunteers be better than paid on these projects. Mozilla, Apache, Ubuntu have a core of paid staff with volunteers developing ina loose nit group.

Negroponte claims that -all- volunteer is better.

In the floss world, we expect proof of a wild statement. If NN has some study or research to backup his claim, fine. I dont think anyone who has had exposure to FLOSS culture would agree. But then again, I dont think NN has had enough exposure to what motivates FLOSS folks, which is why he makes such statements.

"We have since grown stronger. Almost all the cutbacks were in engineering staff related to the in-house support of Sugar, which is far better done in the community. In fact, paying people to do it from within created a degree of control that was unsuitable for real open-source development."

What? Like seriously what?

Very few FLOSS projects actually have a complete, polished feel. Example: Firefox, Apache, MySQL, Redhat or Ubuntu (relative to other distros)

What's in common? There's people paid to work on them. When working on software, 80% of development is relatively easy, it's that last 20% that's a pain, but makes it a polished, finished product. It seems you need paid people to finish off a product.

As it is, even with paid people, Sugar is far from polished.

"Volunteers are less motivated to work for free when they know that others are being paid to do the same work or will be paid to do the work if they do not."

http://wiki.mako.cc/Crowding_out
http://tieguy.org/blog/2006/06/18/crowding-out-of-intrinsic-motivations-aka-the-bounty-problem/
http://www.linux.com/feature/60450

The theory is that paying developers drives away some volunteers, so if you stop paying developers you might get more volunteers. However, if we assume that each volunteer is less productive than an employee, Sugar will need to gain a lot of new volunteers to offset the layoffs.

See my response here:

http://ivory.idyll.org/blog/feb-09/better-oss-unpaid

Briefly, I think the OLPC management demonstrated an inability to manage a software development project.

--tiuts

In some aspects, I agree with tiuts's opinion. I think the magic word here is "project".

You may have an excellent developing team, but if you there is no serious project management, core result may not be achieved in time and many non-critical aspects may consume precious time and efforts. On the other hand, you may have team of junior developers, guided by some good senior developers within a managed project and can get to very effective results, with good programming style and documentation.

I think the most clever way to act at this point is to call for projects of sugar enhancements, new activities and other software pieces needed. Then support (with budget and infrastructure) serious projects and claim for results. Meanwhile, the rest of the community can go on developing the software pieces they want to: Sooner or later, the good ones will be used wisely.

Close