I thought open source was about "scratching your own itch", not "here's $20, scratch me"
Open Source is about availability of the source code, not about paying for the development or not.
However, I think it's a great idea in principle. There's been the "street performer protocol" http://en.wikipedia.org/wiki/Threshold_pledge_system#Street_... (which didn't seem to take off); and http://www.kickstarter.com (which did, but it's mostly not software).
However, it seems like a good model if it gets up to market rates (if someone could do this in an hour or two) and especially if it's something developers wouldn't do on their own.
A group of people want X (digital content), and each will pay whatever they want to for it. Fulfillment is more likely the larger the "pot" becomes, and it's an all-out competition to see who wins the pot.
Any ideas for a tweaking of this business model that makes more sense?
The biggest problem is that the amounts involved are small, and the number of projects involved is also small (this is a $400 project, and it was considered interesting enough to get front page on HN; this indicates a tiny market). At the time, SourceForge, and several other Open Source sites, were beginning to add bounty and "hire this developer" features, and I couldn't see how a third party could more effectively reach those users or those developers (because you need both sides to buy into your product in order for it to be useful). The amount a third party could charge for the intermediary service is bound to be low or developers would go elsewhere; a couple points, maybe. So, 2% of $400 is 8 bucks. It'll take 10,000 projects of that size per year to pay yourself a decent salary and cover expenses. There probably haven't been 10,000 Open Source bounties in the past decade, much less the past year.
One of the problems a product like this would solve would be the trust issue: Can the bounty contributors trust the developer to deliver quality code if paid at the start, and can the developer trust all of the bounty contributors to pay up in a timely fashion if the code is delivered first. But, there are already ways to solve that problem. ChipIn solves the latter one, and many Open Source developers are sufficiently well-known in their community that no one would doubt they would finish the job. The other problem is connecting developers with money; but SourceForge and elance and many other sites already provides mechanisms for users to give developers money, as do traditional contractor agreements.
Of course, you've specified "digital content", and I was just looking at software, which opens up the market quite a bit. There were discussions amongst the browncoats (Firefly fans) of building a system to directly fund new Firefly episodes through viewer contributions. But, I think in the end, everyone agreed that the math just didn't add up. It might for lower budget content.
Back to software, I think github and SourceForge could make a few extra bucks from this kind of idea, but I don't think there's much room for any third party to fit into that relationship, if they aren't already in the loop for some reason.
Anyway, there is http://www.cofundos.org/ and http://micropledge.com/ at least..
Seriously, not every time there's some interests shelling out money pushing for whatever agenda they have, we have to fall for it. If it's bad, it's bad. Just say it and look away.
On the other hand, I can see $400 being something tempting for bootstrapping entrepreneurs like me...
P.S. picking on a technology because it has some flaws (typeof(NaN) returns "number") is sign of someone who reads books by their covers and fails to see the benefits of an otherwise more suitable solution. You will find in many languages the NaN constant is an instance of some kind of Number type. I'm interested in knowing "the way [you've] been programming for 8 years". I'm certain we could begin tearing it to pieces as you're so fond of doing.
Please, in the future, the moment you begin contributing your FUD to a thread such as this, just say it, and look away.
https://secure.wikimedia.org/wikipedia/en/wiki/IEEE_754
Look, a big "system language" like Java also defines NaN, +inf, -inf as values of double (see Field Summary).
http://download.oracle.com/javase/6/docs/api/java/lang/Doubl...
As in
double mathError = Double.NaN;
Any other standards conformant language supports NaN for floating point numerical values. I would even argue an absence of NaN should be perceived as a language flaw.
EDIT: I realize the above might not actually be sufficiently explanatory. "Not a number" is used to specify the class of numbers that cannot be represented in floating point notation. This includes the undefined like 0 / 0 and imaginary numbers (e.g. square root of a negative value). It can also be used for missing values in a large computation.
Any operator with a NaN results in a NaN. So 1 + NaN = NaN. Most NaNs are quiet, as in they do not throw an exception and allow the operation to continue. This allows large batch computations to continue without stopping the entire process for one bad record. Instead there will be a NaN for that record and the rest of the data will be processed correctly. You can see why this might be useful when dealing with large amounts of scientific data and hopefully why the IEEE would introduce such a feature.
typeof(NaN) returns "number" is obviously a bad example, but how about this?
1 + "1" * 1 == 2 // returns true
You really wouldn't know why until you dig into the language spec. There are lots of little things here and there that trips you up on a daily basis in JS I've never really understood why anyone would use it to write large systems on the server-side. It's a language that you have to deal with pretty much everyday when you are using NodeJS, I don't see how using JS can make the people using NodeJS more productive. But maybe that's not the point.
But maybe it is, given that on it's website it openly admits that it takes inspiration from Python's Twisted and Ruby's Event Machine.
V8 is essentially single threaded. That's common knowledge, but then again, Python isn't much better either.
So let's look at it's other selling point - Event driven programming/networking. Is that something new? No. Is that something proven? Yes, as it seems to work very well for Ericsson. Are callbacks necessary in EDP? No. Are they everywhere in NodeJS? Yes. Are they easy to read and manage? Obviously No.
For argument's sake, let's say event-driven programming/networking is a very good idea that it warrants slapping on a terrible language and programming practices on it. What about the eco-system? Well, there isn't much to say, or we wouldn't be reading this thread.
I don't know man, I don't see the merit in having yet another event-driven programming platform and marrying it on a terrible programming language. It doesn't even have bindings for other languages. I don't really understand the hype, but maybe you can enlighten me because I really haven't been able to find any in depth analysis of NodeJS.
OG as in original gangsta. Funny to see it used in a programming setting
The OG rap about node.js: http://soundcloud.com/marak/marak-the-node-js-rap
