www.nettime.org
Nettime mailing list archives

<nettime> [Fwd: Re: [ox-en] Felix Stalder: Six Limitations to the Curren
auskadi on Tue, 26 Aug 2003 09:51:12 +0200 (CEST)


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

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


I am forwarding this message  from the oekonux list
Martin

-------- Original Message --------
Subject: 	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 {AT} oekonux.de>
Reply-To: 	list-en {AT} oekonux.org
To: 	list-en {AT} oekonux.org
CC: 	Stefan Merten <smerten {AT} oekonux.de>



-----BEGIN PGP SIGNED MESSAGE-----

Hi list!

Interesting piece by Felix. Some comments. Anyone feel free to forward
this to nettime.

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.

> 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.

> But this is only part
> of the story. The other part is that the current development model is based
> on a number of specific, yet unacknowledged conditions that limit its
> applicability to more diverse contexts, say the music distribution or drug
> research.

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.

> For them the efficient solution of particular problems is of
> interest, and if that solution can be found and maintained by collaborating
> with others, the sharing of code is not an issue. For others employed in
> private sector companies, for example at IBM, the development of free
> software is the basis for selling services based on that code. The fact that
> some people can use that code without purchasing the services is more than
> off-set by being able to base the service on the collective creativity of
> the
> developer community at large. From IBM's point of view, the costs of
> participating in open software development can be regarded as 'capital
> investment' necessary for the selling of the resulting product: services.
> 
> For members of academia (faculty and students) writing code, but not selling
> (often explicitly prohibited), contributes to their professional goals, be
> it
> as part of their education, be it as part of their professional
> reputation-building. For them, sharing of code is not only part of their
> professional advancement, but an integral part of the professional culture
> that sustains them also economically,. in form of salaries for the faculty
> and stipends for the (graduate) students.

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).

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.

> Last but not least are all those who use their professional skills outside
> the
> professional setting, for example at home on evenings and weekends. Having
> already secured their financial stability, they can now pursue other
> interests using the same skill set.

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.

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.

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.

> 2) Limited capital investment
> 
> Particularly the last, and very important group of people, whose who work
> outside the institutional framework on projects based on their own
> idiosyncratic interests, can only exist due to the fact that the means of
> production are extraordinarily inexpensive and accessible.

This is indeed a valid point. We are just discussing it on the English
list right now
[http://www.oekonux.org/list-en/archive/threads.html#01142].

> 3) High number of potential contributors
> 
> Programming knowledge is becoming relatively common knowledge, no longer
> restricted to an engineering elite, but widely distributed throughout
> society. Of course, truly great programmers are rare as truly great artists
> are, but average professional knowledge is widely available. This has a
> quantitative and a qualitative dimensions. Quantitatively, the number of
> able
> programmers is in the millions, and rising. Qualitatively, the range of
> people capable programmers is also unusually wide, not the least because the
> material hurdles are so low and the learning can take place outside of
> institutions with entry exams and tuition fees. This large and diversified
> pool of talents makes it possible to create the critical mass of
> contributors
> out of only a fraction of population.

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.

So in practice I can't see where there is really a limitation here.

> 4) Modularized Production
> 
> A large software program consists of many smaller code segments (libraries,
> plug-ins etc.)This makes it possible to break down the production process
> into many small steps which can be carried out by distributed contributors.
> If the act of integration is relatively straight forward, it allows to keep
> the amount of work that each has to contribute highly flexible and also make
> use of smaller contributions (bug reports, patches). Furthermore, the
> modularity of the production process allows a high number of people to work
> in  parallel without creating significant interferences.

Hmm... The very point of Fordism is exactly that: modularization.
Indeed I think in many areas far more modularization is possible from
a technical point of view.

However, today modularization is a thing which is bad if you act on a
market. If you want to evade competition - which is what every market
entity wants - you have a strong tendency in having a feature which
gives you a niche. Modularization, however, kills that niche.
Similarly standards kill this niche, too, if it is your niche. That's
why capitalist firms are not very fond of standards in their own field
as they are not fond of modules which click together with modules from
others. This is the alienation of the market / money system
materializing in the features of the products.

However, if you look at the use value side of production
modularization and standards are key concepts for useful things. That
is why the Internet standard out-"competed" earlier, proprietary
communication standards. That's why it is usually easy to use Free
Software libraries - think of CPAN for a *big* example.

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.

> 5) Producers Are Users
> 
> According to Eric S. Raymond, a good open source projects starts with a
> programmer scratching his own itch and finding out in the process that there
> are many others with the same problem. Wanting to use a program is a great
> motivation of contributing to developing it. Often, it's much more efficient
> that waiting, hoping that someone will write and sell a program that will
> address one's particular need.

This is true to some degree but I think it won't explain projects like
KDE. There are numerous window managers out there which are highly
functional so for Free Software developers there is no need for a
Windows remake. Yet, KDE exists.

On the other hand I think a good engineer is fascinated by the problem
as such including that the product is usable for the user. So I think
there is at least some room for development of products which are not
used mainly by their developers.

> 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...


						Mit Freien Grüßen

						Stefan

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3in
Charset: noconv
Comment: Processed by Mailcrypt 3.5.7, an Emacs/PGP interface

iQCVAwUBP0pLjwnTZgC3zSk5AQG6ugP/dgcLyhF7iXIHmVf/TTvcNFirHwDGwruD
1hiPvvIkAvuBgL22Wl4L1ERoKRT0elqss0C+OFlfcvUdSomoQ20UQe7em8+gas01
/Rq371Ik8/EGIAcl0+PQjTXFl+ayNEoRLKKlozKbKZqs+H3HDZ1IcMWOaSQ9MrmA
li82wVqjJ9k=
=Hp8U
-----END PGP SIGNATURE-----
_______________________
http://www.oekonux.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 {AT} bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime {AT} bbs.thing.net