4 ms·

Let's bring in corporate practices / scrum-agile. How about a maintainer would estimate cost of implementing the feature (say $2500) and then we do a mini kicks

Let's bring in corporate practices / scrum-agile. How about a maintainer would estimate cost of implementing the feature (say $2500) and then we do a mini kickstarter and wait until 1000 people pledge $2.50 or a big user offers $2.5k disclaimer: my personal politics / ideology It's really unfair to the community (society) when corporation use FOSS in production and still claim 100% of the profit is theirs only. EDIT: getting downvoted but no comments. Can someone counter argument?

fundamental 9y ago
The difficulty with moving to realistic cost estimates for open source software is partially that people aren't willing to put up a fair wage for many bugs/features and that open source developers often don't have the flexibility to address things immediately. Consider what happens when the funding doesn't reach the desired amount? Does the fundraising stay open frustrating users without the functionality and users who have already chipped in? Does the developer lower the amount and get it taken care of? Is development sustainable when a funding goal is missed? Are donations going to be repeatedly available when discussing fine grained technical issues (a subset of the userbase is likely affected by each issue)? Even if a project obtains funding, unless you have a team of people working on the software as their job it is difficult to predict how long it will take to implement something. Non-FLOSS work/life will end up taking priority in an unpredictable fashion and that would frustrate both the donors as well as the developer who doesn't have enough available hours to address problems that users are willing to pay for. Some projects have gone the route of fixing the time issue by fixing the problem and holding the new code hostage, however that can result in a lot of frustration if funding doesn't go smoothly. The users will think "Why don't they just release the functionality, it's done already?" "Why do they even need the money if they already did it?". The developer will think "Why did I waste my time doing XYZ? Not many people see to care." All and all, users currently don't expect to regularly fund FLOSS and this makes it difficult for FLOSS to consider a by-the-feature funding method a reliable technique. (some projects may have some success, but in general funding FLOSS is a difficult unsolved problem) (per the downvotes, they seem to be used in a "I disagree" sense rather than a "this doesn't contribute to the discussion sense" IMO)
- paulus_magnus2 9y ago
  I am not claiming the "kickstarter" model is the final solution, rather an attempt at starting the discussion / process of iterating towards the correct one. If you need a guarantee for a feature / bug being handled within a timeframe you can do multiple things depending on criticality of the FOSS - develop / patch it yourself. and contribute or fork the project and maintain internally. - purchase paid support (see RedHat, SpringSource, MySQL) - have your employees contribute to the FOSS as part of their normal duties effectively building your own expertise - other Something like BountySource existing is a proof there is a need for other models to "motivate" community into putting more effort into FOSS. What I am advocating is to attempt implementing "value based pricing". Right now a lot of projects are started by someone in their "spare time" and being abandoned because there is no easy way to reward the author. Your points are valid but these are exactly of the type that should be solved by market (money). Features hold different value for different users. In the low end we just live with bugs / missing functionality and in the high end you see $200/h consulting gigs. (per downvotes: let's keep this a discussion board where we agree / disagree by words rather than like / dislike).
  - fundamental 9y ago
    I guess the major issue I have with "value based pricing" is when a project is still evolving and most people would would traditionally have a better short-term option via a non-open tool. This would drive any funding opportunities from FLOSS work which may be significantly more beneficial in a more long term view. This might be just the behavior to expect, however. Per the discussion on funding models, my favorite source for background is the research work which the (mostly dormant) snowdrift.coop project has done: https://wiki.snowdrift.coop/market-research/other-crowdfunding https://wiki.snowdrift.coop/market-research/other-crowdfundi... and https://wiki.snowdrift.coop/market-research/history/software https://wiki.snowdrift.coop/market-research/history/software give you an idea on the other funding options out there which focus on spreading the cost across the users (similar to how many users were intended to make a bounty in bountysource grow). Each one has its own pitfalls.

fundamental 9y ago

The difficulty with moving to realistic cost estimates for open source software is partially that people aren't willing to put up a fair wage for many bugs/features and that open source developers often don't have the flexibility to address things immediately. Consider what happens when the funding doesn't reach the desired amount? Does the fundraising stay open frustrating users without the functionality and users who have already chipped in? Does the developer lower the amount and get it taken care of? Is development sustainable when a funding goal is missed? Are donations going to be repeatedly available when discussing fine grained technical issues (a subset of the userbase is likely affected by each issue)? Even if a project obtains funding, unless you have a team of people working on the software as their job it is difficult to predict how long it will take to implement something. Non-FLOSS work/life will end up taking priority in an unpredictable fashion and that would frustrate both the donors as well as the developer who doesn't have enough available hours to address problems that users are willing to pay for. Some projects have gone the route of fixing the time issue by fixing the problem and holding the new code hostage, however that can result in a lot of frustration if funding doesn't go smoothly. The users will think "Why don't they just release the functionality, it's done already?" "Why do they even need the money if they already did it?". The developer will think "Why did I waste my time doing XYZ? Not many people see to care." All and all, users currently don't expect to regularly fund FLOSS and this makes it difficult for FLOSS to consider a by-the-feature funding method a reliable technique. (some projects may have some success, but in general funding FLOSS is a difficult unsolved problem) (per the downvotes, they seem to be used in a "I disagree" sense rather than a "this doesn't contribute to the discussion sense" IMO)

paulus_magnus2 9y ago
I am not claiming the "kickstarter" model is the final solution, rather an attempt at starting the discussion / process of iterating towards the correct one. If you need a guarantee for a feature / bug being handled within a timeframe you can do multiple things depending on criticality of the FOSS - develop / patch it yourself. and contribute or fork the project and maintain internally. - purchase paid support (see RedHat, SpringSource, MySQL) - have your employees contribute to the FOSS as part of their normal duties effectively building your own expertise - other Something like BountySource existing is a proof there is a need for other models to "motivate" community into putting more effort into FOSS. What I am advocating is to attempt implementing "value based pricing". Right now a lot of projects are started by someone in their "spare time" and being abandoned because there is no easy way to reward the author. Your points are valid but these are exactly of the type that should be solved by market (money). Features hold different value for different users. In the low end we just live with bugs / missing functionality and in the high end you see $200/h consulting gigs. (per downvotes: let's keep this a discussion board where we agree / disagree by words rather than like / dislike).
- fundamental 9y ago
  I guess the major issue I have with "value based pricing" is when a project is still evolving and most people would would traditionally have a better short-term option via a non-open tool. This would drive any funding opportunities from FLOSS work which may be significantly more beneficial in a more long term view. This might be just the behavior to expect, however. Per the discussion on funding models, my favorite source for background is the research work which the (mostly dormant) snowdrift.coop project has done: https://wiki.snowdrift.coop/market-research/other-crowdfunding https://wiki.snowdrift.coop/market-research/other-crowdfundi... and https://wiki.snowdrift.coop/market-research/history/software https://wiki.snowdrift.coop/market-research/history/software give you an idea on the other funding options out there which focus on spreading the cost across the users (similar to how many users were intended to make a bounty in bountysource grow). Each one has its own pitfalls.