Slashdot Mirror
'Open Funding' For Driver Development
Doc Ruby writes "The TreoCentral community has announced a bounty for the first BlueTooth SDIO driver delivered for the Treo 600 (PalmOS 5). The thread shows the development of both the requirements of the quarry, and the contributions to the bounty. If this process works, is 'open funding' of development the next wave of the emerging online community? How will the 'traditional' vision/scope> requirements> features> >recode> retest> demo> cycle expand to include the user community in the financing?" Update: 06/16 19:43 GMT by T : Updated the bounty link to a server better able to handle it.
This is great! I certianly wish more companies would adopt this kind of a driver development model.
I know the GNOME Foundation has also done a similar bounty system, recently.
The bounty is only valid until September 6, 2004 - so let's get coding!
Cliesource.com had created a contest for the development of a compact flash driver for the Sony Clie line. Some developers said that Cliesource did not give developers enough time to develop a working driver but the contest did help getting a working driver into circulation.
http://nyamenation.org/
Isn't the quality of linux software rooted in that there are no timetables to get things working? It seems like quality comes from slow-moving community discussion and eventually a product. On the other hand, I would like to be able to throw money at some projects to get software faster.
Error: Id10t detected
There is a new website available and the estimated savings to the public sector is pegged at $56B / Year.
Help fight continental drift.
While the goal is noble, the result wont be what you think. These free-for-alls to get things like drivers written for money, honestly, doesn't have much real ground for success. Think about it. 10 developers start throwing a whole mess of their own free time into trying to get driver x done for y money. 9 of them will NOT get the money. Depending on the work that they put into it, chances are they will come to the conclusion that it isn't worth the effort, because not only is there no guarentee of a payoff, you will never KNOW the odds you are up against to be the one to get paid in the first place. This certainly keeps people from taking on this model as a means of making a living, and most people doing it in spare time will find it a waste.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
There's a more readable version of the story on treocentral's stories page
I remember when the Blender 3D software was bought from the company NaN for $100,000, there was some speculation that it might not be a good thing if this kind of trend continues. Granted, this is a bit different. But maybe instead of just developing drivers, companies would wait around for someone to generate a big pot of money to make it worth it for them.
Remember SourceXchange? Remember CoSource?
.COM madness, and have since gone the way of the do-do. I was involved with one SourceXchange project and they had the most robust/complete bidding process of the two.
They occurred during the height of the
I remember that CoSource had trouble attracting people to bid on projects. There were a number of interesting ideas, but little money.
With SourceXchange the typical project was a semi-large idea with semi-real funding from somewhere (in my case it was Ricoh's research lab). I participated as an expert/reviewer and the coder-guy received only $10,000 or so for a whole lotta work. Not a good hourly rate if you ask me.
- David
The problem with this is that it doesn't provide a stable paycheck. If you look at many open source projects, they refuse to take donations simply because the money wouldn't help them (other than hosting). If you are a volenteer free software developer, getting a few bucks might be nice, but it won't enable you to spend anymore time writting free software than you already do. You have commitments to your job, schooling and family, and in most cases you don't have the flexibility to work less job hours (and get paid less) as you get more donations. If developers will not accept donations for what they are already doing, why would they go after a bounty? So no, I don't see it being the future of free software. The future will continue to be a mix of businesses that use and need to improve open source software, and volenteers.
That sounds like a great way to get several parallel development streams with zero colaboration going. This will either end with one working driver and several lesser quality broken drivers, or a whole bunch of half finished pieces of code. Either way you'll have end-user confusion.
There must be a way to get that money used in a way that creates an environment where programmers help each other.
...particularly if the community can pony up the cash to pay whatever licensing fees (no, not the teabagging one) that kept them from getting access to different hardware specs until now.
This, to me, is what OSS has been missing- some form of incentive beyond the basic "I programmed it because it is neaty-keano". I may be a marxist, but I realize a basis of capitalism is rewarding people for hard work- or at least it's supposed to be.
A down side of this specific one is the time limit- what if it can't be done by the deadline, what happens to money contributed? My suggestion- take away the time limit, allow anybody to contribute money, and when the pile of money is big enough, somebody will release something and get the money. It's slightly better odds than the lottery, so sure enough somebody will come up with a driver (or any other piece of software) for the heck of it.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
For those not in the know Rent-A-Coder is a site where people/companies put up software projects, and (get this!) coders bid on the project. Once a coder is selected, the client puts the agreed upon fee in escrow. All communication (in theory) is conducted through the website, so that in cases of despute, there is a clear papertrail. At the end of the project, the escrow company releases the money to the coder. Badabing, badaboom.
It sounds like a good place for young coders to get experience. In practice however, the overwhelming majority of jobs get placed to more experienced coders (read: RAC users with higher ratings). So even in the code-whoring business, the classic experience catch-22 remains in effect.
Bidding for software works. This would allow programmers to do the shopping for the bidders based on the programmers skill set. The system could be written into the license so that once the job is performed the code is open for general use.
Jeoin
But NO... these people will use a bounty, leading to perhaps many people competing for a puny amount of cash -duplication, anyone? And who wants to bet we'll end up with horribly unmaintainable spaghetti code everyone would rather re-write from scratch than reverse engineer because it lacks comments? Haven't we all kvetched about the horrible code that was shipped out to meet deadline with no regards to readability? A bounty would only make this worse.
Information: "I want to be anthropomorphized"
...I agree with the poster who mentioned the competition aspect of this. Many, many people will code for money, but the really good ones code to not only put food on the table, but know that they can be or are the best at what they do.
Don't be a looter...and yes, I know that it's spelled with an "A" instead of an "E".
The Horde Project does the same thing. They have bounties for writing specific features for their framework.
So long as the project is very narrow and specialized, I don't think it's a bad thing. This particular example, though, is very broad and we as the end users may not end up getting good code from the "losers" incorporated into that driver.
There is a difference between "insightful" and "inciteful" other than spelling.
Would be nice if the J2ME bluetooth specification would be implemented on PalmOS. That way we could write real cross platform applications for handhelds.
I just don't trust anything that bleeds for five days and doesn't die.
1. Release new hardware with crap drivers
2. Have community pay you to write decent drivers
3. Double++ PROFIT!!
The last visible post on the forum thread is...
"This was just posted to slashdot... "
Now of course, the server's down. Famous last words.
True believers seek redemption from the sin of death.
A developer rushing out code to win money isn't likely to test it thoroughly, and networking drivers are something that need to be reliable. Whilst it's a great way to get development started, this offer doesn't stipulate that the driver be Open Source, which IMO is vital for such an offer to be worthwhile. When the bugs almost gauranteed by rushed development become apparent, the winner isn't obliged to fix them... We don't need more rushed proprietary drivers, I'd like to see some more Open Source programming contests...
I think the [MS Word] paperclip is a great idea. - Miguel de Icaza
It's not bloody likely. On two counts. The first being that the Treo 600 may not be compatable. I chased down individuals at the last PalmSource and tried to get to the bottom of why the 802.11 SD drivers where not being released. The main answer was that on some devices, the card would draw too much power (802.11 suck current, fancy that!) and could even fry the unit. ouch!
The second is more political than anything else. Starting with OS 5.0 (and someone correct me if I'm wrong) the drivers aren't as easy to hack, the least of which is that they have to be in native ARM (as opposed to the PACE layer) Hell Armlets^H^H^H^H^H^H^H PNO's where like pulling teeth to write till resently). Things get worse in OS 6.0/Cobalt where the vendor can choose (and PalmOne will, if they ever release a Cobalt device) to require the drivers be signed in order to run. Great for preventing viruses, sucks for hackers such as myself that might want to hack on a device that I may not care to sell/commit to developer fees that may apply.
And all this before reverse engineering the card itself. Better off to wait and hope that PalmOne releases a Treo with Bluetooth built in (nudge, wink)
That aside, no hurt in trying!
Anyway, it sounds like Peter Easton at Whizoo has already suggested a starting point - rip the BT drivers from the Tungsten|T and rewrite the Palm OS 4 SD-BT transport layer PRC for ARM/OS 5. If all this driver does is receive calls from the main BT driver and dispatch calls/receive callbacks to/from the documented SD API, then perhaps it's not too difficult to rip it apart and figure out what it's doing and rewrite it? That's a big if of course. I've never really reverse engineered a Palm app myself, though I've done a decent amount of Palm OS programming (games and apps).
But apparently IDA Pro supports Palm OS and M68k, so that might provide a reasonable route to disassembling the OS 4 transport layer PRC. Anyway, that's about as far as I've gotten with this - if anybody is interested, let me know, I do have some free time right now and I wouldn't mind putting it into solving this rather annoying problem (no, I don't really give a hoot about the bounty, but I'm going to go contribute 50 bucks to it anyway - I'd pay 100 bucks right now just for a copy of a BT driver that let me use my damn Treo 600).
Sure, if you have a job, you might not be able to spend extra time on writing OSS, but what if you don't? There are plenty of students who code, and could use some extra money. And with coding jobs being outsourced...
Please correct me if I got my facts wrong.
Yeah, a little.
A lot of hardware R&D now goes, not just into the actual hardware, but into the firmware and driver that are required to make the hardware work. And while it seems like a copout, there are often good reasons that a company wouldn't want to give its competitors access to the work that went into that firmware/driver. Any time a competitor can gain access to your expensive, paid for development, for less than you paid to develop it, a company is not likely to do so - unless, like OpenOffice/Linux/etc, there's enough likelihood of external development that your contribution earns you the right to use a lot of someone else's work. OSS only works corporately when the corporation says "If we put in X, we get to use software worth Y" where Y>X, often Y>>X. Unfortunately, in hardware this is rarely the case, as a competitor could just clone your circuits (not hard) and your openly released firmware, never improve the firmware except when you do, and sell the hardware cheaper than you can because they didn't have to fund any development of firmware/drivers.
In addition, there's the everpresent FCC bogie, which the companies that do wireless hardware use as a "Hey, if we give you totally unfettered access to the card's abilities, you could do something illegal with it, which would come back to haunt us". Unfortunately, they're probably right - it would come back to haunt them.
So, yeah, the idea that hardware is going to opensource its software is flawed, I think.
---
Mod me down, you fucking twits. Go ahead. I dare you.
(I read with sigs off.)
It seems to me that a better idea for this type of thing would be setting down criteria for a finished product, starting or selecting an OSS project for the product, and once the project meets the criteria, all coders who contributed to the project get a percentage of the prize based on the percentage of code or content they contributed.
Say I wanted a database interface for a recipe program. I want it to be able to import data from some of the more popular cookbook programs out there, Betty Crocker or whatever, and I want to connect to something that amounts to FreeDB for recipes to get recipes from the web. I want it to be able to convert recipes and I want it to be able to give me nutrition info for the meals. I want to be able to make a menu and print me a shopping list, I want to be able to put in prices and know how much I will be spending(approximately). I want an easy interface for entering new recipes, and if I designate it as an original recipe or one with no copyright restrictions, I want the option of uploading it to the database mentioned above.
So it seems to me I would be best off offering small rewards at the milestones, say 500 to 1000, depending mostly on budget, and a large one when it meets all the criteria. Now, and individual might choke on this, but maybe a hotel chain or restaurant chain would be willing to sponsor it, because it's a one-time expense that they can then use forever, or a long time, whereas before they were coughing up 2K everytime they wanted a new license, which adds up after 20 new restaurants. Then those same coders could turn around and put together a package of OSS software that caters to the needs of mom and pop restaurants, OO.o and the above idea, GNUcash, and whatever else they might need, train them how to use it and help them set it up for maybe 5k or so, wash rinse repeat, you have yourself a viable OSS business model.
Drop me a line at:
Key ID: 0x54D1D809