For Benefit

From P2P Foundation
Jump to navigation Jump to search

The core of peer production is obtaining benefits, rather than profits. It is a for-benefit mode of production.

This means that: In peer production, the interests of capitalists and entrepreneurs are no longer aligned!


Discussion

Excerpts from a great post by the Anomalous Presumptions, at http://jed.jive.com/?p=23

On the difference between for profit and for benefit

“Historically, entrepreneurship is associated with creating a profitable enterprise. In peer production, the idea of profit also splits into two concepts that are fairly independent, and are sometimes opposed to each other.

The classical idea of profit is monetary and is closely associated with the rate of (monetary) return on assets. This is obviously very much aligned with capitalist incentives. Entrepreneurs operating within this scenario create something valuable (typically a new business), own at least a large share of it, and profit from their return on the business as an asset.

The peer production equivalent of profit is creating a self-sustaining social entity that delivers value to participants. Typically the means are the same as those used by any classical entrepreneur: creating a product, publicizing the product, recruiting contributors, acquiring resources, generating support from larger organizations (legal, political, and sometimes financial), etc. Before widespread peer production, the entrepreneur’s and capitalist’s definitions of success were typically congruent, because growing a business required capital, and gaining access to capital required providing a competitive return. So classical profit was usually required to build a self-sustaining business entity.

The change that enables widespread peer production is that today, an entity can become self-sustaining, and even grow explosively, with very small amounts of capital. As a result it doesn’t need to trade ownership for capital, and so it doesn’t need to provide any return on investment.

There are examples where a dying business becomes a successful peer-production entity. The transformation of Netscape’s dying browser business into the successful Mozilla open source project is perhaps the clearest case. Note that while Netscape could not make enough profit from its browser to satisfy its owners, the Mozilla foundation is able to generate more than enough income to sustain its work and even fund other projects. However this income could not make Mozilla a (classically) profitable business, because wouldn’t come close to paying for all the contributions made by volunteers and other companies. “ (http://jed.jive.com/?p=23 )


Conclusions: In peer production, the interests of capitalists and entrepreneurs are no longer aligned

The author argues that “incentives of entrepreneurs (whether they work for free, get consulting fees, or go public and become billionaires) and capitalists (who want to get a return on something they own) diverge in situations that are mainly coordinated through non-monetary incentives.”

For example, Linus Torvalds is a great entrepreneur, and his management of the Linux community has been a key factor in the success of Linux. Success to an entrepreneur is coordinating social activity to create a new, self-sustaining social process. Entrepreneurship is essential to peer production, and successful entrepreneurs become “rock stars” in the peer production world. A capitalist, by contrast, wants to get a return on something they own, such as money, a domain name, a patent, or a catalog of copyrighted works. A pure capitalist wants to maximize their return while minimizing the complexity of their actual business; in a pure capitalist scenario, coordination, production and thus entrepreneurship is overhead. Ideally, as a pure capitalist you just get income on an asset without having to manage a business.

The problem for capitalists in peer production is that typically there is no way to get a return on ownership. Linus Torvalds doesn’t own the Linux source code, Jimmy Wales doesn’t own the text of Wikipedia, etc. These are not just an incidental facts, they are at the core of the social phenomenon of peer production. A capitalist may benefit indirectly, for a while, from peer production, but the whole trend of the process is against returns on ownership per se.”

Historically many benefits of entrepreneurship have been used to justify capitalism. However, we are beginning to see that in some cases we can have the benefits of a free market and entrepreneurship, while avoiding the social costs imposed by ensuring returns to property owners. The current battles over intellectual property rights are just the beginning of a much larger conflict about how to handle a broad shift from centralized, high capital production to decentralized, low capital production." (http://jed.jive.com/?p=23)


For Benefit Organizations are Community Management Organizations

David Eaves [1]:

a talk at the Free-Software and Open Source Symposium (FSOSS) on how community management is the core competency of Open Source projects.

"Companies or foundations that run open source project are not software firms, they are community management firms whose communities happen to make software. Consequently to survive and thrive these projects need to invest less in enhancing governance structures or employees who/that will improve their capacity to code. Instead, we should consider skills and structures that emphasize facilitation, mediation, and conflict management – tools, skills and structures that will enable the community to better collaborate.

More detailed thoughts I’m fleshing out an idea flow that goes something like this:


1. Open source software firms (like Mozilla, the makers of Firefox) are not software companies, they are community management firms whose community happens to produce a software package. (I’ll talk more about Canada25 as open source in the future)


2. The core competencies of a community management organization are different from those of a software firm. Specifically, core competencies reside in their capacity to support and enable the community to collaborate and contribute to the project. Furthermore, the community’s contributions will not likely be limited to a single function (such as coding new features) but will need to include all aspects of the projects evolution including discussions about the direction of the software or marketplace and its impact on strategy. As people volunteer more time and become more invested my hypothesis is that they will want (at least) input (not to be confused with decision-making authority) in more strategic decisions.


3. Consequently, the structures and skill sets of those working on an open source initiative need evolve over time:


1. In the beginning, because of their size, open source projects can pretend to be software firms – this is because the community is sufficiently small that everyone knows one another so that levels of trust are high and the need for formal community structures are low. In this earlier phase:

i. Respect and influence is based on raw brain power/problem solving capabilities – rather than seek permission those who code solutions to problems earn respect, and others listen and/or follow their lead

ii. Common values and operating assumptions in the community are not, and don’t need to be encoded – it is small enough that those who ‘get it’ opt in, and those who don’t opt out.


2. Success changes everything. As open source projects becomes increasingly successful (and, possibly, more political) the context around the community changes:

i. Success means more people join the community. This is not only true of the number of people, but also of the type of people (e.g. skill set, cultural background, etc…). This increase places stress on the community infrastructure. Specifically, an increase in participants can:

1. reduce levels of trust and the sense of community, raising transactions costs to effective collaboration

2. erode the assumed common community value as new entrants join the project for different reasons

3. decision-making becomes increasingly complex as the consultative nature of open source projects does not obviously scale. This may cause individuals/groups to feel disenfranchised and/or frustrated (and never underestimate the damage to productivity frustrated people can cause – thank you for this Shaver)

ii. As the product matures innovative leaps become harder. With the low hanging fruit plucked new features and ideas become harder to imagine and/or complex to code. The likelihood of one genius coder solving a problem is reduced. Thus at the same time that legacy governance structure (or lack thereof) makes collaboration more difficult, innovations become more difficult.


3. Community Management as Core Competency. My interest in all this is how we can take the ideas, methodologies and tools that come out of the negotiation/conflict management/collaborative decision-making arena and port them over to the open source space.

i. Training up in facilitation skills. Getting the core group of project employees trained up on how to collaboratively solve problems. Some basics might include:

1. using interests and not positions when resolving disagreements

2. using Chris Argyris’ theories about how (particularly smart technical people) fight over conclusions, by failing to share the data and analysis behind their thinking – often referred to as the ladder of inference.

ii. Rethinking decision-making processes – chiefly by setting expectations of how decisions will be made, what criteria will be applied when making them. It is likely essential to give community members a common set of criteria to use to evaluate decisions, that way they we can reframe discussion from what they like more to what adheres to the communities standards the closest. This is true for technical decisions, but also strategic or governance questions. The key around decision-making is not how democratic it is, but how well we set expectations for community members and then adhere to those expectations.

iii. Open source communities may fear accepting that even greater collaboration and openness is their core competency because it raises the underlying question no one wants to ask: Is the open source model scalable , and competitive?

The false answer is no: To believe that becoming more competitive and/or moving quickly means we need to consult less.

The true answer is yes. We can’t be competitive by running away from our core-competency, if we do that the we end up playing by the rules of the established corporate players, rules that we can’t win using. Forget their playbook, we have to get back in the box. We have to become faster, more efficient and easier to use at what we do best: engaging and enabling everyone in the community (customers, volunteers, etc…) to collaborate.


4. Leaders Matter: The good and bad news is for project leaders – for example, paid employees of the project – is that you are THE role model for the community. Every action you take validates or invalidates certain behaviour types. If a employee behaves in an unconstructive way it will be hard to tell others in the community that this behaviour is out of bounds." (http://eaves.ca/2006/12/17/community-management-as-open-sources-core-competency/)


More Information

  1. Benefit Sharing
  2. Peer Production
  3. David Eaves on Community Management in Open Source