Modify Colors
Posts in 2008 November 25
How To Implement Brainstorm Bounties
If the number of duplicates on this idea is any indication, there are a lot of people that would like to be able to put bounties on ideas. The way a bounty works is that various people contribute to a fund for a specific idea. Then, when a developer comes along and implements that idea, he/she gets the money.
It is a great idea, in theory, but it is a challenge to implement for a number of reasons. I think that it could be done, though. Here is one possible method.
- Ideas with a certain number of votes and up are reviewed by select developers. Any ideas that are approved are opened for bounties.
- Users pay however much they would like to put on an idea to Canonical, who holds the money.
- Once an idea has a big enough bounty attached to it, a developer can claim the idea. At that point, bounties can no longer be added to. If an idea is not claimed for a certain amount of time (a year?) after being approved, users would have the option of requesting the idea is re-approved or moving their money to another idea. The claim is made by a single developer, with the understanding that he/she can use any code that already exists and request help from others, but only the original developer gets paid. Obviously the developer can do anything with that money, so it could be distributed to others, but not through Canonical.
- The developer submits an implementation. A group of developers is selected to review the implementation. If it is satisfactory, the money is transfered to the claimer (the person who implemented the idea).
I believe this approach is fair to both the developer and the users, prevents stupid wars over little things (since there is an approval process for ideas), and would be possible to implement. I certainly don’t expect this to happen any time soon, but it would definitely be great if it did.
Linux Has to Support Closed-Source Drivers
A recent Linux Devices article summarizes a speech given by Harald Welte in which he details the technical problems with closed-source drivers in the Linux kernel. Basically the overall problem is that closed-source drivers often break, since they can’t be updated when the kernel is updated.
I understand that improving compatibility with closed-source drivers would mean some technical sacrifices and a giant fight over the politics of it, but I still feel it must be done, at least initially. I am all for open-source drivers, but, quite frankly, it is a big step for companies to go all the way to offering open-source drivers for Linux. It would probably be much easier for more companies to support Linux if they could at least bring their current development method to Linux. Basically, making closed-source drivers work better with the kernel would provide a stepping stone for hardware manufacturers, who would eventually step all the way across into the open-source world. Once everyone has crossed, you can take away the stepping stone and go back to the way things were before.
Plus, the problem is more than just not being comfortable with open-source. Some companies may, for legal reasons, not be able to release source code. Granted there is great help for manufacturers wanting to make open-source drivers for the kernel, but it still usually requires they turn over at least some information.
The point is that some sacrifices may have to be made in the interest of allowing and inviting more people into the Linux and open-source software world.