Don't Like It? Code it Yourself!

This pretty much what companies do by allowing employees to work on open source projects. And on a larger extreme, examples like the NSA and open source project relating to security, Google employing Andrew Morton, so on and so forth.

As a side note, I once was annoyed by the fact that rsync didn’t specify filesizes in human readable formats like other programs ls -h, du -h, df -h) so I rolled up my sleeves and tracked down that function through the libraries and was just set to add it in… when I found rsync does have the -h option. I just missed it in the man page.

Taking the time and trouble to learn an alien code base or contributing financially to a bug fix/feature are each just ways of demonstrating an investment in the requested bug fix/feature. When someone asks me to code something, one of the first things I do is evaluate just how much investment the person making the request has committed towards the request. If the person has taken the time to really think things through, taken the time to draw suggested screen layouts or taken the time to sell their idea to others, I am more inclined to tackle the project. If the person has obviously not taken any time to consider the details of their request, I do as you suggest and tell them to code it themselves. Yes, that is a F**k you.

I know the chances of successfully completing even a minor bug fix is higher when I am not the only one committed and invested in the project.

why bother with money? You could just give SO users reputation points.

So would you consider this model for Stack Overflow? I know you use Uservoice to get feedback, but could monetary sponsorship beat the voting system?

I think this would work in theory, not in practice. People making random willy-nilly requests for features in FOSS would lead to low quality FOSS.

First - People are motivated for the quick buck, not writing quality software or scratching that itch

Second - It may go against the unix philosophy that much of this software was originally built upon. A major point of the unix philosophy is that one tool should do just one job really well. Imagine someone coming along and saying I wish apache had a chat client, here is $$$ now go do it.

I feel like there is a third point but I cant quite come up with it right now…

sorry, i meant people WOULD be motivated for the quick buck …

You may take a look at real example:
Crossover has this kind of system. For example, some users want to be able to run Access 2003 on Linux:
http://www.codeweavers.com/compatibility/browse/group/?app_id=150

But still, they have only such a few number of supported apps. Not more than 30.

Sounds like an additional business model for User Voice

It’s like this Stallman and his freetards, the source code is freely available… yeah right!
The borders between what open source is and not have actually diminished a lot. And asp.net has a lot of open source I think!

Google is actually kinda doing that with the Summer of Code

So, years ago I was working on implementing a new MTA at my site. I needed a feature and I couldn’t find it. I asked on the (normally incredibly helpful) list and got no responses. So I rolled up my sleeves and spent 2 days coding a patch. Like a good citizen I donated it back to the list for inclusion. At that point someone was nice enough to point out that I had implemented a feature that already existed, and my version sucked in comparison. sigh. I did learn a ton about the guts of that MTA though and contributed some actually-useful patches over the years.

The good thing about open source is not that I specifically can examine, audit, and change the source code. I don’t have the expertise for kernel or device driver hacking, and no immediate desire to gain it. I don’t want to have to absorb a large and complicated code base just to make a minor change.

The good thing is that anybody can, which means that, in the time-honored capitalist tradition, I should be able to hire somebody else to do it for me.

Finding somebody to do it may be the hard part. Some people work on open source for reasons that have nothing to do with money, and may not really be compatible with money. Some people may be paid for it, and may want to keep their spare time free. It’s hard to know without asking.

I could see this making a lot of sense for software that’s plug-in based, but I would not want every Tom, Dick and Harry’s pet feature to pollute core software packages!

What a usability nightmare.

It’s a lot more fun when you call it a bounty on the feature/enhancement/bugfix. I’ve seen the term used for this before, and it always makes me smile–brings new meaning to the phrase killin’ bugs.

Jeff, I hope you pay attention to zurvan2’s comments. Normally I wouldn’t rag on anything in your posts because I agree with most points (and to be correct, you could translate a request for help in that fashion in either way, as ‘Help’ or as ‘F you!’) but he does make a good point that should be considered. :slight_smile:

I’m not convinced by this idea - simply because of the human element.
I would personally love to work in an open source environment, and be well paid for it, but I just can’t see this working.

The problems are these:

  1. Who decides when a feature is actually complete?

There’s a great deal opportunity here to create problems on both sides - customer to not pay developers even after they put in a lot of hours, just because the requirements weren’t clear, or for developers to insist on being paid for producing shoddy work.

This situation would require an ombudsman, who would that be? And how would they be paid?

  1. Who gets how much money?

Dev1 takes a job and goes dark for months. Customer gives up and asks dev2 to take the job. Dev1 dev2 produce similar but incompatible code at the same time. What about when dev1 dev2 cooperate on a task.

  1. Who decides what a feature actually is?

If 1000 customers pledge money for a feature, there’s a good chance that they actually want 1000 subtly different features. How do you manage those 1000 ideas?

A related idea, 1000 customers each raise individual requests for their specific ideas. The amount of bounty available for each implementation is now 1000 times smaller than it otherwise would have been?

How to you herd the customers?

Basically, there’s 2 parties (A B) and 3 interactions (A-A, A-B, B-B), all of which are easy in the trivial case, but I fear they won’t scale at all with human personalities involved.

The second best idea I’ve heard is the open company, which I’m watching with interest, although I’ve no interest in working on a bloated text editor that’s almost but not quite open source.

http://e-texteditor.com/blog/2009/opencompany

Open ERP had a sponsorship program where people would say how much they would give for a feature, so any developer could offer the feature, and multiple people could donate to it, if the original donation was too low… I dont really know how well it worked…

Another point, I think its a bit harsh taking a ‘do it yourself’ as a F U. I know alot of open source enthusiasts are just that, they have to hold down jobs and spend spare time working on their hobbies.

As Zurvan2’s comments suggest…

I am sure there are developers who take any suggestion as a slight against their product but there are just as many developers who probably agree with you but don’t have the bandwidth.

Some open source projects are easier to work on than others. If it’s a bug in Firefox that I want fixed, no way in hell am I going to do it. But for a relatively small app or library that is easy to build and has a reasonably understandable codebase… I’ve found the DIY option to be very satisfying. Even if I have no way to contribute my improvements back, at least I can still reap the benefits.

I understand that people who release their code have zero obligation to do anything beyond that. It’s their code, their lives, they can do what they want. There’s nothing wrong with that.

Nothing new in this.
I see bounties come and go all the time over on drupal.org where I’m a contributor.
Occasionally there is a feature request that I agree with, but doesn’t scratch my own itch, so as well as reminding folk that they can try it themselves, I point out that if a few people want it badly enough to throw a few hundred dollars at it, it will certainly happen a lot faster! It doesn’t happen a lot, but it does happen.

I did a job like that just last week when someone asked for an extra file format to be supported in an import tool. I gave him some pointers on where in the code he could try doing it himself - he asked me what it would take for me to just do it - I quoted - he said OK - a week later the open source module is better for it!

Simple simple business. And I certainly don’t think it corrupts the ‘open source’ credo at all. There’s nothing evil about a programmer getting paid for work that someone else wants them to do. Getting paid for something you were wanting to do anyway is a great thing! And I don’t think that sponsored feature creep is any more virulent than hobbiest feature creep. The same vetting process goes in to evaluating whether something is really worth doing.

Bounties aren’t new, but they could do with a bit more support as a business model!

Individual apps have this, but I think an organization that did this for tons of apps could really change tings and be big deal for open source. Do it Jeff!