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.
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
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.
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.
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).