Message 01238 [Homepage] [Navigation]
Thread: oxenT01238 Message: 1/2 L0 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

Re: <nettime> [Fwd: Re: [ox-en] Felix Stalder: Six Limitations to the Current Open Source Development Methodology]



Date: 	Mon, 25 Aug 2003 19:46:55 [PHONE NUMBER REMOVED]
From: 	Stefan Merten <smerten oekonux.de>

Last week (9 days ago) geert lovink wrote:
Six Limitations to the Current Open Source Development Methodology

I'm not always sure in which way or to what areas the following points
are limitations.

These limitations refer to the kind of problem that can be addressed through 
the current form of social organization developed in the Open Source 
Movement. The way Open Source Projects are organized reflects the specifics 
of problem -- developing software -- and thus they cannot serve as a model to 
address problem with very different characteristics. 

This does not mean that other problems, for example, the development of drugs, 
cannot be organized in an open way, but this 'open way' will have to look 
very different from the way Open Source Software projects are organized 
because the problem of creating drugs is very different from the problem of 
creating software. In other words, there is an intimate relationship between 
the characteristics of the problem and the social organization of its 
solution.


However, particularly outside the software domain, the Open Source
projects remain relatively marginal. Why? Some of it can be explained by
the relative newness of the approach. It takes time for new ideas to take
hold and to be transferred successfully from one context to another.

I'd like to underline this point. Free Software took 15-20 years to
reach the public space. If I consider that period I find it promising
that similar approaches are far more known today than Free Software
was in the late 80's.

I agree. This is why I'm very hopeful. But in order to continue the social 
innovation, we need to address these problems, rather than hoping they will 
be solved somehow by the magic of 'openness'.

Let's check this.

1) Producers are not sellers

The majority professional, i.e. highly-skilled, programmers do not draw
their
economic livelihood from directly selling the code they write. Many work
for organizations that use software but do not sell it, for example as
system administrators.

So they sell at least the kind of workforce they use when producing
Free Software.

Yes, but the difference between using and selling software is important, even 
within the commercial sector. If you're simply using the software, you don't 
care if it's available to others as well (since it is anyway). If you're 
selling it, you need to control it.


I'm not sure about the first example but for IBM workers and students
Free Software is then at least to some degree an alienated thing: They
don't program because of the program but because of the money they may
sell their services for (IBM) or the reputation they get for it
(students).

I think is too simplistic to say that all work is paid or has other 
utilitarian motives is alienated.

As a result this software is not Double Free Software as I called it
on the German list some time ago because the software is written for a
purpose outside the software and its concrete use value. I'm arguing
that this degrades the quality of the software because of the
alienation.

Any evidence for this? Would be interested in seeing it. Again, I think this 
is simplistic. Many students love what they do. The fact that they get a 
degree for it is an additional motivation, but a detraction.


Unfortunately AFAIK there is no study yet which tries to answer the
question which amount of Free Software is written under alienated
conditions and which amount is Double Free Software.

I guess one of the reasons why this hasn't happened is that it's simply 
impossible to define what alienated means within any degree of empirical 
relevance in this context. We are speaking of highly-skilled, self-motivated 
professionals, and not about people in the assembly line. The contexts are 
different and the differences matter.


However, I can't see where the limitation is here. Oekonux argues that
it is one of the basic *strengths* of Free Software that it is not
sold by those who create it. This way the creators can focus on the
use value of the software alone and are not obstructed by marketing
needs. Exactly this is one of the reasons why Free Software is so
successful.

I'm not saying that the limitations make Open Source Software bad, but that 
they limit its social model in terms of the problems to which it can be 
applied.

So I'd argue that this is not an limitation to spread the principles
of Free Software to other areas but a precondition.

Felix' argument makes sense only if you assume that each little piece
of work / effort needs to be sold. However, this is not true for
*lots* of areas in human life. One instance close to software is the
hobby sector where people spend lots of efforts including spending
money. The only "reward" they get is the Selbstentfaltung they
experience while doing their hobby.

This reminds me of a discussion I had about a year ago at a "radical" media 
conference where people said, in all honesty, that they prefer to work 8 
hours at McDonald's so that they can volunteer at a radical project than 
having their projects tainted by money.

3) High number of potential contributors

I think this is true for the very most areas of engineering. The only
thing is that in Free Software there is a practice of sharing which is
choked by employers and patents in other areas. However, personally I
have the impression that if you would let engineers of all brands do
what they wanted to similar dynamics as in software would emerge. In
some sciences this is already happening.

Of course this is even less a problem when thinking of less skilled
areas.

But this is a problem when we are talking about advanced medical research or 
about writing a novel. Writing a novel, there's usually only one author (or 
small, closely knit collectives, as wuming who authored Q).


4) Modularized Production

So I'd say this limitation is build into the way capitalist society
functions. If, however, the quality of the products is higher when
they are built from modules - and I think we have reached this point
in time - then capitalism becomes a fetter to the development of the
means of production.

Again, I'm not arguing of modularization is a good or bad thing, but that 
certain kinds of problems, for example, writing a novel, are very hard to 
modularize. I think it's not a co-incidence that Stallman distinguishes 
between funcation and non-functional works and basically excludes the latter 
from GPL type copyleft.

6) No Liability

Last, but not least, software has no product liability.

Ahm - does proprietary software has? I thought the "We are not
responsible!" comes at first from M$? I'd *love* they could be made
responsible for all the bugs, security holes, stupidity they pour over
this planet. Perhaps this would be a way to make them produce better
products...

Yes, this is typical for ALL software. But should product liability come, then 
proprietary software, which is owned by a legal subject who could be held 
liable, would have a much easier time dealing with it than open, 
decentralized open source projects that do not even have the money to fight a 
real legal battle in court. It's no suprise that it's IBM who defends the GPL 
and not the FSF. 

Again, I don't really care for the moment if we should have product liability 
or not, but as current way of organizing open collaboration is totally 
unsuited to deal any problem that has liability issues built in. And in many 
cases, product liability is a good thing, it forces the producer to be much 
more careful. But it also requires the producer to be a legal entity.



Felix


----+-------+---------+---
http://felix.openflows.org

_______________________
http://www.oekonux.org/



Thread: oxenT01238 Message: 1/2 L0 [In index]
Message 01238 [Homepage] [Navigation]