Barriers to Entry and FOSS

Next term, I will be a teaching assistant for the imperative programming course at my university. This second-year course will require students to learn C programming on (Lin|U)nix, and one of their first tasks will be to set up an appropriate programming environment. On the course website, I therefore added a link to VirtualBox Linux images which the students can download. I assumed that they will be able to figure out themselves which Linux to chose and what software they need to install in order to solve the course exercises.

A bit of background: A couple of years ago, I was in China and Thailand doing research for my master thesis in Asian studies on Asian participation in Free and Open Source Software (FOSS). And one of my conclusions, amongst others, to the question why Chinese and Thais have difficulties participating in FOSS was the barriers to entry.

While preparing the imperative programming course, I suddenly realised that I was increasing the barriers to entry for my students. Since I had to learn how to set up a Linux system by myself, I just assumed that the students would have to learn it the hard way too. Additionally, when I first started to use Linux, I only had a dial-up internet connection, and finding information was much harder than today.

I started out by thinking what the students would need to do: Searching the internet to compare different Linux distributions, downloading the image, setting up VirtualBox, importing the image, setting the proper parameters for the virtual machine, running the virtual machine, searching the website where they downloaded the image for the user credentials, logging in. And then? Choosing an editor or IDE, finding out how to use the packaging system to install it, setting up sudo, opening a terminal and trying to run ‘gcc’, just to find out that it’s not installed yet, and so on. Students who have no experience with any of that are likely to spend a few days, only to figure things out, and before they get to the actual course exercises.

Conclusion is: I decided to prepare a virtual machine for the students, all set up with editor and the programming tools they will need throughout the course. It’s not the primary goal of the course to get them to set up an environment, the course is about learning to program in C and about how Linux works with threads, processes, and stuff.

Now how is this related to FOSS? Well, anyone who tries to get involved with FOSS, has to do a huge amount of effort just to get the trunk version of the software up and running. I recently started working on multiple mouse pointer support in webkit. I got, like everyone who tries to compile software, lost in the land of dependencies, configurations, compile errors , inadequate documentation, and unhelpful mailing lists and irc channels. Additionally, I was recently asked to deploy a version of my adapted webkit browser for Ubuntu. And what I experienced was even worse than on my Linux distro. Most of the required versions of the dependencies weren’t available in the Ubuntu packaging system (yes, I also checked the testing repositories) and I ended up compiling many of the dependencies myself. I am quite experienced when it comes to compiling things, but despite everything (add a couple of version conflicts, and some weird compile errors), it took me two full days to get my browser running on Ubuntu.

The barriers to entry for most FOSS projects is extremely high. Getting the code up and running is definitely far from easy. Recently, FOSS is trying to get more and more people, and non-coders, involved for testing, usability, bug triaging, design, and other community tasks. However, how will these non-coder people be able to run the required version of the software which is still a development version and therefore needs to be compiled? IMHO, the FOSS communities have to start thinking about lowering the barriers.

I wrote a blog post about a similar topic a few years ago. It’s available here.

Advertisement

---