$$$$$$
Please excuse the length of the article. It has been in the making for quite some time now. I still think the issue is worth the length 
I’ve thought about this during the last weeks and have come to a certain conception, which might deal with most of its issues. But before talking about the details I’d like to think about the general situation first.
The idea about bringing money in to develop FOSS software is surely not new. The issue of fundraising might be a really difficult one as it has been pointed out lately here: http://forum.kde.org/payment-donation-to-get-bugs-fixed-t-46860.html
Still FOSS was never meant to be cheap labour (or free as in beer), so there is absolutely nothing wrong if every FOSS developer would be paid as high as or higher than a commercial developer for the same work. In fact many experienced devs get hired by commercial employers like Novell/Ubuntu/Trolltech/Nokia sometime,… and lately a rush of young developers has been pumped in by Google for GSoC. So a two-class society of paid workers and unpaid contributors is already a fact today. Still it is not as feelable as it would be if the different payments for work in FOSS would be as transparent as the following approach proposes.
The illusion of some hobby developers to be equally participating in FOSS development like the commercial and professional ones would be deconstructed and might demotivate some people. Or to make it clearer the problem is that one can think quickly to be a “real” coder like the others, although in fact one is by far not as skilled and experienced and the work of others is much more worth. Today you can quickly declare yourself part of the dev-community and claim your contributions are of great value although relatively they are not.
But this has been already accepted for students participating in GSoC opposing unpaid ones and it seems to not have harmed FOSS (at least this is how projects reflect on GSoC).
The big advantage of introducing a per-feature/bug donation policy in FOSS would be that the current situation where only big sponsors, distributors or companies behind the FOSS project can influence and decide about the development without coding “themselves” (they hire developers) would be changed. In fact today a non-coding end user can do nothing to influence the development except for bug reporting.
Introducing a per feature/bug donation system would a) value the work of FOSS developers openly, b) it would allow average users to get their functionality without needing to spend years to learn coding. This is especially true for problematic areas in FOSS development like the X.org graphics stack and the graphics drivers or other specialized code, which has hit KDE and in general advanced desktop functionality a lot recently. It would actually introduce a symbiotic relationship between producers and consuments.
NOTE: This has not been an issue in the beginning of the FOSS development where many consuments of FOSS were also its producers and actually technology enthusiasts willing to participate. If the niche phenomenon FOSS is meaning to change towards “mainstream”, one has to take advantage of general users different than pointing them to create the code themselves, (which is plain stupid in a higly specialized society as we have today). If this is meaning to happen, instead of applying work directly, users would have to transfer “abstract” work in form of money to the project so new/additional developers get a social exchange. Instead of adding your own code/patches you can do support by money. This would also finally allow to make a living of FOSS without getting commercial.
Introducing a direct payment program for average users will truely make room for a much faster development and would be very different to do “blind” donations for some infrastructural costs. Again the improvements would attract more users and these will then again support features/bug-fixing they need. In all areas where FOSS has proven to be competitable over the last twenty years, it had to bind big commercial companies/interests into its development (I am talking about the Linux kernel, server software like Apache, storage solutions like MySQL or btrfs, MediaWiki, OpenOffice, WebKit, Firefox …).
On the desktop the competition with Microsoft is extremely hard and given the plain amount of developers compared FOSS cannot succeed, even if some central and older parts of the Desktop get on par or are better integrated, there is still much development on the borders of the traditional desktop (apps/widgets for special web-services or specialized software for content creation) and with new concepts in the core of the desktop (Touchscreens, small devices,…).
Not to mention the web services which are big competition to desktop software already and get sponsored by large companies like Google, which sponsors the Mozilla foundation for Firefox development with several millions regularly, which is magnitudes more than GSoC, btw.
Even a much more effective production method (like imo FOSS is) will get outnumbered if there are that overwhelming competitors like Apple or Microsoft. And they truely accumulate the money of their users for accelerated development. The only other option is to wait for other companies to largely support FOSS on the desktop, which is currently not happening and is much worse than to have a direct relationship to our users. Imagine how the current status of KDE would be if commercial support in form of GSoC, SuSE/Novell/Mandriva/Ubuntu sponsoring for KDE and the founding sponsoring of Trolltech/Nokia for Qt would be missing. Of course they have joined because they truely win from the process. The users won’t capitalize FOSS as they do, and still they could truely give accelerated development by the same magnitude difference and free the dependency on the companies.
Now the issue has been raised that paying for functionality/bug-fixes would be in the cost of bad code and less perfectionism. Well first of all this argument means that you a) should never use the Linux kernel as it is developped that pragmatic way since a very long time b) you should not use any commercially developped open-source code like e.g. Qt since it would be rushed-out code, too. The speciality about FOSS is that its quality can be discussed openly and therefore a patch-queue for paid patches can have clear quality discussions, take the Linux kernel for example.
And note: The projects are still not owned by anybody, it is still copyleft or OSS at least. Decisions are still made by the developers who work on the code and those again only get money if they improve the project from their users point of view, who can truely vote on the value of the solutions or support long term goals like improved security/better performance, too. FOSS already focuses on the openness of the product and that would not be changed.
And for all hobby-programmers, they won’t be excluded by any means. In fact you can decide if you want to work on something you like or on something you get paid for by the users (ideally it will be some combination of both). And by getting more feedback by users in form of support of development, hobby developers who work on it for “free” will be honoured more as well as it is more clear that they do something which they could get paid for.
Every growth will be beneficial to all users in the end being it paid or not. And we don’t talk about feature adding only, but also about bug fixing, which is not popular at the moment either. If I have an ugly bug which only targets ame and a few other people I can still show the significance of it by putting a ghigher amount of money on it.
Of course companies can hijack developments by pumping in a lot of money. But one might forget that a) they can do that and do that by hiring developers of the community already and b) there is no limited pool of developers, so it will be an additional support.
Since they do that privately today already, if they would be integrated into a system with the users, they would have to share their interests more openly.
My conception
Basically my conception would change the votes section to a money based one in the bug tracker. By doing it in the bug tracker one would have to go the same way as one has to go today. The difference is that instead of hiring your private developer, which you can do today, is that the development is integrated into the project and the patch will have clear conditions to enter the mainline code. You don’t know if it is accepted if you do it privately today.
The second advantage would be that many small “votes”, lets say 100*5€/$=500 would also work. The money would be frozen within KDE/a trust service of a bank until the bug is fixed. A developper can get the bug assigned by giving a deadline and a statement. If there are several developers, they’d have to discuss a solution first.
It would be:
1. The user creates a bug report.
2. The bug has to get accepted.
3. The bug gets assigned to a developer who is a maintainer of the code related.
4. Users can “vote” on the bug.
5. Once a developer decides to work on the bug, he tells in the discussion of the bug and gives a proposal with a deadline.
6. Users and the maintainer have a week or so to refuse the proposal of the developer.
7. Other developers can propose to join the development or make a better proposal.
8. After a week the bug gets a status of “frozen” until the developer posts the patch or the deadline is reached.
9. The patch is accepted and the project transfers 80% of the money to the developer. 20% are a “tax” for infrastructural costs or can be assigned to tasks which are necessary but not popular. If the developer who has written the patch is a commercial developer or does not want to get the money he can decide on which bug/features the “votes” are reassigned.
OR: The patch is rejected and the bug is open for proposals again. This can also mean that the proposed patch will simply get fixed in a new attempt by its creator.
I know that monetizing FOSS will introduce new additional work to control the cash flow. This is something that is not very interesting for tech people and can as already mentioned above deconstruct the community-feeling. But at least from the 20% one could get support for professional banking/legal services as well, so you don’t need to care for it.
There can also be conflicts between e.g. the maintainer and the patching developer, which might lead to an unfair rejection. To avoid this problem, one should be able to rate and comment on developers as well. That way every one can see transparently if there are problems. If the dev does not take money, he/she wouldn’t have to be rated though.
What do you think? Even if this sounds still “dangerous” to you, do you agree that the general idea about needing to get more direct support from users is necessary for the further growth of the FOSS Desktop?
If you already know this idea and have rejected it in the past, why have you done it?
Cheers,
whilo
I’m pissed by the “blogs are the new mailing lists” fad.
Frankly, this is a very sensitive issue, the kind of issue that is better discussed only by long term contributors who have a great deal of experience with managing a FOSS project.
Blogging about this will only generate random noise at best.
@Benoit Jacob I dont agrea with you, Think that making this problems more public is very important.
I’m not sure what the solution is, but there is defnetly a problem, example I submited talk for the Akademy and I’m still not sure I will have the money to go.
I don’t agree with rating developers, you either trust them to make the right call or forget it, they are the ones contributing their time.
And should there be disagreements between patcher and maintainer, I don’t think the maintainer would object working code just because.
Monetary incentivation really needs to be there, but of course it’s up to the KDE developers to figure out the best way to go about it, and blogging about it is perfectly fine. This is an issue that also concerns users who don’t read mailing lists.
And how bad could this system be? Just try it out for a month or so, and see what happens.
I think it is time to discuss such possibilities. However, I foresee a problem: most feature and bug donations will be directed solely to easily visible issues. Thus, such a system would discriminate against developers who do the heavy lifting by developing libraries, frameworks, etc. They would lose out against those who hunt for the low-hanging fruit which might make the desktop experience more pleasing, but are much easier to accomplish than creating the underlying base. Thus, library/framework developers could be turned off by such an environment, leaving only commercially supported developers do such work. Introducing a kind of “tax” as you propose might help in this regard if used well, but I can see the political divisions between (economic) liberals and “socialists” pop up.
The problem is not money, but that rational individuals will not donate because of the http://en.wikipedia.org/wiki/Free_rider_problem, and you end up with a selection bias towards bugs that are important to stupid people.
You’ll be draining brain from fixing the more important bugs, unless the payment gets you enough additional resources.
In other words, the question is not whether it is a good idea in principle or not, because it really depends on http://en.wikipedia.org/wiki/Price_elasticity_of_demand, and you have zero data to get estimates.
I think that especially Summer of Code is being exploited in a way that is not good for the community. Take for example Pidgin: New MSN support was started, but not finished. What was the consequence? The code laid around dormant until the next year when the same student got accepted for SOC to work on the same duty he worked on a year before.
That had nothing to do with giving students an opportunity to enter a FOSS community. He treated Pidgin and SOC as a regular job. Do something when you get paid, do nothing when you don’t.
On the KDE side one student blogged that he is in SOC the third year in a row. WTF?
“such a system would discriminate against developers who do the heavy lifting by developing libraries, frameworks, etc.”
I feel there’d need to be a certain responsibility for visible projects to “tip out” to their dependencies, in the same way that a waitress indirectly tips the bus-boy or the chef. Especially if the maintainer of the visible project is interested in engineering things “right”, tasks (and thus cash) would be delegated to sub-projects as appropriate.
Here are a number of things which come to my mind when thinking about what drives an individual to contribute to FOSS
* practical ones
– to learn from the best
– to ensure the quality of a project which one relies on
– to earn money
* emotional ones
– to get social benefit
– to push thing towards a open minded society
– to just have fun writing code
where combinations of the above are common, IMHO.
As soon as money enters the game, it will cause tensions. Today this means there is a risk that Novell/Nokia/Mandriva might push development towards directions the community majority dislikes. But from my POV this hasn’t been an issue, since these companies are aware that messing with the community will backfire very badly. If, on the other had, they win the community for their ideas, their efforts will be boosted by this very community.
Giving the users, so the community itself, the ability to vote with their money will most likely have negative and positive results. The positive ones have been mentioned by whilo. The negative ones are i.e.
– users in poor countries have less influence
– some easy bugs may be taken by grown developers rather than being entry points for new developers
– important but not to the user visible code might be less attractive to work on
These issues have to be discussed and addressed, where the time this takes is a downside by itself
However, there are always risks and there will be downsides. Most likely there will be a need for another important FOSS guild beside developers, artists, translators, lawyers…, the freedom loving economist
. But the potential win for FOSS is IMHO to big to not give it a try.
[...] Golf 101 Tips added an interesting post on Christian Weilbach (whilo): $$$$$$Here’s a small excerpt…one would have to go the same way as one has to … The second advantage would be that many small … 8. After a week the bug gets a status of [...]
Thanks for bringing up this topic. I think it’s crucial to be able to generate an additional flow of money into the FOSS community. As user with no hacking capabilities I would definitely jump in with a little money here an there to have others scratch my itches.
But a community definitely needs a guideline for this to be successful. Without you’ll have jealousies and frustration for sure. I have lived that in non-software communities more than once.
Have a look at this idea from KDE Brainstorm (http://forum.kde.org/integrate-cofundos-org-in-kde-brainstorm-t-39124.html) Unfortunately there has been no reaction so far, beside some negatives votes cancelling out the positive ones. I would be interested to know what you think of cofundos.org.
My problem with this idea is that when you start paying people to ‘complete’ certain tasks you will be encouraging worse quality code.
For example, developer X wants to make money from FOSS development. So X starts searching for all the ‘paying’ bugs/wishes. To make the most money, X needs to churn through the code, and as a result, gets sloppy.
I feel that with money involved as a formal thing will make the developers mindset shift from ‘writing beautiful code’ to ‘just doing enough to get the money’.
..pay for free software? wut? This is the absolute worst idea ever. I’d rather pay for windows or osx first..The only draw to Linux right now is the cost of $0 to users, I can imagine this pay thing working out terribly.
I believe that there was a study on that subject (bounties / monetary rewards in FOSS) somewhere, you might want to see if you can dig it up. The key point was that money does not necessarily add to the developer pool but *changes* the incentive for developers (also for existing ones), which is potentially dangerous for communities with a strong hobbyist/we-do-it-for-fun background.
If you do it right (prime example: GSoC) then it’s possible to bring good for the community, but one has to be very, very careful about this stuff. Don’t be light-hearted about this issue.
Thinking through all the issues, I think a “bounty” system would not be good, for the reasons mentioned here many times(Code quality, fairness, jealousy, etc.)
A much better solution would be this:
- Users can pay money for fixing bugs
- Once enough money is together, KDE e.V. hires developers, as many as money is available
- The amount of money paid for a bug is used as priority-measure for those developers to decide what they work on
The developers should be paid on a regular basis, with code-quality etc. in mind, without any bounties.
This would solve all the mentioned problems. The only problem is that it works only when the amount of paid money per month is at least enough to pay one full-time developer, but if it is less, then the whole thing doesn’t make any sense anyway.
If the generation of a cashflow is the target I’d suggest a similar idea.
1). You can spend money on a wish or a bug.
2). The bug gets resolved in the usual way. By anyone.
3). The money on the bug doesn’t get to the one who solved the bug but to a separate moneypool hosted by KDE e. V.
4). A special board elected from KDE e. V. members now can assign this money to certain non-popular tasks (documentation! ;-P) they consider as important.
5). If you fulfill the task and the criteria set by the board you get the money.
This is just a brainstorming like sketch.
another idea would be to buy freebeer for akademy from this moneypool.. weee
Dave,
spend money on a bug? are you serious? a bug is something that shouldn’t have been there to begin with. If KDE creates bugs, then KDE must fix them..for free. Otherwise don’t advocate users to the platform if the intention is to steal their money by providing a incomplete product then asking for money to fix it.
Features sure..users can spend money on those, but there needs to be strict guidelines, and there also has to be a reason for users to not already just use proprietary products. Yea they get the source in KDE, but what good does that do a normal user? Linux desktops seem to still have quite a bit of growing up to do..
Well since I’m not a programmer, not an artist or a writer -I’m a Windows system administrator and a Linux home user- and can’t think of a good way contribute to FLOSS in any way except reporting/voting on bugs, I’ve always wanted to give the one thing I do have that any project can use: money. I have friends and family who are programmers but wouldn’t think of contributing to some other software development besides what their fulltime day job requires without getting paid for the effort. So if KDE were to adopt a per-bug payment scheme for developers I’d be happy to contribute my money with the knowledge that the money is going towards paying developers to actually resolve bugs.
First of all I’d like to point out that I see a clear necessity to bring in money or accumulate resources if FOSS wants to change its focus from a dev-to-dev community towards average users.
Since this attitude has been the very focus recently (e.g. talking about the “market”, comparisons to commercial users, talking about usability…), I think this decision has been already made, although one should discuss it imho…
But if you try to reach “average users” and be compatitible with the commercial software market you have to find a similar source for growth like capital is for the closed source business. “Average users” cannot support with contributing their time with coding (specialized production in our society), so they’d have to contribute with money.
That is why I think we have a conflict already, although we might give a basical desktop functionality (which is good btw) but the only thing that FOSS on the desktop can do is this, no more as long as there is not enough power to support specialized apps and functionality like Microsoft or Apple do. That is why Google with its web apps will profit from the FOSS desktop by the way. They only need some basic tasks but a good browser for it, so GSoC is a political and not a benefical action imo.
Now you could focus on getting general donations in and do a KDE GSoC like thing. But in general I don’t think that GSoC is by any means more quality oriented and more hobby like than a bounty system with maintainer/mentor would be. Many students do it for the money (or where have they been before GSoC?) and leave afterwards or simply don’t have the time for their “hobby” since they want to make a career.
Then I don’t see a reason why FOSS code should be cheap labour. Personally I think that this is the only reason why especially big companies are interested in it, they get a lot of work for free and they can use it internally without having to give back their real advantages, like the Google clusters code for example.
And you get FOSS already for free, so there is few motivation to pay for it, but more to pay for future development. Maybe the bounty thing is misunderstood. I would recommend to formulate long term goals, like nepomuk integration or code quality improvements as well. Or do a good code review like OpenBSD does, so KDE is considered quite secure, etc… And for GSoC there are clear quality and transparency requirements as well.
@Jakob Petsovits
A bounty system would imo not commercialize the FOSS sector too much, since this would mean people would spend very much money on it. Also there can be a lot of competition, which would still avoid to get paid as well as you’d be in a company. That is the general tendency if you get paid by piece in a competitive “market”.
Still nothings speaks against hobby engagement in the project and FOSS is still a good thing since it is still for everybody, but even better by paying devs.
I can’t find the study. But I could find this:
http://www.fossfactory.org/index.php which is a general implementation outside of the actual project.
@Maik
One would still have the motivation to get involved in FOSS to learn how to code, since it would be at least as professional as it is now. It would be only visible that there is a long way to go from a young student/beginner to a serious long-term contributor (who then could also earn money).
The social aspect might get harmed, but since the projects are ok with paid developers already, it is an illusion anyway, especially for students, where one part is paid and others are meant to work for free…
You still do a good thing if you work on FOSS for free though.
I simply don’t think that you will be able to make a good living with it, since there are many cs students or professional developers around. But for students or to get some basic payments if you are ok with it, it would be enough imo.
@moo
KDE must nothing, it is FOSS without any warranties. Bugs are there already and they are getting fixed or many aren’t.
If you require a patch to be of certain quality (e.g. add unit tests) or only make the bounty available if the patch is tested and known to work without any severe bugs, you won’t get trash in. Infact if you write some new code and applications as a hobbyist at the moment you also try to get your features in even if they might have bugs. Every KDE point release has visible issues at the beginning and new features often have glitches. Many of my reported bugs even if they are several years old already, have not been even talked about yet.
Cheers,
whilo
@whilo
I do appreciate that this post increased the visibility of the issue and fostered its discussion. However, wasn’t it easier for everybody to leave the discussion in the KDE brainstorming forum, since I started it there? Now there are feedbacks both here and there and it is difficult to keep track of both.
@pinheiro
Is this issue discussed inside KDE, where I haven’t found it? I can post it on the mailing list, but I guess the idea is not new internally and I might get bashed. I think that especially you for example do great work and that if I as a user of yours would like to support with a few bugs (I don’t have many as a student) for the icon set which is still one of the biggest progress in KDE 4 imo, you should be able to get the money for Akadamy.
@n00bzor
Well if they get my money I should have the right to rate or comment them. If they do it for free I shouldn’t. That is what I have meant.
@Angel Blue01
Exactly this is the problem that I see. I know friends who’d like to sponsor development as well. You can buy a OpenBSD DVD for example, but that is neither very specific to the development you need, nor possible for every project.
@Alessandro Rossini
Sorry for stealing the buzz. Of course the forum should be the place for long time discussion!
I have thought about this issue for weeks though and some points have come short in your proposal imho, so I wanted to raise the awareness + position my arguments additionally on the planet.
I generally think that this issue is simply not really in the interest of many hobby (professional in real-life) devs, so it might get dropped. Sadly you haven’t got a lot of responses yet.
@David Nolden
But this means that all bugs which have only a few votes on them will get dropped regularly. I won’t spend money to get a bug fixed if the money is readjusted to bugs that are voted by others. Basically that means that I simply lose my money if my interest is not very popular. Not a good idea…
This is the advantage of a bounty system. It allows to support the “production” transparently, where a big pool of donations doesn’t and is intransparent imo.
@Socceroos
The code is not really “beautiful” now either. There are many bugs and KDE has general focus to implement features quickly even if they have known minor glitches, but fix them later. Otherwise there wouldn’t be that much feature buzz on the planet, while on planetgnome there isn’t any.
It would be very inefficient to first examine all bugs, but rather the maintainer or the bug reporter could add an estimate of the time needed to write a patch…
@whilo
> @Maik
…
> I simply don’t think that you will be able to make a good living with it,
> since there are many cs students or professional developers around. But
> for students or to get some basic payments if you are ok with it, it
> would be enough imo.
I agree. It probably will be enough money to by a new PC goody now and then, but not more.
If someone wants to help fixing bugs anyway, he/she will just be more attracted to fix those bugs which users are even willing to spend some bucks (wink wink
) on.
By the way a general aspect of a bounty system would be that developers from India or China could really make a living from it, so I don’t know how exactly this will effect the projects.
@whilo: I said the work of the developer paid by that money should be weighted by the money spent on bugs/wishes. Nothing would be lost. Nobody will try implementing a wish because one user gave 30$ anyway. If the total sum would be significant, the paid developer would developer would work on it.
The only difference to your idea is that it would not cause all the problems.
@David Nolden
Well I would not say that your proposal does not cause “all the problems.” In general changing an economic infrastructure will always cause problems. Yours for example has to ensure that all bugs you take the money from will be fixed. This also means that a few hired developers will have to work in many areas, which might be quite uneconomical.
So I wouldn’t be that optimistic, but I see no chance but to think about giving a feedback system to average users and try some concepts out if FOSS really wants to be a better way of producing software for everybody.
Maybe you could post your proposal on your blog? I’d really like to have everybody who thinks that this issue is important to join.
Cheers,
whilo
A wonderful article…. this is just what I needed to read today. Thanks for describing the way you work and how you structure your writing projects. I’ll go read that article now.
I think it is time to discuss such possibilities. However, I foresee a problem: most feature and bug donations will be directed solely to easily visible issues.
I’m not sure what the solution is, but there is defnetly a problem, example I submited talk for the Akademy and I’m still not sure I will have the money to go.