Goals will be completed my point is we are employing someone, they will be paid for the work they do. They may leave before completing the whole goal but this does not mean they wont be paid for what they have completed so far. The work would just be picked up by someone else.Sorry but then whats the point if the goals are not completed.
I'm working in a scientific environment and there Science is planned very often with a similar Milestone system introduced in this thread; the problem is: this has a very large overhead.
Very often you find yourself wasting time writing reports about which milestones you achieved and which you didn't in a timeline. Having those milestones increases the stress put on you, too, and you will not be able to work freely. With drivers the milestones will be clear anyways (make THING A faster, get Power Management to work, Video decoding!), but the order of them not so. Developers will need to priorize tasks, which would be hard with imminent milestones. <- It's a flawed system, but still a valid choice for this project.
In Science this is necessary, because as was already said in this thread, otherwise people would scam a lot of money out of the funding agencies saying they develop flying cars and simply spend the money on booze. Funding agencies cannot trust Scientists blindly. They also _need_ good results to show to the people paying the bills.
We are in a bit different situation here and I'm writing this thread to point it out. There are already developers in the community I trust blindly (and would throw my money at) and I think many of you do, too; one example would be David Airlie and other X developers. Most of these developers are however already paid fulltime. These are the people, who would know best how to spend the money talked about in this thread. So instead of planning milestones and when and how to pay here I think the best solution would be to ask them: "Hey, do you need money? How much money do you need? If you had _this amount of money_ how would you spend it?" The trust relationship would then allow us to spend the money no strings attached without putting further pressure on them.
Yep, the another option is that the big projects (Kernel, X, Mesa, KDE, GNOME, etc.) will collect funds and suggestions from users.
I can suggest to X, Mesa and Kernel teams that further development of opensource radeon drivers and I'd like to spend my money to that development. For example, there are 50 users that want further development of radeon drivers. We send our money to X, Mesa and Kernel teams and so creating the fund for radeon drivers. In turn X, Mesa and Kernel teams organizes a special contest like GSoC and XorgEVoC with special emphasis on radeon drivers.
Such a strategy is more flexible, I think. First of all, mentors from the big projects can formulate an appropriate task for each developer. Also they can control the development process and the quality of code. Also they can evalute the suggested project.
Yes, I know that donations are possible for (almost) every big project or even to special organizations (like SPI, http://www.spi-inc.org/), but I think that the existing donation system should be improved. Yes, I like to donate my money for X, but not for everything in X, I like my money to be spent for radeon drivers. And so on...
Last edited by dogsleg; 06-24-2012 at 03:13 PM.
No doubt this should be handled by some trusted foundation like those mentioned.
But should it be
- Kickstarter type; developers suggest something and people donate?
- Just salary for hiring someone for short term projects
Then another question is how fine grained should be specific tasks be. Donating for driver development is bound to lose interest if it doesn't mean someone will be working on some hardware the user actually has. I wouldn't want to care to donate.
At least I am only interested in seeing my money go to projects I care about myself, and I'm sure others feel the same.
The more I think about this bounty approach the more I start to dislike it. It's not compatible with how driver development works.
There are developers that would like to start contributing (or contribute more) but cannot find the time (and hardware) to do it. We could buy their time with donations but shouldn't get in the way of the work they're doing. We haven't even discussed maintenance. It might be a full time job to fix bugs, fill in gaps and keep all the shiny features up to date with the rest of the world. That could be a full time job in itself. I doubt anyone would put bounty money in the "Rewrite part X for API change x.y.z" but without it your screen might go blank in the next kernel release. The bounty approach will also result in poor quality and a less stable driver.
Let the donations be for developer hours, not features. I'd be just as happy donating for that cause.
I got the impression that this was essentially to pay a salary to a driver developer in order to employ them full-time (hence the recurring donation) it wouldn't take that many people to put together a decent salary. I thought this might work as a developer who has an unrelated day job might be persuaded to give up this job and work purely for the donated salary, giving them more time to continue the good work that they do. It may even provide a job for somebody who's currently studying but will graduate soon (but for some reason is not able to join one of the open source teams).
@timothyja: The FreeBSD Foundation might be worth a look - it was they who hired Konstantin Belousov to bring Kernel Mode Setting for Intel GPUs to FreeBSD, so they would probably be able to help with most issues that may arise.
1) Watch this, this is vital for you and any management member of this project: http://www.youtube.com/watch?v=ZSFDm3UYkeE
2) Have you found the single unique website/forum topic** where you will COVER THESE SEPARATE TOPICS:
-- publish the sum up of the CURRENT approach. In read-only.
-- publish current goal, required bounty, amount collected so far. In read-only.
-- publish status updates, this is absolutely required. In read-only.
-- where people can SIGN UP. Only this. No discussion. This is so you or your team can track them back to contact them when you have your OFFER.
-- where people can write up ideas and discuss them.
Please separate official policy, official progress and irrelevant human junk (such as likes/dislikes, ideas, criticism etc).
** (or at least protected against hostile takeover by paid microsoft trolls)
3) Have you contacted the people @ Xorg, LKML, Wayland for locating first simple task?
Contact with them is absolutely required, because there is NO reason to write something up, which will not be accepted upstream.
Please do not position your program as a replacement for Xorg endless summer of code or AMD/Intel opensource program, but as another way for people to support single goals we all have.
This can end up deadly if your public response to them is opposite. Good ground for microsoft trolls to troll you down. Be aware.
4) Start SMALL, cover everything relevant up, exclude unneeded things!
Linux. Not freebsd, not openbsd, not haiku.
Small task. Not OpenGL4.
Single place to get people informed. Not mirriad of forums.
Good license. Think twice if you pick up un-free license as BSD! "Public domain" is even better license in this case!
Because you have magnificent idea, which MANY will support, but I detect negative :
- people are turning good idea into endless useless discussion loop of finest details, which WILL NEVER EXIST. We are planning to go out and they start arguing about which amount of tin cans is optimal for normal human.
Fact is: they are polluting the topic with useless things.
- people are writing up their (useless) doubts.
Fact is: don't like? DON'T BOTHER.
- people signing in, but have no status updates, it is difficult for you to track them down and inform them.
Fact is: only people that support you, not those who dislike, are unsure, doubtful, are relevant for you. Start small, start realistic, focus on people that really care, do not waste energy.
Haiku has already gathered 2k$ to port Gallium.
Did it work - YES.
In fact, in several WEEKS.
Linux is much more popular than Haiku and offers much more choice.
We can reach HUGE goals if ball rolls properly.
Last edited by crazycheese; 06-25-2012 at 06:57 AM.
The correct strategy is single entity with clear goal that focuses solely on commercial open-source solution.
1) negotiates the GOAL with project X, Y, W, Z
2) with people VOTING on variants later on
3) publish required MONEY.
4) wait for coding offers.
5) check best variant (together with affected entity X, Y, W, Z) and give money to programmer.
6) submit the result upstream to (X, Y, W, Z)