looking east

The next Beijing Open Party will take place on July 19th at the Thoughtworks offices in Beijing. If you want to give a talk, you can propose it on the Beijing Open Party google group. Alternatively you can also just show up at the party and propose your topic. The party’s original announcement can be found here.

Event:  BeijingOpenParty July: Summer Daydreams (仲夏梦舞)
Date: July 19th
Time:  13.30 - 17.30
Address:  Room 1105, 11th Floor GuoHua Plaza, No.3 Dongzhimen South Street, Dongcheng District, Beijing, China, 100007, see map.

Here a few impression of last weekend’s coding for fun event at Exoweb, unfortunately I didn’t take many pics.

Technologies applied included: Pike, OpenGL, Flash, Chipmunk, Twitter, cURL, Festival, C, Boarduino, Arduino, LED, and many more.

Update: Martin has offered me to add his pics to my flickr account. Thanks, Martin :).

“every time you want to know what a nonhuman does, simply imagine what other humans or other nonhumans would have to do were this character not present.”

Bruno Latour in Mixing Humans and NonHumans Together: The Sociology of a Door-Closer, p. 299.

Inspired by this paper by Basile Zimmermann, I would like to do a small thought experiment about open source development using Latour’s citation as a starting point. It’s almost impossible to imagine open source software without nonhumans. A nonhuman is a object which plays a specific role in a certain context. For example, the remote control allows the human TV watcher to control the TV from the couch without standing up to change the TV settings from the TV itself.

To start with, I would like to create a non-exhaustive list of human and nonhuman actors in open source development. Nonhuman actors include: the developer’s computer, the servers on which the project is hosted, the bug tracking system, the code repository, the IRC channel, the project website, the mailinglist, the code files themselves, binary packages, the software running on the developer’s computer, the software running on the server, etc. Human actors are: the developer, a “community” of developers around the world working on the project, the project maintainer, the server administrator, the people who have manufactured the developer’s computer. I think you can see where this is leading. The idea is to show that a single developer sitting in front of his computer is connected to a huge network of humans and nonhumans who “help” him complete the task. Some of them, like the computer manufacturers, have played a more important role in the past, but they continue to be a part of the developers’ current work.

Now, let’s try removing a nonhuman actor. I’ll choose the most obvious one, the developer’s computer. If the developer doesn’t have a computer, how can he contribute to the open source project? In this case, the answer is quite obvious: He will have to find another computer to replace it. However, a computer cannot simply be replaced by another one as the open source software he is working on might require a specific software setup. If the developer has access to a university lab, he could go there and start setting up a computer. He might first have to ask the university’s administration, if he is allowed to configure the computer and install software. And if not, he will need to follow a procedure to receive this permission. Once he has access to the computer and set up the operating system and the required software, he could start working on the project. However, the university lab might have specific opeingn hours, and our developer will again have to deal with the university administration to receive a key to access the lab whenever he wants.

What do we learn from that? A developer’s computer can only be replaced by another computer. To really replace the computer all together, it would be necessary to rebuild a computer from scratch with all the people and technologies involved in computer production. We also see that if our developer doesn’t own a computer, he will need to go through a more or less complicated set of steps to obtain access to one.

To conclude the thought experiment, let’s imagine the code repository is not present. That means, there is no way to access the source code online, to commit to a common code base, and to obtain the latest version of the trunk. In this case, the source code could be maintained by the project maintainer. That means, if our developer wants to contribute to the project, he will first need to obtain the latest version of the code. He would thus need to write an email to the project maintainer and ask for it. Once the developer has made a change, he would need to send the code back. If the project receives code from several developers, the maintainer would need to merge the code into the main version each time. Merging the code without software means that the maintainer would first need to find out which files have been changed and then open these files and compare them line by line to see what changes have been made. Additionally, after each merge, he will need to test if the software still works as required and if the features added really did what they promised to do. These are all tasks that are generally done by the community when a source repository is present.

So, what is this post about? It’s about to show how complex open source development is, how many actors, human and nonhuman play a crucial role in it’s existence, and what impediments can occur when one or several of the actors are missing.

“Patch hoarding” refers to not committing kernel changes to the kernel trunk which has been a constant issue in the Linux community. At the CELF Embedded Linux Conference last week, Andrew Morton explained the why companies and developers should commit their changes to the kernel:

“One of the areas that he is most concerned about is the practice of “patch hoarding”—holding on to kernel changes as patches without submitting them upstream to the kernel hackers. It is hopefully only due to a lack of resources, but he has heard that some are doing it to try and gain a competitive advantage. This is simply wrong, he said, companies have a ‘moral if not legal obligation‘ to submit those patches.

There are many good reasons for getting code merged upstream that Morton outlined. The code will be better because of the review done by the kernel hackers; once it is done, the maintenance cost falls to near zero as well. He also touted the competitive advantage, noting that getting your code merged means that you have won—competing proposals won’t get in. Being the first to merge a feature can make it easier on yourself and harder on your competition.

There are downsides to getting your code upstream as well. Most of those stem from not getting code out there early enough for review. The kernel developers can ask for significant changes to the code especially in the area of user space interfaces. If a company already has lots of code using the new feature and/or interface, it could be very disruptive; ‘sorry, there’s no real fix for that except getting your code out early enough‘.

Another downside that companies may run into is with competitors being brought into the process. Morton and other kernel hackers will try to find others who might have a stake in a new feature to get them involved so that everybody’s needs are taken into account. This can blunt the “win” of getting your feature merged. Some are also concerned that competitors will get access to the code once it has been submitted; ‘tough luck’ Morton said, ‘everything in the kernel is GPL’.”

Read the full story on LWN.net here.

“Go GNOME - Free Your Desktop” is the theme of the first GNOME Asia Summit to take place on October 17/18 2008 in Beijing. The summit aims at strengthening the ties among GNOME and Open Source community members in Asia. The organisers are currently calling for speakers to send their talk proposals to asia-summit[at]gnome.org. In order for the summit to become a truly Asian event, it would be cool if developers and geeks from all over Asia apply. So don’t be shy, just send in your proposals!

Getting started with open source development is not as easy as one would think after all. In chapter 5 of her thesis, Evangelina Berdou explains the entry barriers which have to be overcome by newbies. As she explains very well, there are several aspects which should not be underestimated:

“Despite their open collaborative character, F/OS communities are characterized by significant barriers to entry. The stumbling blocks to participation can be categorized into three broad categories. First, there are difficulties associated with the technical aspects and tools of F/OS development, such as the use of CVS. Secondly, there are conceptual difficulties related to understanding the development process and the architecture of the program, how they are set up, how things fit and how they are expected to be put together. Thirdly, there are difficulties related to how newbies situate themselves in the development process, where they start and what are the tasks most appropriate to their skill levels.”

To contribute to an open source project, newbies will first have to learn how to check out the newest code (often referred to as trunk) from the code repository (like SVN, CVS, or GIT), and how to build it from source with all the necessary compilers, dependencies, and tools. For someone who is not familiar with these processes and methods, this is very often far from straightforward.

Once they have been able to build the software, they will need to find an appropriate task to work on. In most cases, the first task will be a simple bug fix and result in a patch that can be submitted to the codebase. However, finding a task is not as easy as one might think. It often involves reading the mailing list archives, following discussions on IRC, as well as reading bug reports, find out who is working on which bug, and which bugs are yet to be solved. An easier way to get started with development is, to first start working on the non-coding parts of the project as a way to learn more about the project’s community organisation and technical details. Starting off with documentation, bug reporting, bug reproduction, and translation work is often cited as a very good way to make a first step towards contribution. Some projects offer mentoring for new developers which is another great way to get started.

While writing code for contribution, a newbie has to learn about the coding guidelines of the community. What is best practice for customizing the software’s view? Does this code really belong in the core? Where do I define my constants? How do I document my code? Where do I place my files? Once a patch has been written, the newbie will have to learn how to submit it to the community. I have quite often seen people entering an IRC channel and saying that they have implemented some code that they would like to contribute to the project, so this seems to be a real issue. Depending on the project, the process of contribution might be only poorly documented. As a matter of fact, Evangelina Berdou has cited the fragmented nature of documentation as one of the main difficulties for newcomers.

After submitting the patch, the developer can do nothing much but wait for the verdict of the community. Although in most cases, the contribution is very much appreciated, it might happen that the code is being publicly criticised or not accepted into the trunk. Depending on the project, the contributor might simply never get any feedback from the community. Most communities, however, tend to stress the importance of giving feedback to its contributors.

Now, having committed a first patch is a good start. However, developers who occasionally submit a piece of code, will always depend on other people to add the code to the project’s trunk. In most open source projects, only core developers and a few selected individuals have direct commit access to the code repository.

At LIFT08, Gen Kanai gave a very insightful talk about the state of open source in Asia. In his presentation, he mentions this interview with Linus Torvalds where Linus cites the following reasons for the low participation in open source in regions other than North America and Western Europe:

• Language
• Culture
• Education

Gen Kanai adds another factor this list:

• Economy

Language

Language is definitely a problem, at least from what I have seen in Thailand. However, even though Thai developers don’t tend to speak much English (probably they are just shy), they have a very good notion of written English. The same is valid for China. Hence, language as such is an issue, but probably not the main reason why open source contributions from Asia are scarce.

Culture

Culture is a big word. It can incluce pretty much anything, and it’s often very easy to say that culture is a problem. From what I have heard at the Linux Developer Symposium in Beijing, Gen Kanai’s talk at LIFT08, and some other sources, one main issue is considered to be the “direct” communication among community members. Mailinglist posts sometimes can be quite rude and it’s definitely not considered polite by Asian standards. However, it’s not considered polite by western standards either. Andrew Morton insisted at the Linux Developer Symposium on not taking these reactions too personal:

“The problem is, one person says something, and though not everyone agrees, nobody contradicts. Today it’s not as bad as it used to be, and it’s important not to forget: these people don’t speak for anybody else, they only speak for themselves.”

Although I do think that rudeness is a problem, I am not sure about how much this problem is related to culture. I mean, why are there only few women involved in software development in general and open source in particular? I think this is at least partly due to the fact that open source development is dominated by Western males. I believe that if more women were involved in open source, it would become more attractive for other women. The same holds for Asians. If they see that other Asians are involved, they will be more motivated to join. People tend to hang out with people who share common backgrounds and interests.

Education

I don’t agree with Linus in this point. He says that education is not a problem for Asia. However, I do believe it is a problem. Not education in a general term, but more specifically education in the sense of creating awareness about open source. It seems that open source as it is taught at universities in Thailand and China, is mainly concerned with how to make use of open source without mentioning communites, philosophy, and participation.

Now thinking back, when I was at university, I am quite sure that I didn’t hear about open source from a professor. It was all implicit. Most computers ran Linux, all software developed by the university was freely available online, everyone, including professors, assistants, and students simply lived open source. There was no need to explicitely teach us. What does that mean for Asia? Probably, universities in Asia (though I only can speak for Thailand and China), do not really “live”open source, the students therefore don’t have enough examples and don’t get inspired by the open source spirit. I don’t think Asia needs government support as it was discussed at the Linux Developer Symposium. I think all it needs are role models, individuals who are passionate about open source, who are actively involved in the community and who are motivating other people to do the same thing.

Economy

Economy is definitely a reason why companies don’t contribute to open source. Often, tight schedules, lack of human resources and so on will prevent them from doing so. Additionally, the traditional view of competition in the software sector continues to prevail in many parts of Asia, and the open source business model hasn’t reached many companies yet. I met some developers at the symposium who worked for companies which prohibited contributing code to open source. As, according to Jonathon Corbet, about 75 percent of the Linux kernel developers are doing their development as part of their job, this is a major issue. Moreover, working hours in some Asian companies tend to be very long for different, mostly “cultural” reasons. That means that the developers’ free time can be very short and does hardly allow them to participate in an open source project. I have also heard of cases in which companies actually claimed ownership for any code a developer produced while working for them. Hence, economy is probably the main reason for the low participation of Asia in open source.

Linux Developer Symposium China 2008 was really cool. I got to meet plenty of people including Chinese Linux developers, members of the BLUG, and the Linux Foundation.

The conference started off with a full day of talks, followed by a second day with discussions. Topics included everything Linux, like File System, Desktop, Mobile Linux, and Linux Challenges for the future. A large number of talks and discussions were actually concerned with mobile Linux, a topic that is of interest to a large number of people and companies in China. Another recurring issue were device drivers and their integration into the Linux public kernel. This, of course, has been a central topic in the Linux community for a while, and it seems that quite a few companies in China are maintaining their own device drivers privately without contributing them to the public kernel, even though this would considerably decrease long-term maintenance costs.

There is plenty happening in terms of Open Source in China. At the conference, many of the large software companies were present and showed considerable interest in China and Open Source. However, even despite government support and business representations, there seems to be only little contribution to Open Source projects in China so far. This will probably be changing and I believe that we will see some quite impressive Open Source stuff going on in China in the near future.

Though I have already almost abandoned the idea of going to Beijing to the 2008 Linux Developer Symposium China, I will still go since I found an affordable flight ticket. I am quite excited about going to Beijing, and I am sure there will be plenty to discover for me. However, I have heard about the awful weather there lately and I am kind of scared of the cold. Guess I’ll need to go do some serious shopping before leaving.

David Feng started a new blog on technology in China. The blog is only six days old and he has already published 13 posts, most of which are really promising. For example, yesterday he wrote a good one about Chinese censorship, for once not just a variation of the standard rumblings on the topic. It’s the first post of a series he calls “Mind the Gap Saturday” which I guess he will be publishing every saturday:

techblog86’s Mind the Gap Saturday focuses on the Chinese tech, mobile and startup worlds and why there’s a gap between the Chinese and Western sides of things.

Anyway, here’s the link to the blog: http://www.techblog86.com.