Sponsor An Open Source Driver Dev For a $1 a Day???

[ssam]

Raising the money will probably be the easy bit.

Working with Xorg would be good. try to grow it out of their EVoC, get some short term student projects, and the ones that are successful could be extended.

Otherwise you might need to get a suitable company on board who can receive the money and pay somebody wage. It might be worth contacting companies like yorba, fluendo, collabora, codethink etc, and see if they would take on someone paid by a community fund.

You could also contact the krita developers. They successfully raised $4000 to fund a student. http://linuxcrunch.com/content/krita...C4000-donation

[geearf]

I have been thinking about doing that for years too!
(But in my mind it was not Driver-only).

There are plenty of very talented people that release awesome software everyday for nothing in return (thinking of Marek for example), maybe we could help them help us...
Count me in!

[AnonymousCoward]

OMG First I thought great idea, after reading this that it would mainly come to the nouvou driver guys, I hate that idea, why would we sponsor guys to make a good driver for a company that blocks such stuff so good it can and not release any specs or something, then we help that company to get deals like that in china posted here somewhere, so we work very hard or pay money so that the company that sucks dont get punished for sucking on this area?

Just limit the nouveau sponsoring to gpus that aren't sold anymore.

[patrik]

Sounds like a brilliant idea. I'm a freelancing programmer that would gladly take on this challenge and I would definitely also donate to such a project.

Here are a few points that I think are important (based on my own experience):

1) Let the developers decide what to work on. Forcing it in a certain direction will lead to things being done in the wrong order or in the wrong way. The natural order of how to do things will likely be revealed when development has actually started.

2) Make the developers publicly report status and progress on a regular basis. Weekly would be preferred. Doesn't have to be much but people will want to know what their money is being spent on. Wolfire is doing a good job with this (blog.wolfire.com) on Overgrowth.

3) Don't put up deadlines. Deadlines should only be set by people who knows how long something is going to take. Nobody can say how long it takes to figure out a GPU. Milestones are fine as long as you don't put a date on them.

4) Make sure the work is documented. Writing documentation is boring, but in order for things to eventually work out it is required (see #5)

5) Allow failure. Sometimes things don't work out the way you intended. A developer might come to the realization that they are not the man/woman for the job. Allow resignation and don't make a big fuzz about it. With documentation the money is never wasted. That way a developer can easily say they're stuck and let someone else pick up where they left off. We don't want people sitting around doing nothing because they are stuck but still getting payed.

6) Prefer people with real world experience over students. This is because a fair amount of project planning will be required and the project will probably not be supervised like in school. Good understanding of how to plan and manage a project (even though you're the only one in it) is something you learn only after a few failures. Of course there are exceptions and students might be easier to find and employ.

7) Don't aim for the sky. Keep the expectations on a reasonable level. Wages will not likely be up to par with what the hardware manufacturers pay for their in-house developers. Because of that, we cannot expect to get the same level of expertise and speed of development.

8) Keep the figures public. Clearly state everything on a website. If that information isn't publicly available, we will get all kinds of rumors going.

9) Don't write long "contracts". Money needs to be secured for maybe a year or more, but don't promise more than a few months to a single developer. That will force them to make sure something is delivered back to the community on a regular basis. This will reduce the risk but perhaps make some devs look for something else. This is obviously something that needs to be tuned over time.

10) Make sure it is legal. Somebody needs to research this. Perhaps EFF and/or FSF could help with this.

These are the things that come to mind. I'm sure there are a lot more things that could be added to the list. Feel free to discuss.

[Kamikaze]

Great idea, I'd contribute a dollar a day.

Yes, the idea is in the air. I'm in. Many others here suggested close ideas. So, it is in a very need, almost necessary now.

Last time I suggested that:

I think that it will be very useful. Also I think it should be like an open auction. Users could suggest ideas to developers and developers could offer a price and a project-time (time to implement the suggested feature); then users could choose a developer with an appropriate experience, price and project-time and send him (her, them) money.

I like this idea, but as suggested before we don't want to fragment the money too much so that it becomes insignificant. Perhaps we could do a variation on this like:

* Users donating can suggest development ideas of their own, or vote on existing ideas and would need the ability to log back in later and change their vote (incase a new and better idea comes up)
* Developers interested in working on the projects would submit a cost estimate p/month to work on the feature, and submit CVs inc. previous experience to be viewed in a list of developers on the site.
* After a certain amount of time passes, perhaps have a nominated day every 3 months or something, a selection round happens, and the top voted features are paired up somehow with a good developer (if more than one developer has submitted a cost estimate against a particular idea)... haven't thought this bit through - not sure who could choose a developer - perhaps another voting type arrangement?

Obviously this means that some features wouldn't make the cut and some people may not be happy with this, but it will at least get the most voted features implemented, and allow the end developer to be given enough money to comfortably complete the task. I know I'd still contribute happily for other features to be implemented that I didn't vote for, knowing that eventually the ones that I do care about will get there in the end as more people donate or other tasks finish.

[l0b0]

Excellent points, patrick.

1) Let the developers decide what to work on. Forcing it in a certain direction will lead to things being done in the wrong order or in the wrong way. The natural order of how to do things will likely be revealed when development has actually started.

This might work if they do it Valve-style and with enough devs, but for crowd-sourcing I think a lot of them would want a definite list of work items before committing money to such a project. Verifiable goals or a test suite would be awesome.

6) Prefer people with real world experience over students. This is because a fair amount of project planning will be required and the project will probably not be supervised like in school. Good understanding of how to plan and manage a project (even though you're the only one in it) is something you learn only after a few failures. Of course there are exceptions and students might be easier to find and employ.

Agreed, but students could be hired to do lots of tangential work, like developing test suites, writing informally about the project by sharing space with the devs for a while, acquiring test hardware, liaising with the vendors, making the web site for the project, etc.

7) Don't aim for the sky. Keep the expectations on a reasonable level. Wages will not likely be up to par with what the hardware manufacturers pay for their in-house developers. Because of that, we cannot expect to get the same level of expertise and speed of development.

9) Don't write long "contracts". Money needs to be secured for maybe a year or more, but don't promise more than a few months to a single developer. That will force them to make sure something is delivered back to the community on a regular basis. This will reduce the risk but perhaps make some devs look for something else. This is obviously something that needs to be tuned over time.

I don't know about the wages - If this project is to succeed, it will have to attract top notch devs, and I don't think they will be willing to relocate (see earlier post) just for a few months. Also, based on experience, for any complicated project (and this is sure to qualify) the productivity will be low for a long time (weeks~months) until all the aspects are familiar.

On the other hand, it seems like such a waste to use money to develop something which already exists, and which the hardware manufacturers could virtually at any time decide to open source. Maybe NVIDIA's recent loss (if it's actually real) may soften them to the idea of opening up...

[whitecat]

I will contribute too!

[ChrisXY]

It seems a "rewarding" system would solve some problems here.

For example I want the r600g driver do OpenGL 4.2. So I can create a pool "OpenGL 4.2 for r600g" and pay my money to it, probably also search for existing pools and contribute to them. Then the money just sits there on some bank account and accumulate interest.

Then some developer comes along, thinks "I can do that" and somehow attaches his/her name to the pool so that people know who is working on it. And once OpenGL 4.2 works on r600g he gets the money. Maybe you could get part of the money for a part of the work.
So there would have to be a committee that decides several things: Is it feasible to add another developer to a pool? If there are multiple developers in one pool how much work as each one done and so how much money does each one get? Maybe, is a developer trustworthy and skilled enaugh to get the money in advance?

So that committee should be trusted by everybody to make good decisions and developers and the committee should probably sign something legally binding that the developer does the work and then gets the money afterwards.

[x616e]

This would be great.

Currently I would be willing to sponsor.

Radeon 7000 series support. OpenGL 4.2 and OpenGL Stereo 3D
990FX series coreboot support.

For me coreboot needs a bit of donation love as well as the open source graphics drivers.

[patrik]

It seems a "rewarding" system would solve some problems here.

For example I want the r600g driver do OpenGL 4.2. So I can create a pool "OpenGL 4.2 for r600g" and pay my money to it, probably also search for existing pools and contribute to them. Then the money just sits there on some bank account and accumulate interest.

Then some developer comes along, thinks "I can do that" and somehow attaches his/her name to the pool so that people know who is working on it. And once OpenGL 4.2 works on r600g he gets the money. Maybe you could get part of the money for a part of the work.

Your idea is interesting, but I don't think it is feasible. It could work if you put up rewards for very small problems like bug fixing. But stuff like OpenGL 4.2 i just a too big time investment. I would say, start slow and hire a single dev to either work on AMD, Nvidia, PowerVR or similar but don't steer it much more than that. Sure, we need a goal (OpenGL 4.2 or whatever) but make sure the people giving donations understand that it is what we aim for. Not what will be delivered after XX months or so. I've been freelancing for 5 years and I would never put myself in a situation where I'm unsure when or if I get paid at all. Every hour spent must give something back or I cannot pay my rent. It's that simple.

So there would have to be a committee that decides several things: Is it feasible to add another developer to a pool? If there are multiple developers in one pool how much work as each one done and so how much money does each one get? Maybe, is a developer trustworthy and skilled enaugh to get the money in advance?

So that committee should be trusted by everybody to make good decisions and developers and the committee should probably sign something legally binding that the developer does the work and then gets the money afterwards.

A committee is a good idea. A few people with technical insight who can act as a barrier between the people donating and the developer. Those who donate might be screaming about OpenGL 4.2 but have no clue to what it really is about or how hard it is to implement. They just need it for game X or Y because it says so on the box.