[p2p-research] Open Source Manufacturing

[marc fawzi]

Well, what you say is certainly true and valid when you consider community
dynamics and other factors.

My definition of "open production system" overlaps with "renewable
production system", i.e. if it's not designed to renew itself then it's not
designed to be "open"

There are of course many meaning of "open" and I think the word itself is
subjective.

That's why I believe we ought to look beyond "open" and "closed" and
consider the optimum model for sustainability and evolution, which would
have a mix of open and closed (or not so open) aspects.

It's a complex issue indeed which is why it requires a complex answer, not
black or white like closed vs open.

Marc

On Sat, Mar 21, 2009 at 9:00 AM, Michel Bauwens <michelsub2004 at gmail.com>wrote:

> Hi Marc,
>
> I can't really comment since I have not experienced it from the inside, but
> the comments I quoted are all from insiders.
>
> I think it's a complicated question though, these leaders have grown
> organically into those positions through long engagement, and simply
> plucking outsiders for replacement, ignores the community dynamics,
>
> Michel
>
>
> On Sat, Mar 21, 2009 at 10:53 PM, marc fawzi <marc.fawzi at gmail.com> wrote:
>
>> <<
>> Instead of erecting organizational barriers to control their development
>> process and their turf, the open source development model brings all its
>> artefacts in the open:
>> >>
>>
>> Well, this is NOT true of he "open source" development model for Linux
>> kernel, Firefox, the KDE, genome or any open source software project out
>> there. There is always a hierarchy that creates fixed centers of power and
>> dependency. When Google recently plucked out top leaders from the Firefox
>> development/production organization others who were deemed to be equally
>> qualified are positioned to fill in. If that was to happen constantly to the
>> major open source projects then the production organization would be truly
>> open, but it does not happen often and most open source development
>> organizations change very slowly, i.e. their hierarchy is fixed or very slow
>> changing and the organization is thus slow at renewing itself.
>>
>> At this point, I have to clarify what defines "open organization" for me:
>> an organization that is able to renew its resources (the people) on
>> continuous basis such that no fixed or long lasting centers of power or
>> dependency are allowed to be created within its production
>> process/hierarchy.
>>
>> A closed production organization, which is what most if not all open
>> source development organizations behave like, is one that is not able to
>> renew its resources on continuous basis and thus suffers from having fixed
>> or long lasting centers of power and dependency within its production
>> process/hierarchy.
>>
>> Try going to the Firefox team, presenting your credentials and replacing
>> one of the team leaders. You can't. You run against a barrier. That is not
>> an OPEN production system. An open system should allow itself to renew its
>> resources (the people that make up its production hierarchy) by allowing an
>> outside "qualified" resource (for the given position in the hierarchy) to
>> replace the existing resource for that position (at each cycle or phase in a
>> project or for each new project.) Instead, what you get is entrenched
>> centers of power and dependency that make renewal of an organization
>> impossible, which is why I am sserting that the majority if not all of the
>> so-called "open source" development organizations are CLOSED organizations
>> in essence, and only "open" on the surface.
>>
>> So that paragraph you quote Michel, while very well intentioned, has a
>> blind spot IMO when it comes to how open source development organizations
>> behave. It's very possible and likely that people at say the Linux kernel
>> development group (which falls under Linus as a production hierarchy) will
>> allow themselves to be replaced by equally qualified outsiders but that
>> needs to happen on systematic basis, without political barriers (of people
>> wanting to retain power and thus making up all sorts of excuses to refuse to
>> renew the position they occupy in the hierarchy, especially for the high up
>> positions, unless in case of Firefox and Googlethey're given financial
>> incentive to leave, i.e. the position becomes a trade-able item, so only the
>> nobel and emlightened would give up what they worked hard for)
>>
>> Again, I'm not saying I'm right. I'm just pointing out something
>> interesting and counter to the mainstream view about open source
>> development.
>>
>> Marc
>> On Fri, Mar 20, 2009 at 11:33 PM, Michel Bauwens <michelsub2004 at gmail.com
>> > wrote:
>>
>>> this may be of interest, 'open development' refers to openness in the
>>> production organization, and has been discussed within the free software
>>> community:
>>>
>>> (the material below is from http://p2pfoundation.net/Open_Development)
>>>
>>> Diomidis Spinellis <http://www.spinellis.gr/> at
>>> http://www.re-public.gr/en/?p=97
>>>
>>> "Instead of a management hierarchy dictating how and on what each
>>> developer works, volunteers find tasks that interest them and work when they
>>> find time. Instead of having the software’s source code (essentially its
>>> design) hidden as a company’s proprietary secret, the open source
>>> programmers publish their code on the internet for others to read, learn,
>>> experiment, modify, improve, and reuse. Instead of erecting organizational
>>> barriers to control their development process and their turf, the open
>>> source development model brings all its artefacts in the open: discussions
>>> between developers and users, problem reports, the historical record of
>>> changes made to the software, even results of failed tests. Under this model
>>> transparency and self-regulation nurture each other, fostering organic
>>> growth and taming complexity." (http://www.re-public.gr/en/?p=97)
>>>
>>>
>>> *Weber* suggests eight principles to capture the essence of the open
>>> source process:
>>>
>>>
>>> “Make it interesting and make sure it happens.” -- Combinations of
>>> attraction and persuasion point participants toward problems.
>>>
>>> “Scratch an itch.” -- Address an immediate problem or opportunity.
>>>
>>> “Minimize how many times you have to reinvent the wheel.” -- Freed from
>>> worry about “lock-in,” adopt others’ foundation solutions.
>>>
>>> “Solve problems through parallel work processes whenever possible.” --
>>> Traditional development process relies upon an engineering archetype, in
>>> which an authority decides the path to be followed in development. Open
>>> source process follows an evolutionary archetype, in which the community
>>> allows multiple parallel paths to generate multiple alternative solutions,
>>> from which successful solutions are later selected.
>>>
>>> “Leverage the law of large numbers.” -- Open source projects engage many
>>> bug-hunters and bug-fixers.
>>>
>>> “Document what you do.” -- The larger, dispersed community is more
>>> reliant on documentation.
>>>
>>> “Release early and release often.” -- The evolutionary model rewards
>>> frequent iterations (generations), but puts a strain on those that must
>>> select among many submitted solutions.
>>>
>>> “Talk a lot.” -- Direct communication within the community, with lots of
>>> open conflict, typifies open source processes." (
>>> http://www.dougsimpson.com/blog/archives/000363.html)
>>> [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=2>
>>> ]
>>> Characteristics
>>>
>>> *1.*
>>>
>>> Gianugo [1]<http://feather.planetapache.org/2006/03/08/should-osi-redefine-the-label-open-source/>:
>>>
>>>
>>> "I would rather see the OSI, or an entirely new entity, patronise this
>>> concept, which should be fairly easy (though not trivial) to protect as
>>> there might be some objective criteria to tell open development from plain
>>> Open Source. A first stab at what these criteria could be:
>>>
>>> 1. an Open Source license, of course;
>>>
>>> 2. a non-discriminatory access to the developer’s community;
>>>
>>> 3. a well-defined and stated process for people to get involved;
>>>
>>> 4. a neutral and self-elected governing body;
>>>
>>> 5. (more difficult, could mean having a preferential lane) a neutral
>>> party such as a foundation owning the code.
>>>
>>> The OSI (or its spinoff, or whatever) would assert whether a community
>>> deserves the status of “open development”, much like today the OSI is
>>> approving licenses. The process could be standardised by providing “open
>>> development processes” in terms of bylaws and charters which could then be
>>> just applied via find/replace much like what happens today with licenses.
>>> The specific authorization to use the “brand” should be temporary and
>>> subject to arbitration if someone complains about a community not respecting
>>> the self-inflicted rules." (
>>> http://feather.planetapache.org/2006/03/08/should-osi-redefine-the-label-open-source/)
>>>
>>>
>>>
>>> *2.*
>>>
>>> From a SAP White Paper, "three key characteristics of open source
>>> projects:
>>>
>>> Open source is said to be based on the principle of meritocracy. We have
>>> found that the principle of meritocracy is used as an umbrella term for the
>>> following three more specific principles of open source:
>>>
>>> *Egalitarian*. Everyone can contribute, because open source projects are
>>> accessible on the Internet and the project community is typically inclusive
>>> to anyone who wants to help.
>>>
>>> => *Project members need to be inclusive of whoever comes along to help
>>> rather than viewing them as a foreign element. Documenting the project with
>>> future readers in mind is a core aspect of this.*
>>>
>>> *Meritocratic*. Contributions are judged transparently and based on
>>> their merits. All decisions are discussed publicly on mailing lists and can
>>> be looked up for reference.
>>>
>>> => *Project members need to realize that important input and
>>> contributions can come from all across the organization based on
>>> perspectives that may be unfamiliar to the original developers.*
>>>
>>> *Self-organizing*. There is typically no defined process imposed from
>>> the outside so the project community itself determines how to go about its
>>> work. "
>>>
>>> => *projects need to be accommodating of their volunteers and respectful
>>> of their time.* (
>>> http://www.riehle.org/publications/2008/bringing-open-source-best-practices-into-corporations-using-a-software-forge/)
>>>
>>> [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=3>
>>> ]
>>> Typology
>>>
>>> Peter Hoddinott and Tony Bailetti [2]<http://www.osbr.ca/archive.php?issue=10&section=Ar#A2>define four possible scenario’s mixing open source code with an open or
>>> closed process of developing it:
>>>
>>> “the production of the code lacked key open source characteristics such
>>> as:
>>>
>>> • No external contributors: all code was developed in-house prior to
>>> being published on the Internet
>>>
>>> • No visibility of who developed the code and when they developed it
>>>
>>> • No mechanisms were available to the general public for
>>>
>>> (i) contributing to the production of the code prior to its release in
>>> Sourceforge.net or
>>>
>>> (ii) participating in the governance structure of the organization that
>>> produced it
>>>
>>>
>>> In short, the code was open, but the process used to produce it was
>>> closed. There was no public community behind the production of the code, and
>>> no accommodation for such a community.
>>>
>>> Our discussion then turned to the ambiguity in the usage of the word
>>> "source". Does source mean the computer code written in a recognized
>>> programming language, or the process used to produce the code, or something
>>> else? If we allow source to mean two different things:
>>>
>>> (i) the process used to produce the code, and
>>>
>>> (ii) the computer code, four cases are possible:
>>>
>>> 1. Open process and open computer code
>>>
>>> 2. Closed process and open computer code
>>>
>>> 3. Open process and closed computer code
>>>
>>> 4. Closed process and closed computer code
>>>
>>>
>>> We surmise that many use the term open source with *case 1* in mind. For
>>> example, the Eclipse code is licensed under the OSI approved Eclipse Public
>>> License (EPL). The central repository for the code base is available and the
>>> general public can, with ease, track the pedigree of the code. Release dates
>>> are known and published. The general public is encouraged to contribute to
>>> the organization itself, to define projects, and to write code. Moreover,
>>> the governance structure used to manage all the Eclipse projects is
>>> transparent.
>>>
>>> *Case 2* was outlined above, and it characterizes what our software
>>> professional called "open code" but not "open source". A fundamental
>>> contradiction seems to exist when an open source asset is developed using a
>>> process controlled by a single party. For example, the Open Office project
>>> has been criticized. for encouraging a development culture that differs
>>> radically from the open-source norm The majority of the contributors to the
>>> Open Office project work for Sun Microsystems.
>>>
>>> *Case 3* includes instances of organizations and individuals that
>>> produce a reference implementation of some standard to accelerate that
>>> standard's adoption. The code of the reference implementation is typically
>>> produced using open processes but the code itself may not be released under
>>> an open source licence. The reason is straightforward: releasing the code
>>> under an open source licence would potentially weaken the purpose and
>>> authority of the standard by facilitating the ease by which deviations of
>>> the standard may be introduced.
>>>
>>> *Case 4* includes instances which are typically referred to as
>>> proprietary or closed software. The process used to produce the code is
>>> closed, and the software is released using a non-open source licence. This
>>> case includes instances where several organizations create a consortium to
>>> produce code that only those with membership within the consortium have
>>> visibility and access to. Typically, such consortiums have a tiered
>>> membership that stipulates the members' rights with respect to the code.
>>>
>>> It can also be argued that the use of "source" does not distinguish
>>> between the three types of code, any of which could be open or closed.
>>> Source can mean:
>>>
>>> (i) the code used to implement a system or component,
>>>
>>> (ii) the interface where what we open is the application programming
>>> interface (API), or
>>>
>>> (iii) the data underlying the implementation where most any application
>>> or system creates value from the data underlying it.
>>>
>>> It can also be argued that source is not limited to computer code. One
>>> could extend the four cases described above to combine open and closed
>>> processes with hardware schematics or documentation, two examples of assets
>>> which are increasingly being considered as open.” (
>>> http://www.osbr.ca/archive.php?issue=10&section=Ar#A2)
>>>
>>>
>>>  [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=4>
>>> ]
>>> Discussion [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=5>
>>> ]
>>> The four factors of openness
>>>
>>> Peter Hoddinott and Tony Bailetti [3]<http://www.osbr.ca/archive.php?issue=10&section=Ar#A2>:
>>>
>>>
>>> “we had occasion to find ourselves struggling as we tried to make sense
>>> of instances of the word open in the context of community code. For example,
>>> we found instances where open meant that releases of the code were made
>>> available to the general public (i.e., non-members of a consortium);
>>> however, releases to the general public were delayed 12 months from the time
>>> it was available to the members of the consortium. We also found instances
>>> where what open meant depended upon the level of membership. The more
>>> expensive memberships provided these members more privileges to participate
>>> in and influence the processes, for example with veto power. In these
>>> examples, open is not equated with full access; instead, open is a matter of
>>> degree and that degree is metered out in a distinctly defined hierarchy of
>>> privilege.
>>>
>>> This seeming confusion and differences about what is open and what is
>>> source and the use of open source to refer to phenomena that fall well
>>> outside the OSD, led us to conclude that we need to better understand the
>>> characteristics of the systems in which open source assets are produced,
>>> used and distributed.
>>>
>>> We conceptualize any such system as being comprised of four components:
>>>
>>> 1. *Network*: the network of individuals and organizations that produce,
>>> use and distribute an asset
>>>
>>> 2. *Processes*; the processes, approaches, rules and understandings that
>>> lead to the production, use and distribution of an asset
>>>
>>> 3. *Governance*: the governance structure of the organization and the
>>> projects within the organization
>>>
>>> 4. *Value*: value created through collaboration and value appropriated
>>> through competition
>>>
>>> We observe that a healthy open source system is required to compete with
>>> a strong proprietary system; that is, an open source system cannot compete
>>> by virtue of the distribution license alone.
>>>
>>> *What one would generally agree upon as being an open source system
>>> could be expressed in terms of the health of its four components.* Such
>>> a definition would not be static, but would arguably be more accurate and
>>> useful in determining the true value of an open source system. For example,
>>> one could speak in terms of a system not having reached the status of being
>>> open source until it is deemed to be healthy. And an open source system may
>>> subsequently cease to be an open source system if its health deteriorates
>>> beyond some point. This line of inquiry could then further leverage health
>>> of the four components as a means for distinguishing other types of systems
>>> such as closed systems and community systems.
>>>
>>> Our initial suggestion as to what is relevant for assessing the health of
>>> each of the four components of a system is as follows:
>>>
>>> 1. *Network*: Large, distributed and diverse: We distinguish between an
>>> asset produced by a well developed network from an asset produced by a small
>>> number of collocated producers who have similar characteristics. A general
>>> reference model for an open source asset would be one that is produced by a
>>> well developed network that is able to integrate, test, and quality assure
>>> contributions from a large number of diverse individuals and organizations
>>> dispersed throughout the world
>>>
>>> 2. *Process*: Includes meritocracy where one is recognized for the
>>> quality of their contributions; transparency in communications and
>>> guidelines; recruitment and promotion methods; and mechanisms for dealing
>>> with difficult people
>>>
>>> 3. *Governance*: Includes participation; relationship between
>>> contribution and the influence that can be asserted; membership's influence
>>> over a project, influence over the overall system governance, and ability to
>>> alter the governance structure
>>>
>>> 4. *Value creation and appropriation*: Usefulness of the asset; how
>>> free-riders are addressed--if it is too easy to appropriate value no one
>>> would pay for a membership or undergo an apprenticeship to move from being a
>>> developer/contributor who writes code or documentation to a committer with
>>> write access to the codebase; access to the asset by virtue of the license.”
>>> (http://www.osbr.ca/archive.php?issue=10&section=Ar#A2)
>>>
>>>
>>> See also: Openness in Open Source Software Development<http://p2pfoundation.net/Openness_in_Open_Source_Software_Development>
>>> [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=6>
>>> ]
>>> The Role of Community in Development
>>>
>>> *1.*
>>>
>>> Nelson Ko [4] <http://www.osbr.ca/archive.php?issue=10&section=Ar#A6>:
>>>
>>> "Understanding the nature of the community that produces the open source
>>> software is a critical part of evaluation that is often overlooked by users
>>> who are new to open source software. Unlike closed source alternatives, key
>>> support options for open source software include non-commercial channels
>>> provided by an extended community. Therefore, important criteria that should
>>> be considered when evaluating open source software include the size and
>>> vibrancy of the community, the availability of online documentation, and
>>> access to support via mailing lists, forums, and IRC (Internet Relay Chat).
>>> One source for such information is statistics on sites such as SourceForge
>>> and Ohloh. However, both sites focus on the contribution of developers and
>>> it is important to note that contribution to an open source community is
>>> more than just commits to the codebase. As in commercial software,
>>> production of good open source software also requires documentation,
>>> testing, support, training, and the incorporation of user feedback. An
>>> understanding of the maturity of the community can help to answer questions
>>> such as "what support mechanisms are available if we roll out this
>>> software?" and "how difficult will it be to install and use this
>>> software?"An evaluation of an open source community should also consider the
>>> broader ecosystem in which it exists. An environment in which open source is
>>> prevalent results in consumer choice that is arguably unparalleled in closed
>>> source ecosystems. Open source software has a clear advantage in some
>>> domains, for example, in the area of wikis. Freely downloadable open source
>>> solutions are plentiful and comparable in terms of quality to their
>>> expensive, closed source counterparts.
>>>
>>> A deeper understanding of the nature of the community is also critical in
>>> determining the nature of support that will be available for an open source
>>> software. It is important to consider the nature of the resources the
>>> community has to offer in relation to the capabilities of your organization.
>>> For example, the Tikiwiki and Drupal communities have a large number of
>>> highly technical members who can provide support at a high level of
>>> technical sophistication. On the other hand, another popular content
>>> management system Joomla, has a relatively smaller team of technical experts
>>> combined with a larger community of less technical but more design oriented
>>> individuals such as graphic designers and web designers. Largely as a result
>>> of this structure, the Joomla support forums tend to become somewhat
>>> overwhelmed with questions of a "how-to" nature. Discussions over more
>>> complex technical issues are therefore less prominent. On the other hand, it
>>> is much easier to find consultants that are able to make low cost design
>>> customizations for Joomla than it is for Drupal or Tikiwiki. Another benefit
>>> of open source software like Joomla that is exposed to a wider swath of
>>> mainstream users is that they tend to be more user-friendly, although this
>>> usually comes at a price of reduced functionality." (
>>> http://www.osbr.ca/archive.php?issue=10&section=Ar#A6)
>>>
>>>
>>> 2.
>>>
>>> " at the end of the day, the most crucial issue is the development
>>> community. It is the strength and the diversity of the development community
>>> which is the best indicator for the health and the well-being of an Open
>>> Source project.
>>>
>>> But what about end-users, I hear people cry? End users are important, to
>>> the extent that they provide ego-strokes to the developers, and to the
>>> extent that they provide testing and bug reports to the developers, and to
>>> the extent that they provide an economic justification to companies who
>>> employ open source developers to continue to do so. But ultimately, the
>>> effects of end-users on an open source project is only in a very indirect
>>> way.
>>>
>>> Moreover, if you ask commercial end users what they value about Open
>>> Source, a survey by Computer Economics indicated that the number one reason
>>> why customers valued open source was “reduced dependence on software
>>> vendors”, which end users valued 2 to 1 over “lower total cost of
>>> ownership”. What’s important to commercial end users is that they be able to
>>> avoid the effects of vendor lock-in, which implies that if all of the
>>> developers are employed by one vendor, it doesn’t provide the value the end
>>> users were looking for.
>>>
>>> *This is why whether a project’s developers are dominated by employees
>>> from a single company is so important.* The license under which the code
>>> is released is merely just the outward trappings of an open source project.
>>> What’s really critical is the extent to which the development costs are
>>> shared across a vast global community of developers who have many different
>>> means of support. This saves costs to the companies who are using a product
>>> being developed in such a fashion; it gives choice to customers about
>>> whether they can get their support from company A or company B; programmers
>>> who don’t like the way things are going at one company have an easier time
>>> changing jobs while still working on the same project; it’s a win-win-win
>>> scenario.
>>>
>>> In contrast, if a project decides to release its code under an open
>>> source license, but nearly all the developers remain employed by a single
>>> company, it doesn’t really change the dynamic compared to when the project
>>> was previously under a closed-source license. It is a necessary but not
>>> sufficient step towards attracting outside contributors, and eventually
>>> migrating towards having a true open source development community. But if
>>> those further steps are not taken, the hopes that users will think that some
>>> project is “cool” because it is under an open-source license will ultimately
>>> be in vain. The “Generation Y”/Millennial Generation in particular are very
>>> sensitive indeed to Astroturfing-style marketing tactics." (
>>> http://thunk.org/tytso/blog/2008/04/26/organic-vs-non-organic-open-source-revisited/)
>>>
>>> [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=7>
>>> ]
>>> Six Limitations of the current model
>>>
>>> Felix Stadtler [5]<http://amsterdam.nettime.org/Lists-Archives/nettime-l-0308/msg00043.html>:
>>>
>>>
>>> "Six Limitations to the Current Open Source Development Methodology
>>>
>>> The "Open Source Approach" to develop informational goods has been
>>> spectacularly successful, particularly in the area for which it was
>>> developed, software. Also beyond software, there are important, successfull
>>> Open Source projects such as the free Encyclopedia, Wikipedia; collaborative
>>> sites writing/publishing projects such as koro5hin.org; and the
>>> Distributed Proofreading Project, attached to the Gutenberg Project.
>>>
>>> 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. 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.
>>>
>>> The boundaries to the open production model as it has been established in
>>> the last decade are set by six conditions characterizing virtually all of
>>> the success stories of what Benkler called "commons-based peer production."
>>> The following list is a conceptual abstraction, a kind of ideal-type. The
>>> actual configuration and relative importance of each condition varies from
>>> project to project, but taken together they indicate the boundaries of the
>>> current model. In this elaboration, I draw from examples of free and open
>>> source software, but it would be simple to illustrate these limitation based
>>> on open content projects.
>>>
>>>
>>> *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. 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.
>>>
>>> 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.
>>>
>>>
>>> *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. Materially, all
>>> that is needed is a standard computer (often even a substandard one would
>>> already suffice) and a fast, reliable connection to the communication forums
>>> of the community. Of course, the computer and the network rely on a level of
>>> infrastructure that cannot be taken for granted in large parts of the world,
>>> but for most people in the centers of development, they are within
>>> relatively easy reach.
>>>
>>> Once this access to be means of communication is secured, the skills
>>> necessary to participate in the development of code can also be acquired
>>> collaboratively, free of charge. The number of self-taught programmers is
>>> significant. Since no expensive diplomas are necessary to become active, the
>>> financial hurdle is, indeed, extraordinarily low.
>>>
>>>
>>> *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.
>>>
>>>
>>> *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.
>>>
>>>
>>> *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.
>>>
>>>
>>> *6) No Liability*
>>>
>>> Last, but not least, software has no product liability. Paragraph 11 of
>>> the GPL states, similar to most other licenses, that "the copyright holders
>>> and/or other parties provide the program 'as is' without warranty of any
>>> kind, either expressed or implied, including, but not limited to, the
>>> implied warranties of merchantability and fitness for a particular purpose"
>>> (GPL, v2). The absence of liability makes it possible to produce a program
>>> without having to assign clear ownership, or other markers allowing to
>>> determine liability, to it.
>>>
>>> The space delimited by these condition is large and still not fully
>>> explored. We can expect that the current open production model will find
>>> additional niches in which it can thrive. Few could have predicted the
>>> success of Wikipedia only three years ago, even though Open Source Software
>>> had already been very successful at the time. However, it is also clear that
>>> many information goods fall outside of this space. Not always are the means
>>> of production inexpensive and readily available or the production process
>>> modular. Sometimes, the number of potential producers is small, more often
>>> than not are the producers not the users of their own products, and, in many
>>> cases, product liability is desirable.
>>>
>>> This does not mean that the "open source model" cannot apply to, say, the
>>> production of literary works, music, or medical drugs. What it means,
>>> however, is that to make it viable, another round of social innovation is
>>> required. This is slowly happening. The growth of "Open Access Journals" or
>>> discussions around "compulsory licensing" are good, though very early
>>> examples." (
>>> http://amsterdam.nettime.org/Lists-Archives/nettime-l-0308/msg00043.html)
>>>
>>>
>>>
>>>  [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=8>
>>> ]
>>> Does its model survive corporate cooptation
>>>
>>> Excerpts taken from an article by Doc Searls in Linux Journal, April
>>> 2008, at
>>> http://www.linuxjournal.com/content/linux-now-slave-corporate-masters
>>>
>>> To what degree does the fact that free software programmers now get paid,
>>> change the internal dynamics of peer production? The following debate, taken
>>> from Linux Journal, effectively answers that question,while at the same time
>>> confirming the huge commercialization that has been going on.
>>>
>>> On April 30, the Linux Journal<http://www.linuxjournal.com/content/linux-now-slave-corporate-masters>asked an important question: Is Linux now a slave to corporate masters? Does
>>> it matter who pays the salaries of Linux kernel developers? If so, how much,
>>> and in what ways?.
>>>
>>> This question was prompted by a report from the Linux Foundation<http://www.linux-foundation.org/publications/linuxkerneldevelopment.php>,
>>> on the characteristics of those working on the Linux kernel.
>>>
>>> Tom Slee<http://whimsley.typepad.com/whimsley/2008/04/linux-grows-up.html>has summarized the findings:
>>>
>>> “One of the highlights: “over 70% of all kernel development is
>>> demonstrably done by developers who are being paid for their work”. 14% is
>>> contributed by developers who are known to be unpaid and independent, and
>>> 13% by people who may or may not be paid (unknown), so the amount done by
>>> paid workers may be as high as 85%. The Linux kernel, then, is largely the
>>> product of professionals, not volunteers.
>>>
>>> So Linux has become an economic joint venture of a set of companies, in
>>> the same way that Visa is an economic joint venture of a set of financial
>>> institutions. As the Linux Foundation report makes clear, the companies are
>>> participating for a diverse set of commercial reasons. Some want to make
>>> sure that Linux runs on their hardward. Others want to make sure that the
>>> basis of their distribution business is solid. And so on, and none of these
>>> companies could achieve their goals independently. In the same way, Visa
>>> provides services in many different locations around the world in different
>>> sizes and types of stores. Some banks need their service mainly in one
>>> country, some in another, but when they work together they all get to
>>> provide their services all around the world.
>>>
>>> …the Linux Foundation report has made clear that open source has crossed
>>> its commercial Rubicon, and there is probably no going back.” (
>>> http://whimsley.typepad.com/whimsley/2008/04/linux-grows-up.html)
>>>
>>> Nick Carr<http://www.roughtype.com/archives/2008/04/open_source_as_1.php>predictably concludes from this:
>>>
>>> “The shift in Linux kernel development from unpaid to paid labor, from
>>> volunteers to employees, suggests that the Net doesn’t necessarily weaken
>>> the hand of central management or repeal all the old truths about business
>>> organization.” (
>>> http://www.roughtype.com/archives/2008/04/open_source_as_1.php)
>>>
>>>
>>> This specific argument is addressed by Timothy Lee<http://www.technologyowl.com/i88997-c134-rss>,
>>> who is essentially saying that the corporatization of Linux has not changed
>>> its underlying organisational model:
>>>
>>> “*For starters, most of the people contributing to the kernel are
>>> professional programmers, and most professional programmers have jobs in the
>>> software industry. So it’s totally unsurprising that most kernel
>>> contributors work for software companies.* But Carr’s observation also
>>> misses the point in a deeper way. What makes the open source model unique
>>> isn’t who (if anyone) signs the contributors’ paychecks. Rather, what
>>> matters is the way open source projects are organized internally. In a
>>> traditional software project, there’s a project manager who decides what
>>> features the product will have and allocates employees to work on various
>>> features. In contrast, there’s nobody directing the overall development of
>>> the Linux kernel. Yes, Linus Torvalds and his lieutenants decide which
>>> patches will ultimately make it into the kernel, but the Red Hat, IBM, and
>>> Novell employees who work on the Linux kernel don’t take their orders from
>>> them. They work on whatever they (and their respective clients) think is
>>> most important, and Torvalds’s only authority is deciding whether the
>>> patches they submit are good enough to make it into the kernel. Carr
>>> suggests that the non-volunteer status of Linux contributors proves that the
>>> Internet “doesn’t necessarily weaken the hand of central management,” but
>>> that’s precisely what the open source development model has done. There is
>>> no “central management” for the Linux kernel, and it would probably be a
>>> less successful project if there were*.”* (
>>> http://www.technologyowl.com/i88997-c134-rss)
>>>
>>>
>>> Ed Cone<http://blogs.cioinsight.com/knowitall/content001/decoding_the_professionalization_of_linux.html>confirms:
>>>
>>> “What that kind of analysis is missing is that IBM is paying engineers to
>>> work on projects that IBM doesn’t own, or solely direct. You pay these
>>> engineers — but of all the relationships between senior management and line
>>> employees, the fact you are paying them is about the least important,
>>> institutionally. The idea that the minute you pay people to do something,
>>> you have the right to manage them and the right to completely take over that
>>> work for the benefit of the company — that’s not true. IBM is not producing
>>> that code, IBM engineers are. IBM is paying those people because it’s
>>> getting value out of them — Linux creates value for the enterprise, it
>>> lowers our cost of managing software, it increases peoples’ budgets for
>>> hardware and services — but there’s this crazy middle step where Linux is
>>> not now and cannot be owned or controlled by IBM. Linux is a brutal
>>> technical meritocracy, and there is no senior manager at IBM who can say, “I
>>> don’t care what the kernel engineers think, I want this.” They can’t put it
>>> into the product without appealing to people who don’t work for them. If
>>> they announced a strategic change in the kernel they would be laughed out of
>>> the room. They have given up the right to manage the projects they are
>>> paying for, and their competitors have immediate access to everything they
>>> do. It’s not IBM’s product.
>>>
>>> There is a kind of perverse misreading of the change here to suggest that
>>> as long there are paid programmers working on the project, it’s not
>>> developing in any way different from what’s going on inside traditional
>>> organizations. It badly misunderstands how radical it is to have IBM and
>>> Novell effectively collaborating with no contractual agreement between them,
>>> and no right to expect that their programmers’ work is going to be
>>> contributed to the kernel if people external to those organizations don’t
>>> like it. And that’s a huge change.
>>>
>>> When people read those statistics, they think, If there’s a salary, then
>>> all the other trappings of management must go along with it. Not only is
>>> that not true, it’s actually blinds you to the fact that paying someone a
>>> salary without being able to direct their work is probably the biggest
>>> challenge to managerial culture within a business that one can imagine.” (
>>> http://blogs.cioinsight.com/knowitall/content001/decoding_the_professionalization_of_linux.html)
>>>
>>>
>>>
>>> Doc Searls then concludes the article with some personal observation and
>>> especially quoting a personal testimony by Andrew Morton, confirming the
>>> indepedence of kernel programmers:
>>>
>>> “Andrew went out of his way to make clear, without irony, that the
>>> symbiosis between large vendors and the Linux kernel puts no commercial
>>> pressure on the kernel whatsoever. Each symbiote has its own
>>> responsibilities. To illustrate, he gave the case of one large company
>>> application.” (http://www.linuxjournal.com/article/8664)
>>>
>>>
>>>  [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=9>
>>> ]
>>> Example [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=10>
>>> ]
>>> The Linux Kernel Development Process<http://p2pfoundation.net/Linux_Kernel_Development_Process>
>>>
>>> Andrew Morton:
>>>
>>> "How do new features find their way into "legacy infrastructure" open
>>> source projects such as the Linux kernel? In other words, what is the
>>> requirements analysis and planning process?
>>>
>>> - First up, with a legacy project, the feature set tends to be well
>>> understood.
>>>
>>> We're implementing 30-year-old technology, so we're working to all that
>>> prior understanding of how these things should traditionally operate. This
>>> removes a lot of uncertainty from the design process.
>>>
>>> And to a large extent we're strongly guided by well-established
>>> standards: POSIX, IEEE, IETF, PCI, various hardware specs, etc. There's
>>> little room for controversy here.
>>>
>>> - Generally, new features are small (less than one person-year) and can
>>> be handled by one or two individuals. This is especially true of the kernel
>>> which, although a huge project is really an agglomeration of thousands of
>>> small projects. Linus has always been fanatical about maintaining the
>>> quality and sanity of interfaces between subsystems, and this stands us in
>>> good stead when adding new components.
>>>
>>> This agglomeration of many small subsystems fits well into the
>>> disconnected, distributed development team model which we use.
>>>
>>> If the project was a large greenfield thing, such as, say, an integrated
>>> security system for the whole of San Jose airport then open source
>>> development methodologies would, I suspect, simply come undone: the amount
>>> of up-front planning and the team and schedule coordination to deliver such
>>> a greenfield product is much higher than with "legacy infrastructure"
>>> products.
>>>
>>> The resourcing of projects in the open source "legacy infrastructure"
>>> world is interesting. We find that the assignment of engineering resources
>>> to feature work is very much self-levelling. In that if someone out there
>>> has sufficient need for a new feature, then they will put the financial and
>>> engineering resources into its development. And if nobody ends up
>>> contributing a particular feature, well, it turns out that nobody really
>>> wanted the feature anyway, so we don't want it in the kernel. The system is
>>> quite self-correcting in that regard.
>>>
>>> Of course, the same happens in conventional commercial software
>>> development: if management keeps on putting engineers onto features which
>>> nobody actually wants then they won't be in management for very long. One
>>> hopes. But in the open source world we really do spend zero time being
>>> concerned with programmer resource allocation issues -- the top-level kernel
>>> developers never sit around a table deciding which features deserve our
>>> finite engineering resources for the next financial year. Either features
>>> come at us or they do not. We just don't get involved at that level.
>>>
>>> And this works. Again, because of the nature of the product: a bundle of
>>> well-specified and relatively decoupled features. If one day we decided that
>>> we needed to undertake a massive rewrite of major subsystems which required
>>> 15 person years of effort then yes, we'd have a big management problem. But
>>> that doesn't happen with "legacy infrastructure" projects.
>>>
>>> Development processes and workflow
>>>
>>> - All work is performed via email. Preferably on public mailing lists so
>>> a record of discussions is available on the various web archives. I dislike
>>> private design discussions because it cuts people out of the loop, reduces
>>> the opportunity for others to correct mistakes and you just end up repeating
>>> yourself when the end product of the discussion comes out.
>>>
>>> - Internet messaging via the IRC system is used a little bit, but nothing
>>> serious happens there -- for a start it's unarchived so for the previously
>>> mentioned reasons I and others tend to chop IRC design discussions off and
>>> ask that they be taken to email.
>>>
>>> - We never ever use phone conferences.
>>>
>>> - The emphasis upon email is, incidentally, a great leveller for people
>>> who are not comfortable with English -- they can take as much time as they
>>> need understanding and composing communications with the rest of the team.
>>>
>>> - Contributors send their code submissions as source code patches to the
>>> relevant mailing lists for review and testing by other developers. The
>>> review process is very important. Especially to top-level maintainers such
>>> as myself. I don't understand the whole kernel and I don't have the time or
>>> expertise to go through every patch. But I very much like to see that
>>> someone I trust has given a patch a good look-over.
>>>
>>> - When a patch has passed the review process it will be merged into one
>>> of the many kernel development trees out there. The USB tree, the SCSI tree,
>>> the ia64 tree, the audio driver tree, etc. Each one of these trees has a
>>> single top-level maintainer.
>>>
>>> I run a uber-tree called the "mm kernels" which integrates the latest
>>> version of Linus's tree with all the other top-level trees (32 at the last
>>> count). On top of that I add all the patches which I've collected from
>>> various other people or have written myself -- this ranges from 200 to 700
>>> extra patches. I bundle the whole lot together and push it out for testing
>>> maybe twice a week.
>>>
>>> When we're confident that a particular set of patches has had sufficient
>>> test and review we will push that down into Linus's tree, which is the core
>>> public kernel, at kernel.org.
>>>
>>> - Vendors such as Red Hat and Suse will occasionally take a kernel.orgkernel and will add various fixes and features. They will go through a
>>> several month QA cycle and will then release the final output as their
>>> production kernel.
>>>
>>> - The preferred form of bug reports from testers is an email to the
>>> relevant mailing list. We go through a diagnosis and resolution process on
>>> the public list, hopefully resulting in a fix. This whole process follows a
>>> many-to-many model: everyone gets to see the problem resolution in progress
>>> and people can and do chip in with additional suggestions and insights.
>>>
>>> This process turns out to be quite effective.
>>>
>>> - We do have a formal web-based kernel bug reporting system, using
>>> bugzilla. But the bugzilla process is one-to-one rather than many-to-many
>>> and ends up being much less effective because of this. I screen all bugzilla
>>> entries and usually I'll bounce them directly to up email if I think the
>>> problem needs attention.
>>>
>>> The mailing lists are high volume and it does take some time to follow
>>> them. But if a company wishes their engineering staff to become as effective
>>> as possible with the open source products, reading and contributing to the
>>> development lists is an important function and engineer time should be set
>>> aside for this." (
>>> http://www.groklaw.net/article.php?story=20041122035814276)
>>>
>>>
>>>  [edit<http://p2pfoundation.net/Open_Development?title=Open_Development&action=edit&section=11>
>>> ]
>>> Citations on the role of Emergence in the Linux Development process
>>>
>>> Selected by Karim Lakhani:
>>>
>>> Rik van Riel: “It seems like Linux really isn't going anywhere in
>>> particular and seems to make progress through sheer luck”
>>>
>>> Linus (in several emails in a longer thread):
>>>
>>> “Hey, that's not a bug, that's a FEATURE![his emphasis]
>>>
>>> “Do I direct some stuff? Yes. But, quite frankly, so do many others.
>>> Alan, Al, David, even you. And a lot of companies are part of the evolution
>>> whether they realize it or not. And all the users end up being part of the
>>> ‘fitness testing’....
>>>
>>> “A strong vision and a sure hand sound good on paper. It's just that I
>>> have never met a technical person (including me) whom I would trust to know
>>> what is really the right thing to do in the long run....
>>>
>>> “Too strong a strong vision can kill you-- you'll walk right over the
>>> edge firm in the knowledge of the path in front of you...
>>>
>>> “I'd much rather have ‘brownian motion,’ where a lot of microscopic
>>> directed improvements end up pushing the system slowly in a direction that
>>> none of the individual developers really had the vision to see on their
>>> own.”
>>>
>>> (Source: Linux kernel email list [6]<http://ocw.mit.edu/NR/rdonlyres/Sloan-School-of-Management/15-352Spring-2005/308C4BBD-FFBF-45F4-87B8-92C1075F8078/0/karimlakhani_ope.pdf>)
>>>
>>>
>>>
>>> additional discussion from
>>> http://p2pfoundation.net/Open_Development_Communities
>>>
>>>
>>> Why diverse communities of developers are so important for Open
>>> Development <http://p2pfoundation.net/Open_Development> of Open Source
>>> Software <http://p2pfoundation.net/Open_Source_Software>
>>>
>>> *1.*
>>>
>>> Nelson Ko [1] <http://www.osbr.ca/archive.php?issue=10&section=Ar#A6>:
>>>
>>> "Understanding the nature of the community that produces the open source
>>> software is a critical part of evaluation that is often overlooked by users
>>> who are new to open source software. Unlike closed source alternatives, key
>>> support options for open source software include non-commercial channels
>>> provided by an extended community. Therefore, important criteria that should
>>> be considered when evaluating open source software include the size and
>>> vibrancy of the community, the availability of online documentation, and
>>> access to support via mailing lists, forums, and IRC (Internet Relay Chat).
>>> One source for such information is statistics on sites such as SourceForge
>>> and Ohloh. However, both sites focus on the contribution of developers and
>>> it is important to note that contribution to an open source community is
>>> more than just commits to the codebase. As in commercial software,
>>> production of good open source software also requires documentation,
>>> testing, support, training, and the incorporation of user feedback. An
>>> understanding of the maturity of the community can help to answer questions
>>> such as "what support mechanisms are available if we roll out this
>>> software?" and "how difficult will it be to install and use this
>>> software?"An evaluation of an open source community should also consider the
>>> broader ecosystem in which it exists. An environment in which open source is
>>> prevalent results in consumer choice that is arguably unparalleled in closed
>>> source ecosystems. Open source software has a clear advantage in some
>>> domains, for example, in the area of wikis. Freely downloadable open source
>>> solutions are plentiful and comparable in terms of quality to their
>>> expensive, closed source counterparts.
>>>
>>> A deeper understanding of the nature of the community is also critical in
>>> determining the nature of support that will be available for an open source
>>> software. It is important to consider the nature of the resources the
>>> community has to offer in relation to the capabilities of your organization.
>>> For example, the Tikiwiki and Drupal communities have a large number of
>>> highly technical members who can provide support at a high level of
>>> technical sophistication. On the other hand, another popular content
>>> management system Joomla, has a relatively smaller team of technical experts
>>> combined with a larger community of less technical but more design oriented
>>> individuals such as graphic designers and web designers. Largely as a result
>>> of this structure, the Joomla support forums tend to become somewhat
>>> overwhelmed with questions of a "how-to" nature. Discussions over more
>>> complex technical issues are therefore less prominent. On the other hand, it
>>> is much easier to find consultants that are able to make low cost design
>>> customizations for Joomla than it is for Drupal or Tikiwiki. Another benefit
>>> of open source software like Joomla that is exposed to a wider swath of
>>> mainstream users is that they tend to be more user-friendly, although this
>>> usually comes at a price of reduced functionality." (
>>> http://www.osbr.ca/archive.php?issue=10&section=Ar#A6)
>>>
>>>
>>> 2.
>>>
>>> " at the end of the day, the most crucial issue is the development
>>> community. It is the strength and the diversity of the development community
>>> which is the best indicator for the health and the well-being of an Open
>>> Source project.
>>>
>>> But what about end-users, I hear people cry? End users are important, to
>>> the extent that they provide ego-strokes to the developers, and to the
>>> extent that they provide testing and bug reports to the developers, and to
>>> the extent that they provide an economic justification to companies who
>>> employ open source developers to continue to do so. But ultimately, the
>>> effects of end-users on an open source project is only in a very indirect
>>> way.
>>>
>>> Moreover, if you ask commercial end users what they value about Open
>>> Source, a survey by Computer Economics indicated that the number one reason
>>> why customers valued open source was “reduced dependence on software
>>> vendors”, which end users valued 2 to 1 over “lower total cost of
>>> ownership”. What’s important to commercial end users is that they be able to
>>> avoid the effects of vendor lock-in, which implies that if all of the
>>> developers are employed by one vendor, it doesn’t provide the value the end
>>> users were looking for.
>>>
>>> *This is why whether a project’s developers are dominated by employees
>>> from a single company is so important.* The license under which the code
>>> is released is merely just the outward trappings of an open source project.
>>> What’s really critical is the extent to which the development costs are
>>> shared across a vast global community of developers who have many different
>>> means of support. This saves costs to the companies who are using a product
>>> being developed in such a fashion; it gives choice to customers about
>>> whether they can get their support from company A or company B; programmers
>>> who don’t like the way things are going at one company have an easier time
>>> changing jobs while still working on the same project; it’s a win-win-win
>>> scenario.
>>>
>>> In contrast, if a project decides to release its code under an open
>>> source license, but nearly all the developers remain employed by a single
>>> company, it doesn’t really change the dynamic compared to when the project
>>> was previously under a closed-source license. It is a necessary but not
>>> sufficient step towards attracting outside contributors, and eventually
>>> migrating towards having a true open source development community. But if
>>> those further steps are not taken, the hopes that users will think that some
>>> project is “cool” because it is under an open-source license will ultimately
>>> be in vain. The “Generation Y”/Millennial Generation in particular are very
>>> sensitive indeed to Astroturfing-style marketing tactics." (
>>> http://thunk.org/tytso/blog/2008/04/26/organic-vs-non-organic-open-source-revisited/)
>>>
>>>
>>>
>>> On Wed, Mar 18, 2009 at 1:45 AM, marc fawzi <marc.fawzi at gmail.com>wrote:
>>>
>>>> Dear all,
>>>>
>>>> Has anyone made the distinction between the openness of the production
>>>> organization and openness of the schemes and code to be produced by that
>>>> organization?
>>>>
>>>> The production of open source software and hardware is typically
>>>> governed by a hierarchical organization of leaders, co-leaders, and
>>>> contributors and, while there can be N different distributions or versions
>>>> of software or hardware produced by N such organizations, each production
>>>> organization is a closed system with usually one leader at the top of the
>>>> hierarchy, a few 2nd tier leaders (or co-leaders), project managers and tens
>>>> to thousands of contributors, all governed by an implicit or explicit set of
>>>> governance rules (e.g. democratic voting, leader dictates, leader decides by
>>>> consensus, etc)
>>>>
>>>> In contract, the software code or hardware scheme itself (as opposed to
>>>> the production organization) is completely open.
>>>>
>>>> So when people say "open manufacturing" or "open source software" or
>>>> "open source hardware" they only describe the process, code or scheme. They
>>>> do not describe the "production organization" which is made of people not
>>>> code or schemes and which matters more than the code or schemes.
>>>>
>>>> It's just as important IMO to open up the production organizations, by
>>>> using process hierarchies instead of structural hierarchies, as it is to
>>>> open up the software or hardware produced by those organizations.
>>>>
>>>> People forget that the reason for openness is to evolve higher
>>>> consciousness as a society (of people) and so by opening up the software and
>>>> hardware but keeping the human production systems entrenched in structural
>>>> hierarchies (as opposed to process hierarchies) we only win half of the
>>>> battle. It's far more important at this point in the evolution of the
>>>> openness movement to focus on opening up the production organizations by
>>>> abandoning structural hierarchies where the power if those at the top
>>>> increases with the increase in the size of the hierarchy giving us
>>>> bureaucrats as the final answer!
>>>>
>>>> It is important to start thinking of 'process hierarchies' which allow
>>>> orderly and constructive production systems but do not create fixed centers
>>>> of power (or dependency)
>>>>
>>>> ~~
>>>>
>>>> I will be adding this as a new section to the P2P Energy Economy under
>>>> "Open Production Organization" and add that as a pre-requisite for
>>>> Sustainable Abundance.
>>>>
>>>> Marc
>>>>
>>>>
>>>>
>>>>
>>>> 2009/3/16 Michel Bauwens <michelsub2004 at gmail.com>
>>>>
>>>>
>>>>>
>>>>> Dear Kevin, dear Vic:
>>>>>
>>>>> Kevin, thanks for mentioning our work to Vic.
>>>>>
>>>>> The specific areas where we collate information on open design and
>>>>> distributed manufacturing are:
>>>>>
>>>>> - http://p2pfoundation.net/<http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives>
>>>>> Category:Design
>>>>>
>>>>> - http://p2pfoundation.net/<http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives>
>>>>> Category:Manufacturing
>>>>>
>>>>> (well lay-outed overview article at
>>>>> http://www.masternewmedia.org/how-peer-production-and-economic-p2p-model-can-subvert-physical-production/
>>>>> )
>>>>>
>>>>>
>>>>> In the blog:
>>>>>
>>>>> - http://blog.p2pfoundation.net/category/open-design
>>>>>
>>>>> - http://blog.p2pfoundation.net/category/desktop-manufacturing
>>>>>
>>>>>
>>>>> Tags:
>>>>>
>>>>> http://del.icio.us/mbauwens/P2P-Design
>>>>>
>>>>>
>>>>> http://del.icio.us/mbauwens/P2P-Hardware
>>>>>
>>>>>
>>>>> http://del.icio.us/mbauwens/P2P-Manufacturing
>>>>>
>>>>>
>>>>> On Tue, Mar 17, 2009 at 2:20 AM, Kevin Carson <
>>>>> free.market.anticapitalist at gmail.com> wrote:
>>>>>
>>>>>> Dear Mr. Keegan:
>>>>>>
>>>>>> As a member of several mailing lists frequented by Vinay Gupta and
>>>>>> other open-source manufacturing enthusiasts, I thoroughly appreciated
>>>>>> your sympathetic treatment in the recent Guardian article.
>>>>>>
>>>>>> You might be interested, if you're not already familiar with it, in
>>>>>> Michel Bauwens' Foundation for P2P Alternatives, which does a lot of
>>>>>> work on open-source manufacturing models.  Wiki:
>>>>>> <http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives>
>>>>>> Blog: <http://blog.p2pfoundation.net/>
>>>>>>
>>>>>> You might also be interested in Open Source Ecology's "Factor E Farm"
>>>>>> demo project in the Kansas City area, which is developing an "Open
>>>>>> Village Construction Set" (including CEB Press, tractor, solar
>>>>>> steam-powered generator, sawmill, multimachine, etc.)  Most of the
>>>>>> machinery (including the multimachine itself) can be produced with the
>>>>>> multimachine, and powered either by the generator or by using the
>>>>>> tractor as prime mover.  So the entire package, once prototyped and
>>>>>> demonstrated, is virally replicable.
>>>>>> OSE Wiki: <http://openfarmtech.org/index.php?title=Main_Page>
>>>>>> Factor E Farm blog: <http://openfarmtech.org/weblog/>
>>>>>>
>>>>>> There's one statement in your article I'd qualify:
>>>>>>
>>>>>> "Open source hardware doesn't have the same power as software if only
>>>>>> because the final product, as opposed to the designs, can't be
>>>>>> replicated for no extra cost as software can."
>>>>>>
>>>>>> OS hardware may not ever quite reach the "free beer," as opposed to
>>>>>> "free speech," version of free.  But most of the cost of manufactured
>>>>>> goods, arguably, is artificial.  It results from embedded rents on
>>>>>> artificial property like trademarks (what Tom Peters gushingly calls
>>>>>> "ephemera" and "intellect," as opposed to actual cost of labor and
>>>>>> materials), and from legally mandated requirements for minimum
>>>>>> capitalization (e.g., "safety" regulations whose main effect is to
>>>>>> mandate minimum overhead costs and erect barriers to small-scale
>>>>>> production in the informal and household economy using spare capacity
>>>>>> on capital goods we already own, so that the only way to operate
>>>>>> profitably with the mandated overhead is to engage in large batch
>>>>>> production).  Eliminate all this, so that the capital equipment for
>>>>>> manufacturing is individually affordable and larger amounts of capital
>>>>>> can be microfinanced and crowdsourced, and we're a long way toward
>>>>>> making the boundary between "free speech" and "free beer" a lot more
>>>>>> permeable
>>>>>>
>>>>>> Right now most of our economy is still built around Sloanist mass
>>>>>> production, with artificially inflated capitalization and inventory,
>>>>>> and all the push distribution and planned obsolescence required to
>>>>>> keep the wheels turning and avoid idle capacity.
>>>>>>
>>>>>> Do away with the subsidies to centralization, the protections against
>>>>>> competition, and the barriers to small-scale production, and most of
>>>>>> it would be replaced with small scale production.  A good part of this
>>>>>> would be an informal and household economy of microbreweries,
>>>>>> microbakeries, microindustry using multimachines, etc.  The rest would
>>>>>> be distributed manufacturing on the Emilia-Romagna model (small-batch
>>>>>> production with general-purpose machinery, on a demand-pull basis,
>>>>>> with modular product design for ease of repair and recycling).  About
>>>>>> the only things left for centralized manufacturing would be stuff like
>>>>>> microprocessors and the few heavy internal combustion engines that
>>>>>> would still be needed in a decentralized economy, stuff that it's
>>>>>> simply physically impossible to produce on a distributed basis.
>>>>>>
>>>>>> This was the subject of a quarterly paper I did at Center for a
>>>>>> Stateless Society: <http://c4ss.org/content/78>
>>>>>>
>>>>>>
>>>>>> Best,
>>>>>> Kevin
>>>>>>
>>>>>> --
>>>>>> Kevin Carson
>>>>>> Center for a Stateless Society (C4SS): http://c4ss.org/
>>>>>> Mutualist Blog:  Free Market Anti-Capitalism
>>>>>> http://mutualist.blogspot.com
>>>>>> Studies in Mutualist Political Economy
>>>>>> http://www.mutualist.org/id47.html
>>>>>> Anarchist Organization Theory Project
>>>>>>
>>>>>> http://mutualist.blogspot.com/2005/12/studies-in-anarchist-theory-of.html
>>>>>>
>>>>>> _______________________________________________
>>>>>> p2presearch mailing list
>>>>>> p2presearch at listcultures.org
>>>>>> http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Working at http://en.wikipedia.org/wiki/Dhurakij_Pundit_University -
>>>>> http://www.dpu.ac.th/dpuic/info/Research.html -
>>>>> http://www.asianforesightinstitute.org/index.php/eng/The-AFI
>>>>>
>>>>> Volunteering at the P2P Foundation:
>>>>> http://p2pfoundation.net  - http://blog.p2pfoundation.net -
>>>>> http://p2pfoundation.ning.com
>>>>>
>>>>> Monitor updates at http://del.icio.us/mbauwens
>>>>>
>>>>> The work of the P2P Foundation is supported by SHIFTN,
>>>>> http://www.shiftn.com/
>>>>>
>>>>> _______________________________________________
>>>>> p2presearch mailing list
>>>>> p2presearch at listcultures.org
>>>>> http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Working at http://en.wikipedia.org/wiki/Dhurakij_Pundit_University -
>>> http://www.dpu.ac.th/dpuic/info/Research.html -
>>> http://www.asianforesightinstitute.org/index.php/eng/The-AFI
>>>
>>> Volunteering at the P2P Foundation:
>>> http://p2pfoundation.net  - http://blog.p2pfoundation.net -
>>> http://p2pfoundation.ning.com
>>>
>>> Monitor updates at http://del.icio.us/mbauwens
>>>
>>> The work of the P2P Foundation is supported by SHIFTN,
>>> http://www.shiftn.com/
>>>
>>
>>
>
>
> --
> Working at http://en.wikipedia.org/wiki/Dhurakij_Pundit_University -
> http://www.dpu.ac.th/dpuic/info/Research.html -
> http://www.asianforesightinstitute.org/index.php/eng/The-AFI
>
> Volunteering at the P2P Foundation:
> http://p2pfoundation.net  - http://blog.p2pfoundation.net -
> http://p2pfoundation.ning.com
>
> Monitor updates at http://del.icio.us/mbauwens
>
> The work of the P2P Foundation is supported by SHIFTN,
> http://www.shiftn.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090321/4832fb98/attachment-0001.html>