Open Source Economic Model

One may wonder why would someone invest time and money into software that is going to be given away. Profitability of the Open Source model always has been a major source of questions. In a recent study, about 38% of the programmers involve in open source were paid for collaborating in those projects (Lakhani and Wolf, 2007: 9). Who's paying those developers to build new software? Ubuntu server host thousands of gigabytes of data that all the users can access freely. All this has a cost, and someone need to pay for it.

The open source economic model can be divided in two aspects: why does company pay for developing open source software, and how corporation like Canonical, the corporation behind the Ubuntu project, intend to profits on building such a project.

First of all, to understand why a company would invest in open source development, we need to take the point of view of the client. With proprietary software, large enterprises are paying large amount of money for licenses, so they get involve in open source project for their own benefits. Software only have a marginal cost for distribution, so all the money made through the selling is profit once the development has been paid for. Large companies, exploiting thousands of workstation are paying a large share for the development of a product. And they can't influence the final product.

That's the reason that many of them, instead of paying for license, are paying developers to help improve Open Source project. The final product of Open Source project doesn't have a licensing cost, so all they have to do is to pay for the developer. Moreover, having their own developer on the project give them the opportunity to influence and control the final product through their participation, a power that they would not have through proprietary software.

Often many corporations have developers involved in a project. In those cases, we can affirm that open source development is mutually funded. Since most corporation involved aren't selling the software, but using it to improve their productivity, there is no reason not to cooperate (Moreira de Sa Coutinho, 2006).

The second reason a corporation will get involve in funding of open source projects is the derived service they intend to sell. For example, Canonical Corporation have been funding the Ubuntu project since the beginning and has yet to see profitability, but they expect to meet it soon (Shankland 2008). How? By selling support service to corporation. As Krishnamurthy put it:

"Enterprises are willing to pay for accountability. When they have a problem, they do not want to send a message to mailing list and wait for support that may or may not be of the highest quality. They have no interest in sifting through technical FAQs to find the answer. Therefore, there is money to be made in services such as support for installation, answering technical questions and training employees to use the product."(2007: 283)

Enterprises are also willing to pay for long-term agreements with distributors to ensure that their products get updated regularly. This is what Canonical Corporation is exploiting. Selling desktop software isn't an option anymore, as Mark Shuttleworth, the founder of Ubuntu and Canonical note it:

"I don't think it will possible to make a lot of money, or maybe any money, selling the desktop. We're not going to try to make money selling the desktop. We force ourselves to look to services-oriented business models. I remain confident this is the right business model for the industry. Linux is the forcing function that (means) the broader software industry will shift in business models away from licensing the bits and to services." (Cited in Shankland 2008)

So far, this has been a viable economic model that is growing and getting more and more success. Open source software is not only for hobbyist anymore and business can be build around those models.

Krishnamurthy, Sandeep. 2007. An Analysis of Open Soure Business Models. In Perspectives on Free and Open Source Software, ed. Joseph Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R. Lakhani, 267-278. Cambridge, Massachusetts: The MIT Press.

Lakhani, Karim R., and Robert G. Wolf. 2007. Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects. In Perspectives on Free and Open Source Software, ed. Joseph Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R. Lakhani, 3-21. Cambridge, Massachusetts: The MIT Press.

Moreira de Sa Coutinho, Joao. 2006. Le logiciel libre (1) Aboutissement du Capitalisme. March 4. http://www.domainepublic.org/capitalisme.html.

Shankland, Stephen. 2008. Ubuntu 8.10 due Thursday. Profits? Not so fast. Business Tech - CNET News. October 27. http://news.cnet.com/8301-1001_3-10075890-92.html.

The making of closed source software

The history of free and open source software isn't one where closes source software were liberated and became free and open. Actually, it is quite the opposite. There was a time, when there's was no distinction between hardware and software, between users and programmers that hobbyists shared freely their knowledge. No one wanted to reinvented the wheels each time they used a computer. so they collaborated and share their lines of code.

This early history of computing came to an abrupt end when Bill Gates from Micro-soft send an open letter to the Homebrew Computer Club.

AN OPEN LETTER TO HOBBYISTS

By William Henry Gates III

To me, the most critical thing in the hobby market right now is the lack of good software courses, books and software itself. Without good software and an owner who understands programming, a hobby computer is wasted. Will quality software be written for the hobby market?

Almost a year ago, Paul Allen and myself, expecting the hobby market to expand, hired Monte Davidoff and developed Altair BASIC. Though the initial work took only two months, the three of us have spent most of the last year documenting, improving and adding features to BASIC. Now we have 4K, 8K, EXTENDED, ROM and DISK BASIC. The value of the computer time we have used exceeds $40,000.

The feedback we have gotten from the hundreds of people who say they are using BASIC has all been positive. Two surprising things are apparent, however, 1) Most of these "users" never bought BASIC (less than 10% of all Altair owners have bought BASIC), and 2) The amount of royalties we have received from sales to hobbyists makes the time spent on Altair BASIC worth less than $2 an hour.

Why is this? As the majority of hobbyists must be aware, most of you steal your software. Hardware must be paid for, but software is something to share. Who cares if the people who worked on it get paid?

Is this fair? One thing you don't do by stealing software is get back at MITS for some problem you may have had. MITS doesn't make money selling software. The royalty paid to us, the manual, the tape and the overhead make it a break-even operation. One thing you do do is prevent good software from being written. Who can afford to do professional work for nothing? What hobbyist can put 3-man years into programming, finding all bugs, documenting his product and distribute for free? The fact is, no one besides us has invested a lot of money in hobby software. We have written 6800 BASIC, and are writing 8080 APL and 6800 APL, but there is very little incentive to make this software available to hobbyists. Most directly, the thing you do is theft.

What about the guys who re-sell Altair BASIC, aren't they making money on hobby software? Yes, but those who have been reported to us may lose in the end. They are the ones who give hobbyists a bad name, and should be kicked out of any club meeting they show up at.

I would appreciate letters from any one who wants to pay up, or has a suggestion or comment. Just write me at 1180 Alvarado SE, #114, Albuquerque, New Mexico, 87108. Nothing would please me more than being able to hire ten programmers and deluge the hobby market with good software.

Bill Gates

General Partner, Micro-Soft

This letter is a major schism in the discursive formation of copyright (to embrace some Foucault's notion). This letter bring a fundamental change in the discursive field where hardware and software aren't one anymore, and if you pay for the former, you have to pay for the later too. Programmers and users aren't one either. The first one is working and the later use the product, therefore he needs to pay for it. Those notion seems like self-going today, but they are made out, and the root can be trace back to this very letter, where Bill Gates accused hobbyists of stealing software.

DigiBarn Newsletters: Bill Gates' Open Letter to Hobbyists in Homebrew Club Newsletter Vol 2, Issue 1 (Feb 3, 1976). http://www.digibarn.com/collections/newsletters/homebrew/V2_01/gatesletter.html.

Foucault, Michel. 1969. L'archéologie Du Savoir. Bibliothèque des sciences humaines. Paris: Gallimard.

Gates, Bill. 1976. An Open Letter to Hobbyists. Homebrew Computer Club newsletter 2, no. 1 (February 3): 2.

Politicizing technical question

Ubuntu developers community has been describe as a community of practice before (see older post). I think this concept could also apply to the users of the discussion list I am following. They gather for enhancing their practice of Ubuntu. They use the discussion list to ask how to perform a really specific task, (lately it was about installing Ubuntu on a third drive), and everyone is trying to find a way to perform the task. Sometimes, it does look like a game: someone comes up with a problem, and then everyone is trying to get the better solution. It is the same pattern as describe in The Charms of Wikipedia (2008). That’s what makes the list so attractive to the users.

Almost every conversation on the list begins with a support question. But the support question often leads to larger discussion about open source philosophy and/or how to convince more people to join in. Not all support question that lead to open sources philosophy. Unsolved technical problems related to closed source driver, or closed source software are more subject to lead to broader discussion. Situations where corporation force open source user into closed source software give ways to heated debate on the discussion list. This restriction of liberty and choice encourage the users to consider political action, and some of the discussions did lead to concrete action.

Baker, Nicholson. 2008. The Charms of Wikipedia. The New York Review of Books 55, no. 4 (March 20).

Ethical concern

As you may have notice, the posting cadency hasn’t really improved since last time, while the handwritten scrapbook is filling. 

Even if I did participate a little on translation, the support discussion lists were better suited to get a glance at the discourse of the users and programmers. I decided to follow a French support list based in Quebec.

I informed the “administrator” of my intention to conduct a research on his list though the IRC channel associate to the list.

The discussion went like this:

me> I want to confirm, you are in charge of the discussion list, aren’t you?
admin> yes
me> I sent you an email Monday about a research project. Have you check it out? [the email was about getting permission for conducting research]
admin> I see
admin> the list don’t belong to me.
admin> The data that you could find on it is public
admin> the content is only owned by each authors
admin> so no need for my authorization – but “ be kind “ :)

As you can see, as a manager of the list, admin isn’t claiming any ownership. He’s simply using his role as a moderator as I have seen on the list. Now and then, he will only ask people to avoid crude language and that sums it.
Since I didn’t want to interrupt every user of the list for getting consent, I informed the whole list of my intention. Sadly, I never had feedback on this.

Hacker and Community, part 2/2: Defining Community

Writing about community reveals to be far more complicate than I firstly anticipated, maybe because I am trying to bit off more than what I can chew. I tried so far to enlace too many people in what I considered to be the F/OSS community. On one side, you have multiple “hackers’” community revolving around various projects, and on the other, you have users taking the most out of the system. They do share common goals: adapt the system to fit their needs. On the other hand, their practices to do so are completely different.

There is also the question of “space”. Do they share the same locus? Yes and no. Some platform and website are dedicated to development, while other are oriented for support and community chat. It is not rare to see “hacker” engaging himself on support and community forum and discussion list. After all, “hackers” are also users. On the other side, the open source nature of the various project make it easy for users to participate in various development task, e.g. doing translation. Hence the borders between those spaces are blurred by the flow of individual that goes from one to the other. Thus, “locus” can hardly be taken as criteria to delimit communities boundaries.

One of the interesting reading I made refer to Ubuntu hackers as a community of practice. Andreas Lloyd’s approach is very relevant. Here’s a big chunk of his thesis:

“In examining the Ubuntu hackers' day­to­day practices, I argue that the Ubuntu hackers’ shared use and development of the Ubuntu system constitutes a community of practice around their collaborative work and commitment to the project. By positing the Ubuntu community as a community of practice, I explore how the Ubuntu hackers are using new technical and social means to manage and share knowledge and skills on­line, and how these means of learning and sharing are reflected in the system itself. 

I argue that though the Ubuntu community offers complete access to every technical detail of the transparent system they develop, the social boundaries of this on­line community are defined through the active use and development of the system itself. Because of this, membership and participation in this community is gained through a shared history of learning the specialized knowledge and social norms this use and development requires, making the group of developers a meritocratic group joined only through dedicated collaborative work. Thus, despite the Ubuntu system solely consisting of free software, the freedom it offers can only be fully appreciated by hackers capable of developing it. For this group of hackers, the Ubuntu system is the all­encompassing means offering them the freedom to fulfil their diverse personal, social motivations for contributing to the system. By building a system that works for each of them individually, the Ubuntu hackers come to construct a system which reflects their practices. But they also seek to ensure that the Ubuntu system, as well as the community of practice through which it is built, is open to all, depending on the users’ willingness to invest the time and effort to scale the steep curve of learning necessary to adopt, learn, configure, and even build the system according to their own needs, and master the core practices and social norms required for membership. 

I argue that this shared practice and history of learning to collaboratively build and maintain the Ubuntu system results in a careful mutual trust in the hackers’ complementary abilities through which the integrity and solidity of the intricately complex Ubuntu system is guaranteed, and which the many users of the Ubuntu system come to rely on. And similarly, it is through this reciprocal trust that the diversity of motivations and conflicting interests within the community of practice is managed under the reciprocal big­man leadership and ethos of a few prominent and respected core Ubuntu developers.” (Lloyd, 2007 : 10-11)

While it covers well the hackers’ uses of Ubuntu, I feel it won’t suffice for my needs. In order to look at software as contestation tools against copyright, authorship and intellectual property, the concept of community of practice might be short of use. Some authors (Szczepanska et al., 2007) approach the community identity's question using a foucaultian analyze of discourse. They argue that discours provide understanding on how collective identity is created and communicated. 

“Developing discourses is vital for providing the members of the [open source] movement with a meaningful context that enables creative software development activities across organizational and geographical boundaries. People feel a bond with others not because they share the same interest, but because they need that bond in order to make sense of what they are doing. Discourses […] enable members of a community to affirm themselves as subjects of their action and parts of a collective action.” (Szczepanska et al., 2007: 433)

Contestation discourse might reveal lots of information on the community’s nature and the bonds that tie them. I expect contestation to be a pivotal element to define open source movement as a whole. In this sense, it might also tie together different members, users and hackers, in the same community.

References: 

• Andreas, Lloyd. 2007. A System that Works for me: an anthropological analysis of computer hacker' shared use and development of the Ubuntu Linux system. Master's thesis, University of Copenhagen. Available here.
  
• Szczepanska, Anna Maria, Magnus Bergquist, and Jan Ljungberg. 2007. High Noon at OS Corral: Duels and Shoot-Outs in Open Source Discourse. In Perspectives on Free and Open Source Software, ed. Joseph Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R. Lakhani. Cambridge, Massachusetts: The MIT Press.
  

The Anthropologist in mined fields

I think this is the "Table Ronde" Max Forte spoke of during last class. I just received the invitation, here it is for those interesed by the subject:

Altérités presents

ANTHROPOLOGISTS IN MINED FIELDS

Roundtable organized by Yara El-Ghadban and Kiven Strohm

Friday February 6, 2009 from 12h30 to 3h30 pm

Salle Marius Barbeau (C-3061), Département d’Anthropologie,

Université de Montréal

Moderator: Yara El-Ghadban, doctorante en anthropologie, Université de Montréal

INVITED SPEAKERS

Marie-Joëlle Zahar

Professeure agrégée, Science politique, Université de Montréal

Omar Dewachi

Post-doctorant en anthropologie, Université de Montréal

Abdel-Hamid Afana

President of the International Rehabilitation Council for Torture Victims (IRCT)

Research Associate, Trauma and Global Health Program, Douglas Hospital Research Institute, McGill University

Kiven Strohm, doctorant en anthropologie, Université de Montréal

Maximilian Forte

Associate Professor, Sociology and Anthropology, Concordia University

DISCUSSANTS

Mariella Pandolfi

Professeure titulaire, Anthropologie, Université de Montréal

Nadia Proulx

Doctorante en anthropologie, Université de Montréal

A buffet will be offered during the event

FREE ENTRY

(please see poster below)

SUMMARY

L’intellectuel est peut-être une sorte de contre-mémoire possédant son propre contre-discours qui défend à la conscience de porter son regard ailleurs ou de s’endormir

– Edward Said 2005

Qu’est-ce que l’intellectuel, sinon celui qui travaille à ce que les autres n’aient pas tellement bonne conscience?

– Michel Foucault 1976

In many of Saïd and Foucault’s writings, the intellectual is called upon to keep a critical perspective by staying deliberately out-of-step with current events, in essence by offering a constant counterpoint to the immediacy of the present and its short-sightedness in order to think beyond the surface of things. However, those who undertake research in areas of conflict are often confronted with situations that expose the limits of such a position. In the middle of a conflict zone, the ethnographic text and critical reflection come face to face with the dictatorship of the present, the brutality of finitude, the fragility of human life and the imperative to respond to what seems inhumane, if only to survive.

In such a context, is critical thinking even possible? Being a form of sustained but non-reactive engagement that often occurs at a distance in time and space from the conflict zone, is critical thinking compatible with the acts of engagement that take place in areas of conflict? These are but some of the questions that we wish to discuss in the context of this roundtable, which brings together a range of researchers working in areas of conflict. The discussion will focus on the role of intellectuals in conflict zones with speakers invited to talk about their experiences and their reflections on the risks, challenges and different forms of commitment that working in such conditions inevitably implies. Finally, they are invited to share with the audience the dilemmas and second-thoughts (if there are any) that have shaped their experiences.

Issues covered in this event include :

- How is academic research practiced in areas of conflict?

- What are the risks and challenges of such a practice?

- What to do, as researchers, in the face of experiences that are unspeakable?

- Where do critical thinking and acts of engagement meet and at what point do they come apart?

- What are the traces left by the researchers when they leave these places?