ReactOS Fundraising 2012

[milon]

+1
That's a great idea!

[swight]

Since the discussion went in this direction I thought I would bring up this page

http://www.reactos.org/wiki/CFI

This is what happened when we started funding individual ideas. Main thing being that almost none where ever completely funded. Most you could never tell if they were completely funded as they had no required funding amount(this should really be fixed if possible assuming the page isn't completely abandoned).

Though in this case it could be a bit different as money is pooled and directed to one sector with a fixed dollar amount.but it would be nice to have a heads up as to what the next contract will be for.Next couple could be even better as we could have people rush funding on the current contract to get to funding the contract they want to see happen. you don't have to reveal who is doing just what is going to be done.

One thought I had if it can be applied is that if one of the contracts co-insides with a CFI idea to put any funding already put into the CFI towards the contract rather than pulling from the main fundraising fund for that amount and put a notice on the CFI page that the amount was payed out in contract(maybe with a link to the public contract notice). As I understand it this money is essentially sitting in a proverbial cloud that no one can reach. For example if the goals are met by more than one person who gets it? Same goes for if the goals are never met or defined.

[Z98]

well there is something i wanted to suggest when i was reading along page 4 please note this is completely unconnected to the page 8 discussion! (i dont want to imply that the devs are cheating with the money!)

The fundraising picture on the top could be better designed and include a statement for what the donated money will be spend exactly.

lets say this:

3000E ] 3000E ] 3000E ] 3000E ] 3000E ] 3000E ] ....more money
-----------]----------- ] -----------]----------- ]-----------]----------- ]-----------]----------- ]-----------]----------- ]
Kernel ] Win32 ]USB ]memorym]wifi ]Installer ] To be anounced by the donator

The benefit of this could be A) people get more involved with the knowledge which might result in B) Someone want to see usb improved and will donate double till the usb field is filled.
C) Someone could donate for only a special field later on which again would raise the motivation.

This would be incredibly inaccurate/misleading, as contracts are based not only on areas that need work but the availability of developers to tackle them.

[andreas84]

3000E ] 3000E ] 3000E ] 3000E ] 3000E ] 3000E ] ....more money
-----------]----------- ] -----------]----------- ]-----------]----------- ]-----------]----------- ]-----------]----------- ]
Kernel ] Win32 ]USB ]memorym]wifi ]Installer ] To be anounced by the donator

The benefit of this could be A) people get more involved with the knowledge which might result in B) Someone want to see usb improved and will donate double till the usb field is filled.
C) Someone could donate for only a special field later on which again would raise the motivation.

This would be incredibly inaccurate/misleading, as contracts are based not only on areas that need work but the availability of developers to tackle them.

It is only a draft the developers if they want could go ahead an make it more precise and sophicated
As example check where is the manpower what has to be done right now and make the plan how to use the money right now instead of after the donations are finished - this would speed up the process because the programmer can start now.
When the plan is already very detailed it makes donators more willingly to donate as they see exactly what is going into. So one could make a donation plan and publish it when the visitors click on the donation bar in the top...

[Webunny]

well there is something i wanted to suggest when i was reading along page 4 please note this is completely unconnected to the page 8 discussion! (i dont want to imply that the devs are cheating with the money!)

The fundraising picture on the top could be better designed and include a statement for what the donated money will be spend exactly.

lets say this:

3000E ] 3000E ] 3000E ] 3000E ] 3000E ] 3000E ] ....more money
-----------]----------- ] -----------]----------- ]-----------]----------- ]-----------]----------- ]-----------]----------- ]
Kernel ] Win32 ]USB ]memorym]wifi ]Installer ] To be anounced by the donator

The benefit of this could be A) people get more involved with the knowledge which might result in B) Someone want to see usb improved and will donate double till the usb field is filled.
C) Someone could donate for only a special field later on which again would raise the motivation.

This would be incredibly inaccurate/misleading, as contracts are based not only on areas that need work but the availability of developers to tackle them.

z98, you may have missed it, thus I'm re-posting it again:


That's why I also do not quite understand what z98 said about the 'project working'. If I understand you correctly, z98, the devs are now going to get some bonus, when they accomplish something? Say, if one gets the usbstack for usb 3.0 working, one gets 500 euro (as an example). Is that right?

In that case, I still think there is something missing, if you look at it logically, and want to spend the money as efficiently as possible (from the standpoint of speeding up Ros development). Contrary than some others might, I don't doubt the good will of the devs, and I'm sure they won't 'fraud' us, and claim things work when they don't. But that's not really the point.

What, for instance, is the gain by giving bonuses (aside from making the devs a bit more happy), if there is no time-limit set on to it, which is shorter than it normally would be (now). By that, I mean: with or without the bonus, the usb3 stack thingy will get solved, eventually. Say, it takes another 6 weeks. If we now give a bonus to the dev who makes it, but *for the rest nothing changes* then the other poster is right: it's a waste of money, if one looks rationally at it. One might claim the dev will feel a bit more happy and thus work a bit harder on it and maybe he'll finish it in 5 weeks, but really, that doesn't seem like the most efficient way to speed up things and to spend the limited resources we have on it.

The only way that things are really going to speed up - if one isn't going to hire new devs - is by having the assurance that the dev(s) in question will be spending extra dedicated time on it, be it full time or half time, but in any case, far more than they are doing now. Otherwise, it really makes little sense giving donations for just working on it as usual, since they're already doing it. Either - due to the donations - there is more time spent on it and the pace picks up, or more people are hired working on it; that are the only two main possibilities to speed up the development in an efficient way.

Thus, my question is (because you didn't quite answer this one): Is it, or is it not, going to be used to actually buy extra time of/from the core devs? Is anyone of the devs really going to say: ok, I'll quit my job, and I'll dedicate myself full-time (or half-time) on Ros, for x months?

Surely you must see the logic, z98, that to let the development of Ros go forward as fast as possible, you either augment the amount of people working on it (hiring new devs), or the amount of time that is spend on it (dedicated time of the core devs).

Is this the case, in the current plans for the donations?

[Z98]

I can't make blanket statements about ratios of time dedicated for free versus by contract. Every developer situation is different. We have several developers who are currently students, while others are graduated and have full time jobs. In the case of students, they may have a part time job that eats into how much time they can work on ReactOS, whereas if they took out a contract, it would end up being that part time job and thus we get a net increase. For full timers, the situation might be more complicated and we may not see a significant net increase. Then there may be others who are between jobs and thus have more time to take on a contract, etc. While it is obvious that the most "efficient" use of raised funds is to pay developers to dedicate more time than they normally would, whether that is possible or feasible across the board is uncertain/unlikely. As such while I and the others expect a net increase, we do not expect some miraculous increase in time dedicated.

[andreas84]

Well then let me again put it different...
z98 do you have an slight idea how the funds might be distributed? I mean some blueprint in your head?

If so i suggest to take the blueprint to paper and then publish what you think is not too internal. So the donators can get a small idea for what the money will be used.

[milon]

I was originally under the impression that a given component of ROS would be worth a set value, and would be paid to whoever completed it. Now I'm not so sure. I would like to know how it is decided to distribute the funds. Is it based on time? Are there other factors?

I feel (and I assume others do too) that the targets should be specific enough that we can know ahead of time how much will be paid for what. In that case, we need only to have an available developer. Even if we can't forecast that ahead of time, could we "mark off" what funds already have a designated purpose. The first contract has already been made, so we could show that in the Fundraising Progress Bar. It's more reactive than proactive, but it gives a visual idea of specific things being accomplished with the money donated.

[AmineKhaldi]

Please note the fundraising idea that I pushed for was directly inspired by the work that our friends at haiku did, since they tried the bounty system but it didn't work, yet the contracts system helped them accelerate the development (http://www.haiku-inc.org/funded-development.html)

Let's go over the plan again, in case anyone missed anything from it:

• The community helps raising funds.
  
• Developers issue funding requests like the ones I linked to, where they mention the cost of the contract, how many hours it will guarantee, and a summary of the planned work.
  
• The ReactOS Team examines the request, negotiate with the developer if some terms need to be adjusted, or that there is a queue due to lack of funds... and so on.
  
• Once the contract is accepted by the Team, and we're able to fund it with what we have, it gets announced publicly, which includes the website, the forum, the social networks...etc (like what happened in our first contract). Otherwise it will be announced with an explicit mention that it won't start yet, because we lack the funds (how much we have, and how much we need...etc).
  
• The developer starts working within the terms of his contract, so everyone will notice that the amount of work coming from him will increase (relatively of course, no miracles, but better than what he used to do in his spare time, which is already well worth it) and everyone (most importantly the community) is able to, as always, review this work (his commits, his bugzilla activity, his irc activity, mailing lists...etc).
  
• Once the contract is over (the paid hours are completed) we issue another announcement, using the means mentioned above (website...etc) where we try to make a summary of what did this contract bring to ReactOS. This step will help everyone even further, in reviewing the work that they helped fund.
  
• The developer is free to issue another funding request, if he can still allocate time for ReactOS as a paid job again, this is in fact what we hope for: gradually integrating ReactOS development into his life, and allowing him to be paid to work on the project that he used to contribute his spare time to.

As you can see:

• We're trying to keep things transparent to the maximum possible.
• We can't know who among the developers will have the time to do a paid contract for ReactOS, for example developers with full time jobs already contribute their spare time to ReactOS, so for them this is a case of "money can't buy time" and as a result they wouldn't issue funding requests.
  
• The developer who issues a funding request will create a summary of what he plans to work on, but that doesn't guarantee the achievement of all what has been planned, because as you probably know, hidden milestones may come up when he's developing something, and he'll be forced to fix other things (and spend more paid hours here) to be able to continue on his original plan, so as you can see it's not possible to determine, beforehand, what will the contract exactly cover.
  
• We chose to accept only funding requests from ReactOS developers, i.e. developers who have commit access to ReactOS, and the reasons here are hopefully obvious, but for clarity let's go over some of them off the top of my head:
  
  • Contracts like this are mainly based on trust, since we can't possibly know for sure how many hours the developer has spent, and so we can't know for sure whether he fulfilled the contract hours or not. We can estimate that from his work, but estimations are rarely 100% accurate as you know.
    
  • Contracting outsider developers means wasting so many paid hours on the learning curve, and we won't even be sure whether that developer will "get it" in the first place, so it's a very high risk compared to developers who spent so much of their spare time building ReactOS from the ground up. Take for example GSoC, where even though students had mentors, two of the outsiders failed, and only one succeeded with the help of not one mentor, but two (The case of lwip student, Mihail, mentored by Cameron and Arty) which is something the paid contracts don't offer (you won't be mentored because we assume you already can work for money).
    
  • Opening the funding request to ReactOS developers only, will encourage outsiders, who want to be affiliated with ReactOS (to improve their CV, career chances...etc), to join the development, submit quality patches, and eventually get commit access (that's how it works BTW, there is no red tape, you show commitment to help ReactOS, provide a good deal of quality patches => you get commit access) and be eligible to such contracts. With the proper PR this message can be widely adopted by these potential new developers and that fits perfectly into the reason behind the contracts: Accelerating the development.

I hope this serves as a good, clear, quick summary of the plans behind this fundraising idea. It's already showing great signs with the first contract, and hopefully more developers will be able to allocate more time like this for ReactOS

[HJRodrigo]

I haven't read the whole thread yet, so I don't know if it has already been suggested, but opening a kickstarter campaign might be a better way to raise funds. Ouya had a lot of success, so studying their methods maybe a good idea. They focused on being an open console and an alternative to the established systems. They even broke the record for the most money raised on the first day and got more money ($8,596,475) than their goal of $950,000.

[Haos]

@HJRodrigo

It has been proposed many times. ReactOS project is not really fitting into a Kickstarter project, not to mention that this site only accepts submissions from USA.

Be a US resident and at least 18 years of age with a social security number (or EIN), a US bank account, US address, US state-issued ID (driver’s license), and major US credit or debit card.

[Saibamen]

It has been proposed many times. ReactOS project is not really fitting into a Kickstarter project, not to mention that this site only accepts submissions from USA.

Thanks for the quick reply and information. That is a shame since kickstarter is so popular, but there are alternatives. I asked around and was recommended Indiegogo. It is more lax in its rules and apparently more "International" friendly.

[Acamapichtli]

ReactOS needs an intense promotional campaign in order to reach the goal this year.
for example
buy some ads in popular magazines and newspapers.
grant any interviews for radio, television, podcast and alternative media.

[joblack]

Is it tax reducible (especially in Germany)?

[Z98]

They are tax deductible in Germany and any country that recognizes German registered non-profits. One would think this encompasses the entire EU, but there are a few countries who have been, slow, to update their laws.