Paid and Unpaid Work in Peer Production

Discussion

Why do companies pay Open Source Software developers?

Andrew Morton:

"Companies pay staff engineers to work on open source software products for several reasons.

- because they have a commercial interest in the quality of those products.

- so they have some leverage on the product's future feature set.

- so they have staff at hand who understand and can support the product.

- if they manufacture hardware: so the product supports that hardware well.

- Rather than directly hiring their own engineers, companies will also fund open source development by entering into contractual arrangements with other parties, mainly Linux distributors, for all of the same reasons. The main distributors of Linux are employing a large number of world-class engineers who work purely on open source products.

- Companies who contribute to open source projects place their engineers into a peer-to-peer relationship with the rest of the development team, thus gaining influence over the project and total visibility into the development and planning processes.

All these good things do not come for free. They only really come when the company (or, more specifically, individuals within that company) become recognised contributors to the project.

Companies contribute engineering resources to open source projects for two strategic reasons:

- Firstly: resource pooling. Maintaining an entire OS is expensive, but with open source you get to pool development resources with the other users of the product while retaining many of the benefits of an in-house development project.

- And the second main reason why companies contribute to open source is to avoid vendor lockin. One way to obtain your low-level software is to simply license it from another IT vendor, and the cost of this could well be similar to the cost of using and contributing to an open source equivalent. But with open source you get full access to all the technology, you get access to the products key developers and you get full rights to modify the product if you need to do so and you get good visibility into the product's roadmap. In fact, you can to some extent control that roadmap if you're prepared to put appropriate resourcing into it." (http://www.groklaw.net/article.php?story=20041122035814276)

Typology

From Stefan Merten [1]:

Paid time

"What people confuses mostly is that there are Free Software developers which are paid by their companies for their development efforts. Or to be more exact: That they work for Free Software during their paid time. However, that people do something during their paid time does not say everything about the relation of their employers to what they do - think of coffee breaks for an example.

I think there are a number of types of Free Software development during paid time which needs to be distinguished:

• Non-official work: That is when people work on Free Software on their spare time without knowledge of the management. This can be the case when you use a certain Free tool during your job and improve it as a side effect to your normal work and give the improvements back to the community. This also applies to Free tools developed during a job.

• Half-official work: There may be times when people are not working on a job project because there is no order at the moment. In these times management may give people the opportunity to work at their own projects which may be Free Software. Google even has an official 20% share of such time.

• Non-competetive work: If you work in the software sector then you know that often there are tools you use but which are not of competetive interest to your customer. For instance in a big company you may develop a Wiki engine for the Intranet but the core business of the company is in a totally different sector - such as finances for instance. In that case the management may allow that in-house development be public Free Software.

• Competitive work: This is the case when a company officially engages in a Free Software project because it has manifest interests in this project. For instance if a processor vendor engages in the Linux kernel to make it run on his processors. Then the employees not only officially work for the company in the Free Software project but also this is relevant to competition.

Only in the last case I see the danger of alienated influences from paid labor. And even then it should be distinguished whether these influences are more useful or more harmful for the community.

Non-paid time

If develop Free Software during non-paid time then it seems to be clear that this must be based on Selbstentfaltung. However, there might be cases where people during their non-paid time they do things in the interest of commercial interests - be it in their own interest or in the interest of their company." (http://en.wiki.oekonux.org/Oekonux/Research/MeasuringCommercialInfluences)