Ask HN: Review our startup (bitloot)
bitloot.com
bitloot.com
I wrote about it here: http://www.sitepoint.com/blogs/2008/10/09/open-source-fundin...
I'm sure there are a lot of project owners from microPledge looking for a new home, but using PayPal might just lead your down the same path.
It's good to see this getting such attention here, because it's something we discussed at some length internally as a potentially really big problem, and it validates that we're spending time talking about the right things.
As soon as they catch a whiff of that, they'll shut your account down, and lock your money in for 6 months.
It's not very pleasant, to put it mildly, and if I were you I'd switch to AlertPay or some other provider ASAP. Sorry to be negative about this ... but I'm commenting so you hopefully don't have to go through what we at microPledge did. :-)
(Edit: Oh, just curious, how much did you know about microPledge before you launched? I wouldn't be surprised either way, and certainly good on you for trying ... but your descriptions of the site on Bitloot sound awfully familiar. :-)
UI crits: 1) Try browsing without javascript enabled (cough). 2) Try using the back button in any project-specific page. You have to hit it multiple times, quickly, to go back.
That is THE most annoying thing a web developer can do to a user if you ask me!
The hope would be, of course, that developers would resolve their differences with the contributors. But if they don't, developers can walk and take their code with them (shareware it, say, or take it to a third party)
This is also not very good for the developer. They have to perfect the software to please all the contributors before getting paid. How long until everyone agrees that it's ready? Where am I supposed to take it if I walk? I just wasted all this time writing code, thinking I was going to get paid and now I have to try and sell software that I didn't even come up with the idea for. At least with Rent A Coder, I don't have to please a group of random people.
Our election algorithm looks at a lot of metrics before deciding whether to pass a project. Our goal is to pass projects that have broad community consensus that they meet the project requirements. We obviously want to fail projects that have obvious stability problems, or that don't do what the proposal says. We're working hard to make it difficult to game the system, and I'd be interested in any thoughts you might have to make things more fair.
If a bunch of contributors vote 'no' and pull their money then how do I improve the project and get them onboard again if it's going to be OSS? With shareware, I can improve the product and catch them on the next release.
Contributors can only pull money if it's been more than 30 days since they made the contribution. After that 30 day holding period, they can walk. We've considered playing with that number, or letting it be variable.
Contributors don't have great incentive to let an election fail; if it does, they don't get any software (other than whatever demo the developer posted). While I'm sure there will be cranky contributors here and there, hopefully we can factor them out to some extent in our election process. At the macro level, people are going to want the project they contributed to released.
We're geared toward normal people funding the software projects. Normal people don't want to compile sourcecode; we provide developers incentives for distributing binaries. Normal people don't use wiki markup to describe what they want; we let them use a WSIWYG editor.
Normal people also use different platforms (mostly Windows and Mac). Making binaries work across platforms (12 people want Windows, 5 people want Mac, 3 only care about the source...) and giving the developer the tools to field those platforms (Is there demand for a Mac port? Is it worth my time?) is something that hasn't been solved yet by any bounty system I've seen.
However... "It's rare to see non-coders visit an OSS bounty site and create a bounty." There's a good reason for that: normal people are going to look for something that does what they want, now, not go through all the hassle of bounties and other things only to possibly see some code who knows when.
Maybe the site can be 'salvaged' by doing some creative tweaking to make it into something else that is a little bit more likely to make money? Good luck in any case!
We're trying to mitigate that where we can; for instance a pledge is a 30-day commitment (rather than a perpetual one). If nothing satisfactory is released in that time, the money can be easily withdrawn.
Regardless of what we do, there's going to be less "normal people" contributing to projects than the number of normal people actually using the stuff after it's gone through the process. Our hope here is that our search and drilldown options (and some other stuff in the works) will help the normal people find what they're looking for after it's released. We think "finding-the-right-software-for-X" is a big open problem, and we'd like to take a crack at it.
That might make for a good site. Help connect people with open source software, and consultants who can assist them with it. For values of people where people == 'small businesses'.
I don't think anybody is going to do this, Drew.
I still don't see how this site is any better than any of the 100 freelance job sites out there now.
I'm having a hard time imagining exactly who you're targeting.
How is this different than microPledge?
* My mom, who wants a free alternative to MS Word that works well on Windows and is less intimidating than OO (and more powerful than Google Docs)
* People who saw an OSS tool running on their friend's Linux and want a port to their platform
* People who run existing closed-source software that they want to add a feature to, but can't
* People like me who code, but are too busy to learn to hack Platform X just to get Feature Y
I was a long-time mp user. Unfortunately they are no longer operating. As I understand it, their model was more focused on funding (mostly closed) software in an open way. Of course, it's difficult to convince closed-source people that community funding is a good idea, and I think that was one of several challenges they faced before shutting down.
Our focus is completely different. We want to connect people with OSS. A large part of that is money (because money is a strong attractive force). We talk about it a lot, because people start listening when you tell them they're going to get paid. But there are other problems too--search (how do people find OSS projects?), developer time (I have a week--what do I work on?). These problems are far out of bounds of micropledge or other bounty or funding systems.
College kids who want a good, free game to play at a LAN party
College students pirate software. If they want a free game then who is supposed to fund the idea on your site? I don't think people want cheesy open-source games. They want quality graphics and good gameplay. You can't achieve that with a shoestring budget and without a team.
My mom, who wants a free alternative to MS Word that works well on Windows and is less intimidating than OO (and more powerful than Google Docs)
Does your mother really know that she needs someone to write an alternative to MS Word? She knows enough to seek out a developer and is willing to invest in software that no one else has used? I don't see people trusting their documents to an untested word processor and I don't think they would pledge money for it. OOo and Google Docs are good, free, alternatives.
Most open-source software projects are started as some hacker's pet project. If I'm going to get paid to write an MS Paint clone for the Mac then I'll keep it closed and sell it myself since normal people don't understand or care about OSS.
Also, once I click "Next" when browsing for projects, I see absolutely no way to go back!
Here's my suggestion: target developing knock-offs (copies of existing products). There's a long and glorious tradition of this in open source (linux, gimp, open office, samba, mySQL, etc). It works because users already know they need it, and how to use it, it's already integrated into their behaviour and their other processes and other software - and programmers have a clear specification to work from. This narrowing the kind of project you seek to fund (i.e. a niche) will help you in many ways, as any business book will recommend (even though narrowing your options seems like a limiting thing...)
But please don't use this to undermine good-guy programmers, who took the risk of working to understand a problem, design a solution and get it accepted - use your bounty powers for good, not evil. That is, use it to break monopolies that are hurting customers in small industries. If they have any sense, the monopolist will back down, and some good will be done (whether the open source product is actually used or not). Sounds like good, heroic fun!
It doesn't feel right to me, for various reasons, starting with the above.
Also it vaguely says that code must be "open source" but this is not a well-defined term. The GPL (just one example of many possible licenses for open source software) requires that GPL-licensed projects have the source code available in the preferred format, an important distinction that is not necessarily present in all open source licenses. A developer could provide an assembler dump of their code, and claim that was open source, and walk away with the payment.
Worse, of course, they could just do a slideware demo, or they could do a demo using Microsoft Word, but claiming that it was software they had written.
Also you claim to be more centered on normal users, but normal users don't know or care about open source. To them, they just want the program. Yes, open source gives them benefits too, but they don't know that, nor do they really want to know.
As a developer, I would feel hesitant about committing much time to a project - it would be huge gamble. On a normal open source project, I could get things started, get the code base maybe 80% done, and then when that last 20% needs to be done (which in reality is actually 80% of the work ;-)) others typically would be pitching in, to the point where I could even walk away and development would continue without me, ensuring my initial work was not wasted, and ensuring the project got done. But with your site, the developer risks that the "normal users" will see any rough edges and deliver a total rejection - binary thumbs down - and I won't get paid. So it forces me to do way more work, and even then, the users can still say no based on some arbitrary whim - "I like the OK button on the left, not the right, this sucks!" - that's just an example; please don't bother trying to debunk it unless you can address the more general point.
All that being said, I could be wrong! It's happened before! I'll be curious to see how it turns out.
As others have said, the site would benefit greatly from proper use of Web standards and accessibility. Perhaps these problems are due to GWT. What you have is probably good enough to test the idea, so I won't beat this into the ground.
As for the model, I think users are much more likely to fund software that they already know and use. Once software is actually released, it develops a community of users, some of whom may be willing to support it. Asking the small fraction of users with the foresight to anticipate using a program to bear the entire cost of developing it may work for a few cases (e.g. device drivers, or cloning existing software) but there are many other software projects that would have more success if they can rely on donations after they have been written and released.
A model that finds a way for developers to work on credit against donations from future users would be interesting.
I've developed a similar site in the past but never publicly released it as there was a few flaws in the system that I couldn't work around. I've since moved on but I'm wondering how you managed to get around them.
For my system you got votes based on the amount you contributed. This opened the site up to people pledging just enough to get 51% of the vote then accepting any solution even bad ones.
The other way where the creator of the bounty gets the final say also opens up to people creating popular bounties then claiming them for themselves with no acceptable solution posed.
Outside of automated solutions I suppose you could have staff review each claim manually but I decided against this idea as it just couldn't scale.
Anyhow, curious to read your solutions to these problems.
We've got some pretty good metrics that we're looking at. The obvious ones, like number of contributors, voting times, and so on. We also look at activity, and construct minimum spanning trees for various subsets of users as an automated "Someone should look at this" flag. Contribution times and rates are also something we look at.
Probably the biggest single stopgap measure is decidedly low-tech: there's a short delay (a day or so) between project release and release of funds. If any real people at all are downloading the stuff they paid for and it doesn't work, hopefully they'll shoot an e-mail off to us and we'll take a look.
One other suggestion for going forward might be to implement none software bounties as well. A large portion of my development was based on the idea of community bounties. Say Bountyville wants their park cleaned up so their kids can play they all chip into a bounty on your site. Receive proposals from companies then choose the best one to do the job. This would help you get more "normal" people involved in the site which might translate into these people discovering the software side of the site as well.
The only difference you need for those are a two stage voting process where by users vote on proposals before the action and also on the result after.
Anyhow, best of luck.
Blog | Contact © 2008 Experiment House LLC
Blog and Contact were links, but that was all that was on the screen. Your site isn't that shiny and fancy, so it has no reason to be so dependent on JS.
It's a cool idea though. I could see developing on it.
I would suggest finding a few businesses that spend a substantial amount of money every month on proprietary software. Then ask them to support the development of a free and better version by pledging a small amount each.
The supporters can see it as a form of advertising for one. Every company would love to have its name behind a piece of software that has the ability to change the game. They also get to fix a problem and reduce future expenses.
Not only that, this new software will be constantly updated by talented people who are passionated about the problem they are solving and they will not have to pay a penny more for new versions.
(Never used it, don't know much about it, just made a note of it when it first got attention.)
A few glitches I noticed:
* The video takes awhile to load, while loading there's a black rectangle. May be use an image while the flash is loading, or bootstrap your flash with a preloader a la youTube.
* The "Help" form is behind the flash video.
* Consider dimming the background when the help form is open. Also, close it when the user clicks anywhere not on the form or presses Esc. ThickBox, GreyBox, LightBox, Uservoice, etc all do that, it's something the users expect.
* As clay suggested add some real content, no one is going to contribute to a test site.
Nice to see some implementation of it.