looking east

“What you say sounds great, but honestly, how can we make money with FOSS?” This is a question I have been frequently asked since I have come to China. It’s the kind of question which made think a lot about FOSS and it’s business model. It’s a question which seems crucial for China, and since I have been asked so many times, I have been trying to improve my answer by asking other people. However, none of these solutions seemed really satisfying, and whatever I said was met with strong resistance and further questions.

When reading the book Open Sources: Voices from the Open Source Revolution, I found the following answer to the question by Robert Young:

“That question assumes that it is easy, or at least easier, to make money selling proprietary binary-only software.

This is a mistake. Most software ventures, whether based on free or proprietary software, fail. Given that until very recently all software ventures were of the proprietary binary-only kind, it is therefore safe to say that the IP (Intellectual Property) model of software development and marketing is a very difficult way to make a living. […]

No one expects it to be easy to make money in free software. While making money with free software is a challenge, the challenge is not necessarily greater than with proprietary software. In fact you make money in free software exactly the same way you do it in proprietary software: by building a great product, marketing it with skill and imagination, looking after your customers, and thereby building a brand that stands for quality and customer service.” (chapter 9)

The fact that it’s very difficult to make money with proprietary software is probably even more true for China. In a country in which nobody is actually willing to pay for software, the question should not be: “How can we make money with FOSS?”, but rather: “How can we make money with software?”. But let’s first continue looking at the original question. As Robert Young puts it, in some cases using FOSS can even be a competitive advantage:

“Marketing with skill and imagination, particularly in highly competitive markets, requires that you offer solutions to your customers that others cannot or will not match. To that end Open Source is not a liability but a competitive advantage. The Open Source development model produces software that is stable, flexible, and highly customizable. So the vendor of open-source software starts with a quality product. The trick is to devise an effective way to make money delivering the benefits of open-source software to you clients.” (chapter 9)

This is exactly what I tried to say when I tried to answer the question. I told them that FOSS allowed them to start off with a high-quality source base rather than reimplementing everything from scratch, that open source made it easier (and affordable) to build highly customised products, I mentioned that in the West many businesses have been created because of the relative low cost of building software on top of FOSS. However, all these explanations were countered with more questions and strange looks.

Today, I believe that Robert Young does successfully answer the question of how to make money with FOSS. I also think that my answers were not totally wrong, though I simply missed one important fact: That making money with FOSS doesn’t have to be harder than making money with proprietary software. And thanks to Robert Young, I believe that the real question should be “How can we make money with software?”, and more specifically, “How can we make money with software in China?”.

I have spent a bit over three months in China, trying to find out how FOSS is organised and how it’s different in China from what we see the West. When I met Basile two weeks ago in Beijing, we have come up with the following hypotheses:

• Language is an impediment. Most FOSS activities take place in English.
• There is no culture of innovation in China.
• The discussion culture in FOSS projects is too confrontational.
• FOSS is still too young in China to be successful.
• There is only little support for FOSS in the Chinese software industry. Piracy has a negative effect on the creation of a proper software industry in general. Customers are not willing to pay for software.
• Students don’t learn about FOSS at universities and hence don’t know about it.
• Individuals can’t make money with FOSS in China.
• Chinese government policies are not favourable towards FOSS.

These hypotheses are an extension to the ones presented in an earlier entry I have posted in February. They are specifically applied to China (because that’s the country I am currently studying) rather than Asia in general, though I do think that most of them could be applied to other countries like Thailand too.

Despite the fact that these hypotheses are rather negative in their formulation and might have some other shortcomings, I believe that they provide a good basis for further discussions. Also, hypotheses are there to be proved or disproved, they don’t need to be valid in the first place.

Why am I posting this?

Because I would like to get some feedback. I would love to know if there is something completely wrong with them, if I have totally missed the point, if I have forgotten something important, or anything else you have thought of while reading them. Please let me know :).

Technical objects define in their configuration a certain partition of the physical and social world, they attribute roles to certain types of actors - humans and non-humans - and exclude others, they authorise certain modes of relations between these different actors […] in such a way that they participate as a whole to the construction of a culture in the anthropological sense of the term, and, at the same time, they become enforced mediators in all relations that we are maintaining with the “real”.

Madelaine Akrich, Comment décrire les objets techniques?

Later in her paper, Madelaine Akrich introduces the term “script” to refer to the behaviour of a technical object. The “script” is the program which the original developers write in order to define how the object can be used by its users.

For the purpose of studying FOSS in Asia, the technical object would be a piece of FOS software, its behaviour is defined by the source code, and the users are people who are using this software from within the borders of what is defined as Asia.

However, the scope of my master thesis as described above is not complete. FOS software has a specific characteristic which is related to it’s licensing terms. I don’t want to enter into FOSS licensing in detail, but I would like to emphasise one interesting aspect of open source software: modifiability. This means, we can take a piece of existing FOS software and tailor it to our needs. Going back to Madelaine Akrich’s definition of the “script”, this means that the “script” can be modified by its users. We are thus moving away from the traditional developer-user model to a more distributed open source community development model. In FOSS, users are not stuck with a pre-defined script, rather they are encouraged to change the script according to their needs. This in turn, forces users to think about the software in terms of its utility to an individual.

To be honest, the source code or “script” cannot be changed by any random user. Instead, this freedom is restricted to people who are familiar with computer programming. However, FOSS has made it easy for users to give feedback, propose new features, and report bugs. You don’t need to be a programmer to do this, though you still need to be able to use a computer and run the program.

Implementing modifiability into objects is not new, although the open source movement and its derivatives have been strongly promoted lately. In his book Two Bits, Kelty investigates the impact of modifiability on culture, he writes:

But what is the cultural significance of modifiability? What does it mean to plan in modifiability to culture, to music, to education and science? At a clerical level, such a question is obvious whenever a scholar cannot recover a document written in WordPerfect 2.0 or on a disk for which there are no longer disk drives, or when a library archive considers saving both the media and the machines that read that media. Modifiability is an imperative for building infrastructures that can last longer. However, it is not only a solution to a clerical problem: it creates new possibilities and new problems for long-settled practices like publication, or the goals and structure of intellectual-property systems, or the definition of the finality, lifetime, monumentality, and especially, the identity of a work. Long-settled, seemingly unassailable practices — like the authority of published books or the power of governments to control information—are suddenly confounded and denaturalized by the techniques of modifiability. (page 12)

Modifiability is at the core of FOSS. It’s one of the main reasons why FOSS communities have emerged. It’s at the base of almost all discussions on mailinglists, forums, IRC channels and FOSS events. The users and developers can decide the future of the software by participating in these discussions. The fact that a FOSS culture has emerged around open source software, proves Madelaine Akrich’s point that technical objetcts are important elements in the construction of cultures. And, of course, despite it’s modifiability, FOS software has a “script” which clearly defines how it’s supposed to be used

Despite the fact that nobody is willing to pay for software and that proprietary software is free as in free beer, there are some points to be considered:

• FOSS is legal to use, copy, modify, and distribute. Especially in China, where new laws can be enforced within little time, this can be a considerable advantage. However, it doesn’t seem that anti-piracy laws will be enforced anytime soon.
• FOSS can be modified to meet the exact needs of the users. This is impossible with proprietary software.
• FOSS has always been free, and FOSS-based companies have always been forced to come up with different business models. Hence the Chinese situation is not that different from other countries.

The question is: If people don’t pay for software, will they pay for customisation of open source code? Are they willing to pay for services and support related to the software?

I have been in China for almost three months now. I have attended quite a number of FOSS-related events, have spoken to many people, and observed everyday programming at Exoweb. I have taken notes, asked questions, actively participated, and helped organising events. I now have a large pile of important-looking business cards, some new contacts on GTalk, Twitter, Facebook, and a wiki full of words describing what I have experienced, but I am still struggling to describe open source in China.

So far it seems that FOSS in China is mainly about talks, about promotion, about words, not that much about code. When it comes to software, China and Thailand are special cases: Software is generally available for free or little money, independent of it being open source or not. Piracy is omnipresent, licenses don’t exist. It seems almost impossible to make money with software development in China. People just don’t want to pay for it.

Questions

How does this influence software development in China? Are there new business models emerging from this? Is there a need for China to have a software industry at all? How does it influence innovation and creativity? How do existing software development companies survive? What about web (2.0) development?

“Free Software is a set of practices for the distributed collaborative creation of software source code that is then made openly and freely available through a clever, unconventional use of copyright law. But it is much more: Free Software exemplifies a considerable reorientation of knowledge and power in contemporary society — a reorientation of power with respect to the creation, dissemination, and authorization of knowledge in the era of the Internet.”

Christopher M. Kelty, Two Bits (2008), page 2.

What happens if we place this definition in an imaginary context in which copyright law doesn’t exist, where people are prosecuted for mentioning “reorientation of knowledge and power”, and where creativity is not considered a positive trait?

Yesterday, the Quadcopter group of the Beijing LUG met at the Exoweb office to assemble the pieces of the boarduino  microcontrollers. We had lots of fun, and I learned a great deal about hardware, soldering, resistors, LED’s, analog, and digital pins, as well as microchips. Although the Quadcopter group’s final goal is to build a quadcopter, the microcontrolles we built yesterday were rather an educational experiment in which we tried to understand the internals of the boarduino.

The boarduino is an Open Source arduino clone which can run the same software as the arduino. Unfortunately, we didn’t succeed in loading the bootloader to the chip yesterday, so we will need to wait for next time to start programming.

Exoweb shows a strong commitment to Free and Open Source Software (FOSS), most of the computers run Linux, much of the software developed is based on Python’s Django framework, and a few people are actively involved in Open Source projects.  One of my tasks at Exoweb is to strengthen the relations between Exoweb and the FOSS communities by encouraging FOSS-related activities, and finding ways for Exoweb to collaborate with the communities.

The Open Source Business Model

I was invited to a discussion about Open Source in China at the Programmer magazine two weeks ago, and one of the things I learned was that companies trying to build on FOSS don’t seem to be very successful in China, and many of them are struggling for survival. One of their main worries is how to actually make money with Open Source. Of course it is true that if a company wants to build a completely new FOSS  product, it would be hard to find a way to finance the development.

However, as the Exoweb example shows, you don’t really need to start with a new product, but you could just build your business based on existing FOSS software. In that case, the company doesn’t need to invest in product development at all, but can immediately start their business by customising an existing product for the needs of their customers. This is one of the main reasons why the FOSS business model has proved to be so successful in the West.

Contributing Back

Using FOSS products is an excellent way to get started. And once you have become fairly familiar with the internals of the products you are using, you will might start building your own reusable components based on the existing software. You might also discover bugs, fix them, and send patches to the community. As this will improve your final product you are building for a client, the time spent on building components and patches can be, at least partly, covered by the customer’s mandate. Of course, the client has to agree to that, especially if the code is being  published with an Open Source license.

However, contributing to FOSS might in many cases require more time than just writing the code for a specific project. The patch has to be documented and packaged according to the the FOSS project’s standards, and the the reusable components have to be maintained and improved to guarantee future reusability. While one can easily understand the reasons for contributing back a patch, questions might arise as for the components to be open sourced or not. In some cases, like Linux which is based on GPL, developers are in theory constrained by the original project’s license. Though despite this fact, I strongly doubt that the GPL could be enforced in China.

There could be other reasons for a company to open source a component’s or extension’s code: Maintenance and marketing. When the company is the only owner and developer of the extension, they will be forced to change the code whenever they decide to upgrade to a newer version of the original product. In an Open Source world, however, there might be other developers interested in maintaining the code, or even better, the code is added to the project’s core and is thus maintained by the community. Additionally, creating and maintaining Open Source code can have a considerable marketing effect for the company.

Exoweb and the FOSS World

Exoweb is trying to actively engage in the Django and Python community, as well as other local communities like the Beijing Linux User Group (BLUG). They have hosted the Django Sprint in Beijing in December last year, and are currently planning other similar events. Additionally, some of the teams are developing extensions which they want to add to Django’s contribution repository, and a few developers are working on their own FOSS projects. In order to encourage it’s employees, Exoweb additionally offers a 10 per-cent time during which everyone is free to work on whatever they want. Exoweb also offers hosting for internal FOSS projects on contrib.exoweb.net.

“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.

Language issue as discussed at the Ubuntu Open Week (see full discussion log here):

[19:44] <iulian> <ligemeget> QUESTION: How do we deal
with bug reports containing error messages in another
language than English?
[19:45] <pedro_> well that depends, if somebody filed a
bug in spanish and you talk spanish, translate the report
[19:45] <pedro_> otherwise if you have time you can ask
for more info or reject the bug waiting for a
new one in English
[19:45] <pedro_> more info meaning "Please translate
this in English"
[19:45] <pedro_> s/in/into
[19:46] <pedro_> sadly we have to deal with hundreds
of reports daily and we don't have enough resources to
translate all of them

How do non-English speakers deal with that? Are there readily available translators in the different countries? Or are bugs first reported through the channels of the local community and then only added to the global bug database?

Update: There is a similar discussion about blog posts appearing on Planet GNOME in languages other than English currently going on. For details, see the comments to this Spanish post, and the follow-ups here, and here.