programming and human factors
by Jeff Atwood
Have you ever considered paying for, or sponsoring, a
... for software that you use?
I don't mean waiting for a new release of the software, which will contain a bunch of new features you may or may not care about, along with all new bugs. I'm talking about making a very specific request for existing software happen through financial sponsorship.
Sure, if the software you're using happens to be open source, you can theoretically download the source code, roll up your sleeves, and code it yourself.
If you have a very strong desire to see a particular feature implemented, your odds of success of ultimately having it become a part of the tool are dramatically increased if instead of asking for it to be implemented, you check out a copy of the latest source code tree, code it yourself (even if slightly incomplete or somewhat buggy), and submit it for peer review by the existing developer pool. Other technical parties are far more likely to help you complete a worthwhile code enhancement that you've clearly put time and thought into than they are to remotely consider doing what you want from scratch just because you want it.Of course, not all end-users have the technical acumen or programming experience to bring such things to reality. You have three options: a) find a programming friend that you can get excited about your idea and have him follow the above paragraph, b) live without the feature and enjoy the software you have been provided free and proves useful to many others, or c) find a different software package that does do what you want.
But how realistic is this for the average user? Heck, how realistic is this for the average programmer? Even if you're the type of macho, gung-ho programmer who can master an alien code base just to get some small pet feature or bugfix in -- do you honestly have the kind of time it would take to do that?
Sometimes, when people say this:
The source code is freely available. If you feel so strongly about this bugfix/tweak/feature/plugin, why don't you code it yourself?
They're really saying this:
F**k you.
That seems a bit harsh to me. Surely there's something between the extremes of "give up" and "code it yourself."
Why isn't there a service to aggregate and pool funds to sponsor programming particular features or bugfixes in open source software?
There are many end-users willing to pay for improvements to free software and writing new programs. There are also many talented programmers wanting to get paid to work on free software. Allow end-users to escrow payments that are pooled together to pay developers for implementing features / writing software. A panel of well-known free software experts is needed to vet new ideas before payment is escrowed for them, and to review programmer work having met the target.
I realize that using financial incentives on open source projects can have some unintended consequences. But a sort of attention and interest aggregation service for existing projects -- one backed by real money, so you know the interested parties are serious -- seems like a worthwhile cause. It might even attract the interest of other programmers if the pool got large enough.
To me, at least, sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project. For example, I've sponsored several bugfixes in a key .NET open source library that we use for Stack Overflow. These are bugfixes they considered low priority, but were serious issues for our site. I was happy to give back to the project, and it was certainly a more realistic option than us carving out a chunk of our own development time to contribute the bugfixes ourselves.
That said, I am concerned that this sort of aggregated sponsorship system hasn't naturally evolved on its own by now. Is it not sustainible, or incompatible with the kind of intrinsic motivations that drive most open source development?
I looked at some of the bounties on the FOSS sites listed in these comments, and the vast majority of bounties are US$200 or less. For a even slightly talented developer, these numbers are negliglibly close to zero (given the amount of work involved simply in getting your development environment going).
I thought what developer is going to take this job? Possibly a single developer would know a product well enough to earn *all* the bounties logged against the product. More likely you're going to get an unskilled developer writing horrible code (never accepted by the maintainer, if there's an acceptance process). If most business are aware of this, it'd explain why bounties aren't common.
Me, I'd much rather light $200 on fire and wait to find someone to do the work for free, than to hire someone for $200.
Actually, just coding it yourself really is best.
Bill on March 31, 2009 7:26 AMAt Funambol we have a program called Code Sniper https://codesniper.forge.funambol.org that sponsors with money grants the development of new features for the product. The list is pretty open and when somebody of the community asks for something that is not available, our answer is not a simple 'do it yourself' but 'we can sponsor the development, help us find somebody willing to accept the task'. It's not a simple issue in any case and I don't think there is a silver bullet.
stefano maffulli on March 31, 2009 9:32 AMCouldn't this work (maybe better) for closed-source projects?
If you've got some software which people pay to buy, then you have the hassle of deciding whether and how to prevent them copying it freely. There are a whole raft of methods used, but it's all crappy overhead in relation to your core task.
You could use a fund-and-release system to propose functionality improvements (even bug fixes) and collect the payment for your work in advance. See for example the Takoha manifesto (www.takoha.org) for a description of how this could work.
Nigel Dorser on April 2, 2009 3:34 AMI've done this kind of thing too, in a way... http://blogs.compdj.com/post/Refactoring-someone-elsee28099s-code.aspx
Financial incentives for feature-requests would go a long way to help improve open source software. People may see it as commercialization of the software or corporate takeover (as financial incentives could be used to change project direction). It's more-so a practical donation.. I would work on open source projects if I had free-time to do so (I would prefer to work on open projects as opposed to projects that had lots of NDAs associated with them) - but I'm also in university and have my own place. I need to pay for food, university and housing.
Patrick Gryciuk on April 10, 2009 7:58 AMI'm doing it (at least theoretically). People that want a given feature in hippo mocks have three options: do it yourself and send me a diff, pay me to do it or convince me that it's so awesome I'd want my free time spent on it. And to counter the most prevalent comment I've read so far, none of these options require me to merge back the change, but all keep the option open if I deem it a good idea. The mainline is kept up to date and if you have a good feature I will do it for you, make it work in your environment and merge back the good bits.
I'm not sure there is interest in a generic way of doing this.
Peter Bindels on April 15, 2009 8:21 AMHow can software be any different from other things in life?
If you want something done:
A: You do it yourself.
B: You find someone else who can do it and a suitable motivator (money, coke etc. and in rare cases persuasion.)
C: You tell your kids not to do it
I think the latter. But it's not just the motivation either; as much as I hate to say this, it's the business people and managers and CEOs who actually know how to spend or invest money in order to improve productivity. Open source projects are run entirely by developers who, by and large, simply would have no clue what to do with the money.
I'm not trying to level criticism here; modern society runs on specialization. Money is just one commodity and by itself doesn't accomplish anything - you need an organizational structure and business plan to go with it. Open source projects have neither; thus, they're unlikely to benefit from any serious investment. And to the *credit* of the developers in charge, they are probably aware of this and that's one of the reasons they eschew sponsorship.
Bottom line - paying someone to perform their hobby does not make it a business.
Aaron G on February 6, 2010 11:16 PMPooling money for features can result in a customer mindset, where people tend to get agitated if they feel they've paid for something that doesn't meet their expectations or desires.
I wouldn't be surprised to see people either demanding their money back or insisting it be counted in a separate bucket that specifies the feature be implemented in a specific way that suits their needs.
I guess there are ways around this, but still...it sounds like a recipe for strife.
aaron ward on February 6, 2010 11:16 PMJeff, I think you are onto something here.
Don Park on February 6, 2010 11:16 PMWINE and CodeWeavers has had a pledge system for years. You pledge for an app you want, and it gets bundled with others pledges. For example:
http://www.codeweavers.com/compatibility/browse/name/?app_id=151
Ironic that the one natural example of this kind of system (that I know of) is for closed-source applications, but the difference between donations and payments is huge. One comes with goodwill, the other with requirements. And it's not just software or FOSS where this kind of change happens. Blood drives are very different if they're donations or payments.
Doesn't SourceForge already have such a feature?
Simon Brown on February 6, 2010 11:16 PMI don't think financial incentive for an individual feature makes for good project management. That goes for open source or closed source.
FEATURES HAVE TO BE SUPPORTED FOREVER. Is this user willing to continue to foot the bill for that?
Even when they conflict with other features? Even if it prevents other important features from being implemented?
The choice to implement a feature (or sometimes even to fix a bug) has to be viewed in a larger context.
Jason Cohen on February 6, 2010 11:16 PMYou missed one of the possibilities. In the OS projects I contribute to (Perl modules), there's also the choice of Write a failing test, if you can't or don't have time to write a feature yourself. The test gives the devs something actually concrete to write towards, and, if accepted, makes them itch cos now the test suite doesn't pass.
Jess
Jess Robinson on February 6, 2010 11:16 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |