And here goes anonymity...

Taken from: Raymond, Eric S. 2001. How To Become A Hacker. http://www.catb.org/~esr/faqs/hacker-howto.html.

Finally, a few things not to do.

• Don't use a silly, grandiose user ID or screen name. 

[...]

The only reputation you'll make doing any of these things is as a twit. Hackers have long memories — it could take you years to live your early blunders down enough to be accepted.

The problem with screen names or handles deserves some amplification. Concealing your identity behind a handle is a juvenile and silly behavior characteristic of crackers, warez d00dz, and other lower life forms. Hackers don't do this; they're proud of what they do and want it associated with their real names. So if you have a handle, drop it. In the hacker culture it will only mark you as a loser.

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.
  

Hacker and Community, part 1/2: Hacker vs Cracker

Before unpacking the information I have already collected (it seems I have more material to posts than time to write), it is essential to defined two key concepts. The first one is the concept of hacker, the main agents of free/open software development, and the second one, to answer rsrcher, the concept of community, how does it defined itself in a virtual context. This post is the first in a series of two: it will try to outline the hacker concept. The second post will concern the community part.

The “hackers” concept has been abusively over abuse by media over time, as noted in Cybermethods by Hellen Megens and Brian Martin:

“The meaning of the word "hacking" has changed over time. Originally it meant building hardware and software and was considered admirable. Media coverage has increased public awareness of hacking but changed the meaning in a negative way.” (Megens and Martin, 2003)

However, many maintain the original definition, explicitly the Free / Open Source Software developers. Many still call themselves hackers. According to the The Jargon File, also known as The New Hacker's Dictionary, hacker can be define as this:

“A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. RFC1392, the Internet Users' Glossary, usefully amplifies this as: A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.” (Jargon File 4.4.3, 2003)

Also, the term hacker implies a person who follows the hacker's ethic code, describe in the Jargon File as followed:

“hacker ethic: n.

1. The belief that information-sharing is a powerful positive good, and that it is an ethical duty of hackers to share their expertise by writing open-source code and facilitating access to information and to computing resources wherever possible.

2. The belief that system-cracking for fun and exploration is ethically OK as long as the cracker commits no theft, vandalism, or breach of confidentiality.

Both of these normative ethical principles are widely, but by no means universally, accepted among hackers. Most hackers subscribe to the hacker ethic in sense 1, and many act on it by writing and giving away open-source software. A few go further and assert that all information should be free and any proprietary control of it is bad [...].

Sense 2 is more controversial: some people consider the act of cracking itself to be unethical, like breaking and entering. But the belief that ‘ethical’ cracking excludes destruction at least moderates the behavior of people who see themselves as ‘benign’ crackers [...]. On this view, it may be one of the highest forms of hackerly courtesy to (a) break into a system, and then (b) explain to the sysop, preferably by email from a superuser account, exactly how it was done and how the hole can be plugged — acting as an unpaid (and unsolicited) tiger team.

The most reliable manifestation of either version of the hacker ethic is that almost all hackers are actively willing to share technical tricks, software, and (where possible) computing resources with other hackers. Huge cooperative networks such as Usenet, FidoNet and the Internet itself can function without central control because of this trait; they both rely on and reinforce a sense of community that may be hackerdom's most valuable intangible asset.” (Jargon File 4.4.3, 2003)

Therefore, it is possible to understand the distinction between “hackers” and “crackers”. Eric S. Raymond, a notorious hacker, sums it simply:

“[H]ackers build things, crackers break them.” (Raymond, 2001)

In this definition hackers have little in common with what Raymond calls “cracker”. Media has mis-associate both together, but for the purpose of this project, I will use the hacker's term as F/OSS community understand it, i.e. as programmer who are drive by their desire to understand computer system and to share that knowledge to their community.

Reference:

Megens, Hellen, and Brian Martin. 2003. Cybermethods. First Monday. February 3. http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/viewArticle/1035/956.

Raymond, Eric S. 2001. How To Become A Hacker. http://www.catb.org/~esr/faqs/hacker-howto.html.

Raymond, Eric S. 2003, (Ed). The Jargon File, version 4.4.7. http://www.catb.org/jargon/.

Participant observation as a method

After some scouting on the Ubuntu forums, I've come to the point were participant observation need to kick in. I've located a working team that I will try to join as a regular member, and I will participate as much as I can in the free / open source projects. For ethical reason, I'll notify the group leader of my researcher's status. On another part, I will comply with their norm and behavior as much as it is possible for me. There are various requirements to join the team that I'll try to fill out. The inclusion process in itself will probably provide lots of information on what defined this group. This part will be my main objective for now and once inside the group, I'll see how I can contribute, and at the same time I hope to get a better understanding of the community..

On a different note, language is a key component in understanding how a community think and work. So last weekend, in a spontaneous excess of motivation, I've started learning a programming language. This experience is completely new to me, but already, I've learned many things about the community through this learning process. 

For someone who has never programs before, learning a code language involve more than reading a manual. You need to choose out a language to learn (oh yes, there's more than one!), why this one is relevant for the F / OSS community, you need to look for advice, for new module to include in your program and so on. When I made this decision, I hadn't realized how relevant this might be. Even if the main focus on this project will not be on programming language, I think the process of learning a language may provide insightful information. 

In sums, I start my investigation with those two paths: 

1- Getting accepted in a working group.

2- Learning coding language

The objectives in themselves are not relevant, the process is.