I planned to build something very similar this about four years back. Registered "Ransomware.com" just for the purpose (and still hang onto the domain, because one day I might come back to it). This was about the same time I started in on what is my current business, so it took a backseat.
Anyway, I think it's a solid idea--but the competition is stiff. SourceForge.net takes donations on behalf of its projects, every Open Source project has a PayPal link, Elance/rent-a-coder eats up the very specific work where only one person/company wants it, SitePoint runs "contests" sponsored by big companies. And, of course, your profit comes from taking a small cut, so you have to do a very high volume--hundreds or thousands of projects per day, if you want reasonable revenues for just a couple of employees. If it's a one-man shop, it's a solid business. By the time you take investment, or hire some additional employees, it could get ugly.
I agree with this completely. I had a similiar idea to this company a few months ago, but only for fixing bugs. I called it "Bug Bounty". I even wrote up a business plan. In the end the financials just didn't work out. I'd have to have 1000s of bug bounties being created every day to make a few million dollars a year. It's discouraging to determine that even if everyone used your product, you'd still have a pretty small company.
If anyone is interested in seeing the business plan, just shoot me an email gregpinero at gmail.com
I recall this being discussed on the FSB (Free software business) mailing list a number of years ago. It's one of those ideas that seems good, but doesn't seem to work out in practice. Maybe all it will take is the right tweak or two to make it functional?
The website looks aesthetically pleasing, and the idea is very good, if implemented right. Even if it isn't the most original idea, that's not what matters. Something worth thinking about if you already haven't:
What, exactly, is an "idea"? Will the person first creating the project decide all of the specifications? What if there is an idea with $2000 pledged to it, and I have a very similar idea (but slightly different) and am willing to pledge $3000 more, but insist that it be different. Can people defect and re-pledge to my idea? Since I'd be providing the most money, would that give me power to change the specifications? Who is in control over making decisions like this in production?
We're going to start with a fairly simple negotiation scheme between pledgers and developer, and we'll see how it works. A pledge is a commitment, so pledgers can only defect if the developer's not doing his job over time (pledgers vote on this).
As for bigger pledges having more voting power, we're considering this for commercial projects. But not for open source -- part of the attraction of open source is that it's not (too) controlled by money.
Lots of features never make it into software because the developers themselves don't need it. You could make it really easy for users to say to developers "If I can get 20 other people to pay $100/ea will you implement this feature?"
Let them create really simple polls, without much registration or anything. Pretty informal. Maybe a "stage 1" poll and then move to a payment-verified "stage 2" poll if there was a good response for the informal poll.
I think the 1000 x $5 is not realistic. Most of the time when I need something created it's for a business and I have hundreds/thousands of dollars to available. I've underwritten projects for tens of thousands of dollars and would love to share the load. I'd go for a smaller number of bigger buyers, even if it seems less interesting. Business-related software because consumers are cheap bastards.
I'm highly skeptical of design by committee software. Most open source soft is not done this way. Please form some kind of a structure on how to incorporate features and how to prioritize them and WHO decides what goes in. Popular votes might not be the best indicator...
You're dead right about design by committee -- the idea with microPledge is more like "funding by committee". Except that it's not a commmittee, it's a group of loosely-knit pledgers. They'll have their say in the project, but the design will still largely be done by the developer.
That said, very good point about some kind of way to prioritise and structure how and when features are included. We're thinking about it, and have a few ideas.
Shared interest is sufficient for a lot of projects (e.g. format converters, small plugins, bug fixes, performance improvements, support for a certain standard/protocol, driver support, port to another platform, etc.)
It wouldn't work for a full-featured 3D modeler or a video game, of course.
Briefly, for now: developers can quote, and who's chosen will be based on both the time they'll take and the amount quoted, as well as on the current pledging rate.
We're using web.py and Cheetah, but we've rolled our own database layer. web.py's small and in a fair bit of flux, but we get a lot of control this way.
Very good questions, but we've thought them through and come up with some solutions. They're solutions we think are better than anything the competition's got, but we'll see!
If 500 people are willing to pay $10 for a piece of software, a developer has two options: 1. Make it on your site for $5000 (minus your cut) and feel good about themselves; 2. Make it themselves, sell it on the web for $10, and make much more money. So much for others' incentive to produce your product.
It's a bit of a different model... on this site, a designer can see what they can make and sell for $5000. That is, "write a program, make $5000". As opposed to "write a program, make a website, figure out a way for people to find out about it, wait for money to trickle in".
Our cut for open source will be zero, and for commercial projects small. We're hoping the advantage of using microPledge will be that it's a central location people know about and will build up trust in. And also that the developer can focus on his project rather than on building a nice website with pledging functionality. (Our site's much more than just a SourceForge donate button -- but you'll have to wait and see. :-)
Seems that we are more likely to throw down a $100 at a betting table, and gambling to winning it all , than on developers pioneering the next useful technology. Just noticing for myself how high the stakes really are. ;-D
Anyway, I think it's a solid idea--but the competition is stiff. SourceForge.net takes donations on behalf of its projects, every Open Source project has a PayPal link, Elance/rent-a-coder eats up the very specific work where only one person/company wants it, SitePoint runs "contests" sponsored by big companies. And, of course, your profit comes from taking a small cut, so you have to do a very high volume--hundreds or thousands of projects per day, if you want reasonable revenues for just a couple of employees. If it's a one-man shop, it's a solid business. By the time you take investment, or hire some additional employees, it could get ugly.