Felix Stalder on Tue, 26 Aug 2003 21:34:35 +0200 (CEST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

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 +0200
> 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 problems 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 the 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



#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net