Show Navigation
Conversation
Notices
-
I like the idea. indeed, it sounds quite familiar. it's very close to something I proposed in a speech at FISL back in July 2010; I'd never heard of crowdfunding, so I called it Social Bargaigning, but an attendant told me about Kickstarter right after it :-)
this works for projects starting from scratch, but also for "feature branches" to add stuff to preexisting projects. the latter, with strong copyleft projects, avoids the potential problem of the development becoming proprietary
-
I feel a moral duty to clarify that my proposal back then fell short of what you put forth now, @zkat
I was suggesting something for funding authors of copyrightable works in general, not specifically software. the idea of publishing the development ChangeLog did not even cross my mind then, and I find that a lovely piece of enticement and accountability. goodies are good (support on the feature makes sense); early access, I'm not sure; would that be nonfree? I'm also uncertain about the notion of withdrawing funds. my proposal was built upon the notion of eventual convergence, in which total of offers would grow while the ask price could only go down, so they'd eventually meet at a fair point. while withdrawal may be fair, I feel it may be too prone to abuse. perhaps setting a timeout at the time of the offer would enable unfinished offers to be recouped, while offering further incentive for authors to complete the transaction and release (assuming the work is completed)
-
another aspect that seems relevant for software development is that validation is something that often requires user exposure. unlike works of art, that are there for enjoyment (or not), software is usually meant to perform a practical job. it's a little hard for me to picture how a release protocol could include some user validation so that the developer can't just take the payment in exchange for a very broken piece of software and disappear. OTOH, there could be buyers who won't take less than an unachievable perfection. I don't immediately see how to strike a balance of the risks, protecting honest developers and buyers, discouraging cheating, and giving users and developers the improvements that field exposure can bring. perhaps saving part of the funds for later release to the developer, as post-release bugs are filed, estimated, and prioritized by users through this fraction, and possibly additional pledges?
-
merging the improvements with the development version of the software is also something that would necessarily take place after the release.
how do other software bounty systems deal with this, and with quality of releases? there must be plenty of experience and best practices to borrow from them
Alexandre Oliva (moved to @lxo@gnusocial.jp)
All Jonkman Microblog content and data are available under the