Lessons learned from Munich's migration to Linux

I attended LinuxTag in Berlin last week and there was a very interesting presentation about the state of Munich's migration to Linux on the desktop. Andreas Heinrich explained that their goal is to migrate 80% of the 15000 desktops to Linux. At the moment, 6200 desktops have been migrated and they intend to have a total of 8500 Linux desktops by the end of the year.

Here are some of the key lessons they shared with the audience:

• Technical activities and requirements are easy to manage but managing social factors of change is hard since all change is associated with fear. They have specific people who are responsible for change management and for communication. For example, they organize events to share information and provide training. They also give away CDs so that employees can use the software at home.
• Make sure the new system is accepted: if users don't like the system (for whatever reason), their boss and other employees will know immediately since "bad news travels fast". Make sure that user needs are met: they talk a lot to their users to find our what their needs are and how to meet them.
• Don't make a "big bang" migration: instead of migrating everyone at the same time, they prefer gradual change. They started with some users, saw what worked and what didn't and then used that knowledge to improve their migration process.
• Don't migrate everyone: their aim is to convert 80% of desktops to Linux. There are some users who have specific needs for which only proprietary solutions exist. If Linux and open source offers no solution, it doesn't make sense to migrate those users.
• Don't go with dual-boot: if open source meets the needs of your users, there's no reason to provide an alternative. On the other hand, if open source does not meet their needs, don't attempt a migration.
• Continuous improvement: after making a new release of their software or migrating users, don't consider the migration as complete. Instead, see how you can further improve the user experience.

It seems that the city of Munich has learned a lot from their Linux migration. We can hope that other Linux migrations will make use of the lessons learned by the folks in Munich.

Project management lessons from the FreeDOS Project

A lot of people seem to think that open source is a magic solution to project management and that open source projects will automatically attract a large and healthy community of contributors and users who will improve the software. This, of course, is not the case. In fact, creating a successful open source project is a really major and difficult effort. You have to deliver an initial promise that people find interesting, attract other people, then facilitate and lead the community, etc. You just have to look at all the failed projects on SourceForge that never delivered any code to see that "open source" is not a guarantee for success.

Even though project management is a key element of every open source project, there are only few resources about this topic. That's why I always enjoy reading about the experience from open source project leaders. Jim Hall, the founder of the FreeDOS project, recently posted a series of four articles which I find particularly interesting.

Here are links to the articles along with a quick summary:

• Free and Open Source Software: the first article just describes what free software and open source are all about. It also looks at Raymond's model and compares the cathedral and the bazaar style of development.
• Starting Open Source Software: this article summarizes a number of key lessons learned: every project needs a clear purpose (i.e. you have to solve an actual problem); initial users of the software should be recruited as developers; releases are important; and every project needs an active coordinator or maintainer.
• Cultivating Open Source Software: you need a web site; making the source code availability in an easy way is important; documentation is often hard to write but is vital; you need a bug tracking system and responding to bug reports is important to attract good feedback.
• Transitions in an open source software project: finally, when you need to hand over the project, make sure to communicate openly, arrange for your replacement and stick around to ensure a successful hand over.

I really like these articles from Jim Hall since they contain a lot of great insights that apply to other projects, so I suggest you check them out!

(Originally published on FOSSBazaar)

Corporate participation in open source communities

Someone recently asked me a few question about corporate participation in open source communities and I thought I'd share my thoughts on this topic here.

Are there differences between an open source project done for a corporation and one done for personal reasons?

There are many different ways to run an open source project, led by a corporation or by someone else. Some projects that are run by corporations have few outside contributors. This is often the case with projects that require copyright assignment (i.e. contributors have to assign their copyright to the corporation). These projects may not gain all the benefits of a true open source community, such as outside contributions or high levels of peer review. However, they may still be very successful projects and may have high levels of quality.

Projects done by a corporation may have better planning and may have more resources than other projects. When a corporation, especially a large one, starts or becomes involves in a project it can also give credibility to the project and attract a lot of interest to the project. This means that projects done by corporations may have a bigger impact and might also be more visible in terms of publicity.

How do corporations successfully utilize an open source community?

Corporations can benefit from an open source community in many ways. For example, they can often find people who will review their code or make code contributions. If people become excited about what the corporation does, they might also spread the word and create viral marketing for the corporation. Establishing a community around one's project is often also a good way to identify people to hire since you already have experience working with them and know their capabilities.

How do open source communities successfully utilize their corporate relationships?

Corporations can make several unique contributions. For example, large corporations can use their name to attract attention to a project and give it credibility. Furthermore, corporations have some capabilities that personal contributors often don't have access. They may have special testing equipment (such as servers with thousands of CPUs or hard drives) or access to a testing lab where a professional usability test can be done. Finally, corporations can sponsor developer conferences, which are typically very effective means for the community to come together and work on activities together.

It is important for projects to remember that corporations are not charities and that they will invest in an open source project for a reason. Therefore, they have to ensure that the corporation will get tangible outcomes from their involvement or sponsorship, otherwise they may not stay involved in the long run.

What are the risks for a corporation when working with an open source community?

One risk is that the code (or other form of contribution) is not accepted. However, this is a risk any contributor to a project faces. Before making any sort of contribution, it is therefore important to become familiar with the project and its culture. Every project has their own "do's" and "don'ts" that have to be followed.

Another risk is that a corporation will invest in a community project that later on is abandoned by the community. However, in this case, the corporation could take the lead and continue to maintain the project.

What are the risks for an open source community when working with a corporation?

One potential risk is that the corporation will assert too much control over the project. It's important for projects to ensure that the community as a whole has influence over the direction of a project rather than one particular player.

Are certain certifications needed in order for someone to participate in open source projects for a corporation?

Certifications are not needed to get involved in or start a project. However, it is important to become familiar with the open source community and the project one wants to contribute to. A good first step is to read the book Producing Open Source Software by Karl Fogel which is available online. As a next step, the community in which someone wants to get involved in should be studied, for example by reading the mailing list archives. This will help to become familiar with the culture of a project as well as the mechanisms to contribute to the project.

How do open source communities communicate and collaborate with corporations?

In the best case, employees from corporations would interact in the project like any other contributor. That is, they should use the existing communication channels, such as mailing lists, IRC or developer gatherings. Many companies are good at working "with the community" but the ideal scenario is for a company to be part of the community and to work "in the community", just like other contributors. This is the most effective way for them to make changes to the code and project.

Of course, not every corporation will get involved in a project directly. That's why it makes sense for projects to collaborate with corporations in other ways. For example, projects can talk directly to companies to get samples of their hardware in order to add support for them in their software. Projects can also work directly with corporations to find out how their project can better meet the needs of enterprise users.

OSI signs an MOU with the Korea Software Copyright Committee

I visited Seoul last week to represent the Open Source Initiative (OSI) at an open source conference and to sign a Memorandum of Understanding (MOU) with the Korea Software Copyright Committee (SOCOP). SOCOP organized a conference with the title "Free Open Source Software License Insight Conference", and the international speakers included Brett Smith of the FSF, Brendan Scott of Open Source Law, Michael Coté of RedMonk and myself. From the questions we received, it seems that there is a lot of interest in legal questions related to open source. There were a number of folks from hardware companies that asked specific questions what they could do and couldn't do (e.g. related to including sources for GPL code and properly giving credit for BSD code).

I think the conference was a great success. The talks were of high value and we got good questions. The audience was quite mixed, ranging from managers to developers. Even though they had simultaneous translation of the talks, the majority of the people listened in English... this gives me hope that some of these folks will end up becoming involved in the international open source community.

SOCOP is working on a number of activities related to open source, including:

• An information portal called OLIS.
• The translation of all OSI approved licenses to Korean.
• The verification of open source code to identify which code uses which license.
• More promotional activities, including workshops and conferences.

The day after the conference, I went to the SOCOP office to sign the MOU between SOCOP and OSI with Mr Yung Bo Koo, the chairman of SOCOP. The MOU says that we'll share knowledge and expertise, help with promotional activities and support each other's activities in other ways. I was delighted to sign the MOU between SOCOP and OSI, and I look forward to a fruitful cooperation between our organizations in the future. It's great to see so much interest and so many activities around open source in the Republic of Korea.

Case stories of good and bad community interaction

It is often argued that companies have to work with the FOSS community and there are good reasons for doing so. I've tried to collect a number of case stories of good and bad community interaction that may help as a starting point for further exploration of this topic:

• NVidia is probably the best example of a company that is not interested in providing open source drivers for their graphics chips. There are lots of folks who won't buy hardware with NVidia chips for this reason. Intel is the number 1 choice at the moment because they work closely with the community. Related to this, the Linux Foundation and kernel community released a statement regarding open drivers.
• When Sun finally made Java available as open source, they argued that it would help inclusion and distribution of Java (e.g. inclusion into Debian). Sun also felt that the GPL provides the strongest protection "against misbehaviour by monopolists in the Java platform".
• The Novell/Microsoft deal was not perceived well by the community, which led to web sites like http://boycottnovell.com
• Nokia recently had an insightful blog posting about the problems when nobody knows about the open source contributions you make: for example, you cannot influence decisions in a project as easily.
• Sun is often criticized for dominating all open source projects they run. They can be used as a good example that you have to give up some control in order to get outside participation.
• The fact that Xen is not in the mainline kernel is a key reason why a number of companies (e.g. IBM, Red Hat) are looking at KVM (which is in the mainline kernel and actively developed in the community). In fact, "looking" is probably not the best word. IBM is actively working on KVM to make it a viable solution and Red Hat recently acquired Qumranet, the company behind KVM.
• Oracle got fairly bad press for copying the Red Hat distribution and changing Red Hat to Oracle, without engaging in the Red Hat community.
• There's a paper that looks at "empirical evidence on the incentives of firms that engage in OS activities." They look at 146 Italian companies supplying open source solutions, but unfortunately the study doesn't include any major company.

Can you think of other examples?

(Originally published on FOSSBazaar where comments are possible)

European Commission publishes guidelines on the procurement of FOSS

The Open Source Repository and Observatory (OSOR), a new site sponsored by the European Commission to foster the exchange of FOSS related information and software among European public administrations, recently published guidelines on the procurement of open source software. Public administrations in Europe have to follow public tender procedures and the new guidelines give practical and legal advice on how open source software and related services can be incorporated into the procurement process.

Rishab Ghosh, who presented the guidelines at the Open Source World Conference in Malaga, argued that the procurement guidelines were needed because of two reasons. First, they studied recent tenders and found that many explicitly mentioned proprietary applications. 16% of 3615 software tenders explicitly asked for products from top 10 software vendors, such as Microsoft, SAP and Oracle. This practice may be illegal because public tenders generally have to describe functional requirements in a general way instead of specifying specific products. Second, many public administrations don't have any experience with the procurement of FOSS. In fact, they often don't know whether or under which circumstances they are allowed to adopt and ask for FOSS solutions. The guidelines are specifically designed in order to clearly and simply explain how public administrations can acquire open source and they don't assume that a country has adopted a specific policy regarding open source.

The guidelines include a long section about open standards, open source and how they relate. Both open standards and open source align very well with the needs of public administrations who have an "obligation to support interoperability, transparency and flexibility, as well as economical use of public funds". The guidelines argue that the exit cost, i.e. the cost incurred in moving to another IT system, is also an important consideration but one that is often neglected. The adoption of a proprietary solution without open standards may limit the future choice, thereby increasing the long-time costs and giving the proprietary vendor an unfair advantage in future tenders.

The procurement guidelines describe two ways of acquiring FOSS: it is possible to go the usual route of publishing a tender for the supply of software (possibly with related services). However, in the case of FOSS, it is also possible to download the software directly from the Internet. This is possible because the software is not only free of charge but comes with no contractual obligations. If there were any obligations involved with the download (such as fees, the agreement to an EULA or the requirement to purchase services in the future), software download is not an allowed method. What I like about the guidelines is that they explicitly say that downloading software has to be part of the formal procurement process. You have to think about your requirements, look at various alternatives, and so on, and not just blindly download something from the Internet.

When it comes to the procurement of FOSS, the guidelines don't suggest that tenders should explicitly ask for FOSS. Instead, they should describe the functional requirements of the software as well as certain properties. For example, a tender could specify that the public administration as well as third parties must have the right to study, distribute and modify the software. In a sense, the guidelines suggest that tenders should include the principles of the Free Software Definition along with justifications for these requirements.

Personally, I think there is a great need for these procurement guidelines. There are many public administrations that don't know how to acquire FOSS and these guidelines offer clear advice. Furthermore, I find the guidelines very balanced. They don't recommend that you should always ask for FOSS but incorporate FOSS principles into tenders where it makes sense. It remains to be seen whether the procurement guidelines will have an impact on the FOSS adoption in Europe, but I surely hope so.

(Originally published on FOSSBazaar)

Amazing figures on the open source adoption in Finland

I attended Openmind last week, an interesting conference organized by the Finnish Centre for Open Source Solutions (COSS) to bring together open source professionals, community members and academics in Finland. In the session about business aspects of open source, in which I gave a talk about FOSS Governance, Nina Helander and Mikko Rönkkö presented the preliminary results of the National Software Industry Survey 2008.

I found the results incredibly interesting. In particular, they found that 75% of responding firms use open source software in some way. This figure is up from approximately 13% in the year 2000, which is a major increase in just a few years. The study also found that that there was no statistically significant difference of company size when it came to the use of open source. Finally, companies that have open source components in their offering rate themselves as more innovative.

Roberto Galoppini, who moderated the session, commented that Finland is where Gartner predicted that companies would be in 3 years. Indeed, I think everyone in the room was pleasantly surprised by the amazing numbers from the survey. We should not forget that the study was with software companies and that the use of open source will certainly be lower in other industries, but nevertheless the study shows that Finland is a leading country when it comes to the adoption of FOSS.

(Originally published on FOSSBazaar)

Differences between paid and volunteer FOSS contributors

There's a lot of debate these days about the impact of the increasing number of paid developers in FOSS communities that started as volunteer efforts and still have significant numbers of volunteers. Evangelia Berdou's PhD thesis "Managing the Bazaar: Commercialization and peripheral participation in mature, community-led Free/Open source software projects" contains a contains a wealth of information and insights about this topic.

Berdou conducted interviews with members of the GNOME and KDE projects. She found that paid developers are often identified with the core developer group which is responsible for key infrastructure and often make a large number of commits. Furthermore, she suggested that the groups may have different priorities: "whereas [paid] developers focus on technical excellence, peripheral contributors are more interested in access and practical use".

Based on these interviews, she formulated the following hypotheses which she subsequently analyzed in more detail:

1. Paid developers are more likely to contribute to critical parts of the code base.
2. Paid developers are more likely to maintain critical parts of the code base.
3. Volunteer contributors are more likely to participate in aspects of the project that are geared towards the end-user.
4. Programmers and peripheral contributors are not likely to participate equally in major community events.

Berdou found all hypotheses to be true for GNOME but only hypothesis two and four were confirmed for KDE.

In the case of GNOME, Berdou found that hired developers contribute to the most critical parts of the project, that they maintained most modules in core areas and that they maintained a larger number modules than volunteers. Two important differences were found in KDE: paid developers attend more conferences and they maintain more modules.

Berdou's research contains a number of important insights:

• Corporate contributions are important because paid developers contribute a lot of changes, and they maintain core modules and code.
• While it's clear that the involvement of paid contributors is influenced by the strategy of their company, Berdou wonders whether another reason why they often contribute to core code is because they "develop their technical skills and their understanding of the code base to a greater extent than volunteers who usually contribute in their free time". It's therefore important that projects provide good documentation and other help so volunteers can get up to speed quickly.
• Since many volunteers cannot afford to attend community events, projects should provide travel funds. This is something I see more and more: for example, Debian funds some developers to attend Debian conference and the Linux Foundation has a grant program to allow developers to attend events.
• Paid developers often maintain modules they are not paid to directly contribute to. A reason for this is that they continue to maintain modules in their spare time when their company tells them to work on other parts of the code.

Personally, I'm also wondering why there are some significant differences between GNOME and KDE. For example, about 67% of contributors where paid to work on GNOME whereas only 38% were paid to work on KDE. Why do some projects attract more commercial involvement whereas other projects continue to be mostly volunteer based? [Update: it was pointed out that I made a mistake with these numbers. In reality, 37% of GNOME developers are paid to work on GNOME or GNOME and other FOSS according to the PhD thesis. The number for KDE was correct (38%). So according to this PhD there is not a lot of difference in the percentage of paid developers between GNOME and KDE. My original question still stands though because there are many projects that don't attract much commercial involvement at all.]

(Originally published on FOSSBazaar)

The European Open Source Observatory and Repository (OSOR)

I attended the Open Nordic Conference in Norway in June, a conference that brought together people from Norway, Sweden, Finland and Denmark. Attending the conference allowed me to find out what's going on with FOSS in Northern Europe. What I found interesting is that there was a lot of talk about using FOSS in the public sector. A number of countries are working on repositories to exchange software, in particular for public administration.

One example is the Software Exchange (softwareborsen.dk), a project by the Danish National Software Knowledge Centre to promote the use of FOSS in Danish public administration. The Norwegian software exchange (delingsbazaren.no) plays a similar role in Norway.

It seems as if every country is working on their own software repository to share FOSS. As such, it's great to see that the European Commission is taking a step towards bringing everyone together by introducing the Open Source Observatory and Repository (OSOR) for European public administrations. The goal of OSOR is to provide a platform for the exchange of information, experiences and FOSS code for the use in public administrations.

OSOR will officially launch at the Open Source World Conference in Malaga in October. I've always thought that there is not enough cooperation and communication between European countries, so I have high hopes for OSOR.

(Originally published on FOSSBazaar)

OSI and License Proliferation

License proliferation has been a topic for discussion for quite a while now in the FOSS community and many would like to see the Open Source Initiative (OSI) fix this problem for good. In a license proliferation report, the OSI lists three problems that people generally see with license proliferation:

1. Too many different licenses makes it difficult for licensors to choose: it's difficult to choose a good license for a project because there are so many.
2. Some licenses do not play well together: some open source licenses do not inter-operate well with other open source licenses, making it hard to incorporate code from other projects.
3. Too many licenses makes it difficult to understand what you are agreeing to in a multi-license distribution: since a FOSS application typically contains code with different licenses and people use many applications which each contain one or several licenses, it's difficult to see what your obligations are.

License proliferation is a hard problem because nobody wants to give up their favourite license and because it can be extremely difficult to relicense a piece of code when there are multiple copyright holders, as is the case in the majority of community projects.

It's a particularly hard problem for the OSI because of two conflicting interests. One the one hand, the OSI approves licenses as open source based on the Open Source Definition (OSD). Therefore, it seems natural that a license that fulfils the OSD should be approved as open source. On the other hand, because of the problems of license proliferation, it's beneficial to keep the number of open source approved licenses low.

At the OSI meeting in Portland a few weeks ago, the Board decided to tackle this problem again and split licenses into two tiers. The specific wording has not been finalized yet, but "recommended" and "compliant" have been suggested. This would make it clear which open source licenses are "merely" OSD compliant whereas a limited number are recommended for use in projects.

The discussion about the two tiers has just started, so there are no results yet. But it's definitely an important discussion that needs to take place.

(Originally published on FOSSBazaar)

FLOSSInclude wants to foster FOSS in developing countries

The EU is sponsoring a new two year project called FLOSSInclude to explore the use of FOSS as a development tool. In particular, the aim of FLOSSInclude is to study what is needed to "increase the deployment, development and societal impact of FOSS in Africa, Asia and Latin America". The project starts with the premise that FOSS provides a number of benefits to developing countries, such as low cost, adaptability, and a free-of-charge high quality training environment.

The project will identify and analyze key problem areas and areas of blocked potential in the target regions. Furthermore, pilot studies will be conducted to ensure that FOSS solutions, tools and services can be cost-effective and practical for each environment. At the end of the project, FLOSSInclude intends to develop a roadmap for future EU development research cooperation in order to "ensure that the impact of FLOSSInclude will be sustained far beyond the duration of the project". I think it's great that there is a research project now with the focus on including developing countries in FOSS and I hope this project will be very successful.

(Originally published on FOSSBazaar)

Obstacles for making FOSS development truly global

Li Yang, who works for Freescale Semiconductor, gave a very interesting talk at linux.conf.au a few weeks ago about the obstacles of getting people from all around the world involved in FOSS projects. He started off by saying that he'd like FOSS to be really global, and not just global in the sense that developers from North America, Europe and Australia are involved.

He started by comparing Internet usage and FOSS involvement of different parts of the world. The US, Europe and Australia make up about 45% of Internet users while 55% come from other parts of the world. He also noted that Internet usage is growing particularly fast in Brazil, China, India and Russia. When you look at FOSS development, you see a different picture. He looked at the attendees of the Linux Kernel Summit 2007 and found that 51% were from the US, 32% from Europe, 9% from Australia and only 8% from other countries. He also presented some statistics from SourceForge that showed a similar picture: 36% of developers are from the US, 40% from Europe, 3% from Australia and 21% from other parts of the world. His conclusion was that it's important to get more people from Asia, Africa and other underrepresented regions involved.

His presentation followed with obstacles associated with the participation in an international community. Unsurprisingly, language is a big problem. Learning English can be hard for people from China and other countries whose native language is not part of the Indo-European family. While many educated people in China can actually read English at a basic level, written and spoken English is often poor because of lack of practice. This makes communication slow, misunderstandings are more common and it's difficult to express yourself clearly.

The problem is not just with language, though. Culture is also an important factor. For example, direct criticism is taken as an insult in China. This is a problem since the patch review process can be very direct. Furthermore, Li Yang argued that Chinese people are more effective in close-knit teams whereas the FOSS community prefers to form loosely-knit teams.

Time difference is another problem. For example, China has a 8-12 hour time difference to Europe and the US. This makes it hard to use real-time communication, like IRC. While e-mail works fairly well, communication is quite slow since each round of discussion takes a whole day. Finally, developers in China have less time for hobbies and so it's often hard to get more people involved. There are also some problems with net access. For example, sourceforge.net and freebsd.org used to be banned by the government and wikipedia.org is still banned.

Li Yang finished his presentation by sharing his experience with local communities. The idea is to establish a local community in a country with members who can talk to each other in their own language. A local community should also have some experts who are part of the international community. Those experts can then help other members with sending bug reports or patches to the international community for feedback. This way, it's ensured that the local community has at least some connections to the global community and hopefully over time members of the local community will get more experience interacting with the global community.

(Originally published on FOSSBazaar)

Models and tools for FOSS quality

There has been interest in quality models for FOSS for a long time. There are various concerns about FOSS and the quality thereof. Given that a lot of FOSS is produced by volunteers, how can we rely on the software? Is software developed in the public more secure, or can people use the source code to find exploits? It's important to have an objective assessment of the quality of a piece of software to address such questions. Furthermore, having good metrics allows users to choose between different software that offers comparable functionality. Given the large number of FOSS projects, this problem is of growing concern.

Software quality is a tough nut to crack. When you see and use a product, you will usually form a judgement as to its quality pretty quickly. However, if you try to develop rules for assessing the quality of a product you'll find that it's really hard. This is partly because there are so many different components that make up quality, and that different people put different emphasis on these components or see them in a different way. While quality has a subjective component, there are several objective components that can be measured.

There are number of researchers who are interested in developing tools and models that can be used for empirical studies of quality in FOSS. The EU has recognized the need for such models and tools and is funding not only one but several projects that study quality in FOSS:

• QUALity in Open Source Software (QUALOSS): QUALOSS will develop a high level methodology to benchmark the quality of FOSS in order to ease the strategic decision of integrating adequate FOSS components into software systems. The QUALOSS platform uses tools to analyze two types of data: source code and project-repository information. The goal is to estimate the evolvability and robustness of the evaluated software products.
• Software Quality Observatory for Open Source Software (SQO-OSS): This project is developing a comprehensive suite of software quality assessment tools. These tools will enable the objective analysis and benchmarking of FOSS. SQO-OSS aims to remove one of the key barriers to entry for FOSS by providing scientific proof of its quality.
• Qualification and Selection of Open Source Software (QSOS): QSOS is a method designed to qualify, select and compare free and open source software in an objective, traceable and argued way. It consists of four different steps.
• Quality Platform for Open Source Software (QualiPSo): QualiPSo is a huge project which focuses on a number of different areas. As part of their activities on trustworthy processes, they are interested in developing a Capability Maturity Model (CMM) like model for FOSS.

These projects are very ambitious but they certainly have the potential to make a great contribution. There is also quite a bit of overlap between these projects, which is why some of them have united and formed the Flossquality initiative (FLOSS stands for "free, libre and open source software"). These projects are relatively young, but I look forward to their results.

(Originally published on FOSSBazaar)

Driving forces of FOSS adoption and development

Matt Asay of Alfresco recently observed differences in the adoption of FOSS. He sees a lot of adoption in Europe by governments who support the ideals of FOSS whereas he claims that adoption in North America is mainly driven by enterprises "seeking to lower costs and maximize innovation". His comments remind me of a discussion I once had with someone a few years ago. We didn't talk so much about adoption, but rather about development of FOSS. Our conclusion was that the main driving forces behind FOSS are not the same in different parts of the world. Specifically, it seemed that FOSS development in North America was heavily driven by corporations, whereas FOSS development in Europe was mostly community driven. Finally, governments in Asia and other emerging markets, like Brazil, saw FOSS as a great opportunity to establish a healthy software development industry in their own countries and as a way to become more independent from the US.

Today, this picture may be different and clearly there are multiple driving forces in a region. The EU in particular has been pushing FOSS in recent times for public administration and they are funding a number of research projects related to FOSS, such as FLOSSMETRICS, SQO-OSS and QualiPSo (more on these later). This may explain why Matt Asay is seeing so much adoption of FOSS by governments in Europe. Nevertheless, in terms of development I'd still say that the community is the driving force in Europe. I find the differences between the FOSS community in Europe and in the US quite amazing. It seems to me that the FOSS community is much more tightly connected in Europe than in the US. In Europe, we have a lot of community events for FOSS (both for users and developers). FOSDEM is one of the largest FOSS events in Europe, but almost every country in Europe has their own event (or even several) related to Linux and FOSS. Many of them are organized by the community and entrance is often free of charge. Contrast this to the US, which has much fewer events and the most prominent one, OSCON, sets you back around $1000. I'm aware of OLS and SCALE, and have heard many good things about the LinuxFest Northwest and Ohio LinuxFest, but it's still not comparable to what you can find in Europe.

Some countries in Asia are very keen on participating in the FOSS community but I don't see many individual contributions from there (with the major exception of Japan, which has a very strong FOSS community). However, governments are providing incentives for companies to get involved. Unfortunately, there are many obstacles. For example, the open way in which most FOSS projects are performed may be in conflict to how some Asian cultures work. Also, FOSS development is often quite hostile (with heated discussions and arguments), which may be a problem to some. Finally, proficiency of English and access to broadband Internet connections are a problem in some Asian countries. Nevertheless, it's important to engage with developers in Asia and to help them contribute to and join our world-wide community.

In summary, I think there are important differences with regards to the adoption of FOSS and the way development communities work in different parts of the world. These differences will have an important impact on the governance of FOSS. Since FOSS is a world-wide phenomenon, we need to develop a better understanding of issues that various people face. I think that FOSSBazaar will be a great venue to hear from people all around the world and to learn what the obstacles are to wide adoption of FOSS in their countries.

(Originally published on FOSSBazaar)