I'm a developer, I remember one time I needed to have a particular piece of functionality in an app. I could have built it, but I found that someone was selling what I wanted for $3.00 on the internet, it was a no-brainer. I paid with something like gumroad, downloaded and plugged it in within a matter of minutes, vs the few hours I would have spent writing/debugging.
Odd price, $3. He could have doubled his price to $6, doubled his income, and lost no sales. Anyone who would consider buying a component online would surely not blink at the difference if it saves them a half-a-day of effort.
Maybe he doesn't want to have to provide support and thinks that $3 would be the cut off point for that? Hard to say really.
I would happily sell a bunch of scripts for a few $ on an "if it works, it works" basis. Once you start thinking about saving days of dev time it makes sense to bump it up to $100+ but then you will have to deal with emails or calls.
If that was on a site like codecanyon he might had no choice for the price. The staff there have their own ideas for the prices and doesn't let sellers set their own.
That's interesting. As you say, it's a no-brainer. I wonder if some kind of micropayment market in functions could be pulled off... The kind of thing Ted Nelson or Jaron Lanier talk about, only for small pieces of reusable code rather than small pieces of reusable text.
That's true. But money in that micropayment sense might not be entirely insane (assuming the whole micropayment model isn't entirely insane to begin with). The idea (as I understand it) is that you'd get a tiny wee payment every time someone quoted your work; so why not every time someone quoted your code? In the context of some Xanadu-like system, wouldn't that make sense?
But (I think) he means as a product, not a service (i.e. for bounties, only the asker pays, so it's a service; though it's true that everyone else benefits too).
I like this idea. The big problem, as always, is the boundary or interface of the module/component. (1). The buyer has to specify it, which is usually the difficult bit and writing it is usually easy. (2). For a market, you need to find modules that many people need, that people can search for and find, and that are difficult enough to implement that people would buy rather than build.
Maybe it's possible, for things that seem one-off or too specialized to a person, if you reduced friction enough, in a SO way. They've solved the search problem.
I guess an example would be a square-root function. I wouldn't know how to code it, I'd have to look it up, test and debug. It would take at least hours, I'd think. Of course, it's such a useful one, it's already done. That's the fate of all generally useful functions. The exceptions are new ones and niche ones.
I guess you could just add a little "debugged code" box for SO, and the person keeps coming back to it, to support it. This might be a useful addition; but I think you're right that money would spoil it. However... if you imagine a spectrum from one-liner to massive library, there's probably some level where the amount of work would make it reasonable to pay.
Conclusion: to see the value in the idea, leave money out (build something people want). How would you modify SO, or start a new one, to provide this value, or reusable functions/code snippets?
Matt Cutts (Google SEO) fondly referred to this site as "Expert-SexChange" at Wordpress Conference in San Francisco in 2009! Google it. The video is funny!
But it makes me wonder when exactly we start to call something over-engineered. The same function will be implemented differently depending what you are going to feed into it i.e. if the numbers are sufficiently large then you need to worry about integer overflow etc. Probably a function definition should be considered incomplete without pre/post conditions.
One could imagine incorporating the component store into the app store, where developers could get a cut of app profits for providing components while the app store is responsible for all the bookkeeping. Think 5 cents/app sale micropayments, but that includes all apps on the store that want to use your component.
