[p2p-research] is open source design inferior

[Paul D. Fernhout]

Ryan Lanham wrote:
> On Mon, Nov 9, 2009 at 10:22 AM, Eugen Leitl <eugen at leitl.org> wrote:
> 
>> The problem is that FLOSS people and usability don't mix.
>> At least the current culture doesn't seem to, it might mend
>> eventually.
>>
>> Not holding my breath, though.
> 
> I think it was a separate thread where Michel and I were speculating on
> why.  It may be that the work of being customer driven is unappealing and
> therefore requires a market model to succeed.  FLOSS is fun for
> programmers.  Fun isn't necessarily the path to useful.  I doubt games that
> people make up would have the features wanted by gamers in the main.  I
> doubt cars designed by care enthusiasts would have cup holders.  Profit
> creates interesting incentives to be responsive.  Free has no such
> incentives.

There's certainly truth to that.

Still, free has other "incentives" in the sense of direct engagement with 
the substance of the situation.

What "incentives" does a parent have to be responsive to their child? It's 
just something most people do given the circumstances (unless something is 
really pathological).

What "incentives" does a gardener have to grow flowers in their front yard 
or windowboxes, for everyone to see? (There actually are some, but they are 
more social than directly material or ration-unit oriented.)

Another aspect is openness. People who want their individual needs met can 
either extend the system or get someone else to do it for them. So, there is 
a direct way individual needs can be met, but it is different than a simple 
fee for service in that sense.

Also, on games specifically, for a lot of people, it is more fun to make 
games than to play them. So, there are lots of ways to have fun. So, again, 
there is a paradigm shift there on that issue.

As I said before, from all the programming mailing lists I've been on, I've 
always got the feeling that open source software would be better if most 
programmers doing it did not need an eight-hour day job doing something else 
(usually programming, but sometimes other things). A lot of times the 
developers of code want to be responsive, but do not have the time.

--Paul Fernhout
http://www.pdfernhout.net/