
CodingHorror and Open Source Economics - davidw
http://journal.dedasys.com/2009/03/27/codinghorror-and-open-source-economics
======
jacoblyles
I applaud Jeff for trying to think of new ways to fund open source
development. Ultimately, I think open source will benefit from a diversity of
funding sources, including those which currently exist (day jobs, corporate
benefactors, and service sales) and those which do not yet exist (such as
Jeff's sponsorship clearinghouse). There is no reason to think that the status
quo is optimal and cannot be improved. There is certainly no reason to think
that new ideas for funding open source development ought not even be tried.

I am not sure why there seems to be a lot of vague criticism directed at
Jeff's idea, without much concrete analysis. The author of this article
mentions that Jeff's proposal "more or less works here and there" but at a
larger scale there are "too many factors" for it to work. How the heck are you
supposed to argue with something that vague?

The author just _knows_ that Jeff's idea won't work, but he can't explain why.
He implies that we should just trust him because he "gets it", and Jeff
doesn't. That implication is the only supporting argument that the author
offers. It's not very convincing. He certainly doesn't convince me that Jeff's
proposal ought not even be tried.

The tone of the conversation seems to be that people find Jeff's idea
offensive in some way, rather than unworkable. I hope that Jeff is confident
enough to implement his idea despite the naysayers, if only because I think we
will all benefit if it does indeed work.

Lastly, am I the only one that finds the last paragraph dripping with
condescension? Reading it makes me feel a little dirty.

~~~
bena
There seems to be an undercurrent here and on programming.reddit that anything
Atwood says is immediately wrong. Just about every codinghorror and
blog.stackoverflow post gets on here and programming.reddit and you can count
on 100+ comments where most people are criticizing whatever Atwood said this
time without pausing to consider what he said or what point he was trying to
make.

------
Vivtek
Sorry if this comment comes off as naive; about 2002 I realized I didn't have
the necessary set of personality traits to survive as a sole proprietor in the
open-source field, so I earn my money elsewhere now (technical translation).
And so I'm only peripherally aware of the software industry, so to speak.

But here and there I keep seeing the notion of a bounty pop up, whereby people
can sponsor specific changes. These frameworks don't seem to last long,
though. And it's fairly obvious why: if I have a business need for a specific
change to the point that I can afford a bounty, then I also need a non-flaky
pledge from a developer to make the change in a timely manner and follow
through with testing and so forth.

It seems to me that we have a mismatch of scale. A small change is worth a
week of my time if I _really_ want polka dots on my music player. It's fun and
I take time from the paying work just because I get a charge out of it, and
maybe the community appreciates it. The positive charge I get from that
improves my life -- perhaps makes me happy and motivated enough to be more
efficient with the paying work.

But I can't make a living doing other people's small changes one after the
other. I don't care about their changes, only their money -- and they can't
afford a week of my time to make me care enough about it.

So what you would really need would be to find _all_ the people interested in
a given change, and they would _all_ pay for it, and in sum, it might be
worthwhile. Right? But that won't work, either -- if I want polka dots on my
music player, I might chip in ten bucks, say. If I see that it's already got
$75 x 8 x 5 = $3000 dollars pledge, I'm going to say, what? Three thousand
bucks for polka dots?

Problem two: I don't actually know it's going to take a week, do I? If it
takes two, I'm working myself into a hole. What if 300 people have already
pledged their ten bucks and I flake out because it really didn't seem that
good an idea afterwards?

And finally, problem three: how long will it take for 300 people to think they
want polka dots? The need will have passed by the time it can gain momentum.

So what? Do I work on spec and hope 300 people will pay me? That won't work --
I either give it back to the community, so there's no motivation to pay me, or
I withhold my change until paid enough, and it's not open source any more. (By
which I mean, it violates the spirit of open source -- the mood is gone, to my
mind.)

It could be that when all six billion of us are online and more of us make
more than a dollar a day, this kind of scale problem will melt away. But until
then, paradoxical as it sounds, maybe the world just isn't big enough for this
stuff.

It could also be that a magical change in technology will make it way cheaper
to make changes (some hand-wavy high-semantics AI-supported coding system --
be honest, you want to write one, too). That would also alleviate the scale
mismatch.

But until then, I think these efforts are doomed to failure. Unless somebody
proves me wrong -- but so far, I don't see it happening.

------
davidw
I posted another one too... this one has been building up in my head for a
while:

[http://journal.dedasys.com/2009/03/27/software-economics-
pub...](http://journal.dedasys.com/2009/03/27/software-economics-public-goods)

I find this stuff extremely interesting.

------
jorleif
I think one very serious problem with someone paying for features, is
determining if a certain change actually does what the person wanted. In the
commercial world the client decides that software is good enough for them by
paying for that software (that already exists). But say if I want a certain
feature from an open source project, and decide to pay for it, and someone
writes a sloppy fix which does almost that and argues I should pay them, how
is the conflict resolved? The developer has already used his time, so if I
decide not to pay, there is a good chance the implementation is included
anyway later. One would need the same kind of management as is used for custom
software projects, but that is way too heavy for small individual features.

