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)

When the Debian installer starts, it will normally ask you what language you want to install in and gives you a really long list of languages to choose from. Unfortunately, that's not how it works when you install on a headless NAS device. The reason for this is that installations on NAS devices are done via SSH and the installer normally brings the network up after asking the user for their language. So we'd simply skip the language question and go with English.

When Timo Jyrinki recently mentioned that he couldn't install in Finnish, Frans Pop pointed out that localechooser has changed a lot since etch and that it should now be possible to have the language question after setting up the network. This turned out to be correct and I managed to choose a different language but the installer still showed everything in English. Frans reminded me that the installer drops all translations that are not necessary but unfortunately this happens too early in our case. He pointed me to a variable that determines whether translations will be dropped. So in lenny translations will not be dropped on NAS devices that have enough RAM and users will be asked when they connect to the installer via SSH what language they'd like to install in.

One thing that's annoying about the Debian installer on the NSLU2, as Joey Hess pointed out a few months ago when he reinstalled his NSLU2, is that you have to manually select some installer modules. The reason for this is that the NSLU2 only has 32 MB of RAM and thus Debian installer runs in lowmem mode in which less functionality is enabled by default. As a result of this, you have to select partman-auto, partman-ext3 and usb-storage-modules from a list of additional installer modules to load so the installer will recognize your USB disk, offer guided partitioning and format the disk with ext3.

When Joey submitted his installation report, Frans Pop suggested that we could put a list of installer modules we want to have installed automatically in /var/cache/anna/include. I finally got around to playing around with this yesterday and while this specific solution won't work on lowmem systems we can use anna-install to automatically queue installer modules for installation. Since anna-install works, I put some functionality into the installer today to automatically load required installer modules on the Linksys NSLU2 and on Cobalt machines.

This change is good for users because they don't have to select some modules during the installation. I'm a little bit worried that existing users of the installer on the NSLU2 will be confused when they don't see the modules in the list anymore, but I'll update the documentation accordingly.

I started testing GCC 4.4 ten days ago and the results are in. In total, I filed 28 new bugs and ran into 7 known issues. More than half of the bugs I filed have already been fixed and many of those that are still open have already received some attention (debugging, suggested patches). I sent a complete report to the GCC list, although I forgot to mention that I set optimization to -O3 to catch more problems.

I know that it's quite popular to complain about GCC, but I'd say that most impressions people have about the GCC community no longer hold true. The GCC community is very active these days, bugs tend to get a lot of attention and there are major infrastructure changes underway to improve the compiler.

To follow-up on my recent posting about oldsys-preseed: I uploaded a new version of netcfg yesterday that can be told via preseeding not to use a gateway. I also uploaded a new version of oldsys-preseed that will properly handle static IP configs without a netmask or gateway. Additionally, oldsys-preseed will now use DHCP when the static IP config is incomplete (i.e. when either the IP address or DNS are missing). This makes oldsys-preseed much more robust and will hopefully get rid of many problems users ran into with etch.

Since I'm spending the summer in Israel, I used the opportunity yesterday to visit the Marvell site in Yoqne'am where the majority of the NAS software engineering team is located. They first gave me a tour through the hardware labs which I found incredibly interesting. It's amazing what equipment those folks use to perform QA tests of new chips, how they can reverse engineer chips and even make some modifications to test their theories about hardware bugs. I found it really amazing and at the same time felt glad that changing things in software is so easy.

Later they showed me the software lab where they had an exhibition of various devices based on the Orion chip, including NAS devices, but also printers, wifi APs and game machines. They also told me some details of their product roadmap but unfortunately I cannot share that information. The only thing I can say is that we'll see a lot of new devices to which it would be cool to port Debian.

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)

I've been too busy to follow GCC development recently and haven't done any testing of development snapshots during the GCC 4.4 development phase so far. However, GCC 4.4 moved to stage 3 yesterday, the development stage dedicated to bug fixes and documentation. Given that GCC is now in stage 3 and that Debian unstable has fairly little churn because of the freeze, it's an ideal time to do some archive rebuilds.

I started archive rebuilds on amd64 and powerpc last night and added ia64 today. I also tried to build GCC on armel, alpha and sparc but there are compiler errors during bootstrap. mips builds fine but I haven't started any archive rebuilds.

I found and reported 9 compiler errors so far. Most of them have already received some attention and one of them has been fixed in the meantime. I'm not looking at build failures of packages at the moment since that's very time consuming and I'm not sure whether I'll find the time to report build failures later as GCC becomes more stable, but we'll see.

I finally found the time today to dig into oldsys-preseed and what I found wasn't pleasant. In fact, I may have solved the mystery why some people trying to install Debian on their NSLU2 cannot connect to the installer via SSH.

oldsys-preseed is used on certain NAS devices to read the network configuration from the original firmware and these values are used to bring up SSH in debian-installer. If you used DHCP in the original firmware to obtain an IP address, debian-installer will do the same. If you have a static IP config, debian-installer will use it. In theory, it's all pretty simple, but users often run into troubles when a static IP config is used (as is the case on the NSLU2). While you only need an IP address, netmask and gateway to bring up SSH (and then you could configure the rest, such as DNS and hostname), debian-installer expects everything at the same time. I've seen many cases where users couldn't connect to the installer because they forgot to configure their DNS in the original firmware or some other values they didn't think were important.

Anyway, right now oldsys-preseed will use a static configuration if the firmware is configured this way even if it's clear that netcfg won't like this configuration because of missing values. The IP address and DNS are always required, but the netmask and gateway can be figured out automatically. I wanted to add a sanity check that would choose DHCP in case the IP address or DNS were not specified.

While working on this sanity check, I noticed two things: First, the "empty" value oldsys-preseed preseeds when there's no netmask or gateway is not accepted by netcfg and leads to an error message (which the user cannot see because SSH is not up yet). I'm pretty sure I tested this scenario when I wrote oldsys-preseed but it clearly doesn't work today and I don't see how it could ever have worked. This is pretty significant because having an empty gateway is a valid configuration (if hopefully not too common). Second, it seems that it's impossible to create a preseed file that tells netcfg that no gateway should be used. If you preseed an empty value, netcfg will simple use .1 as the gateway.

I've fixed the first problem and proposed a patch to put in a special case to allow preseeding of no gateway. The sanity check that chooses DHCP when the network configuration is incomplete is also there now.

debian-installer is now using the 2.6.26 kernel (the version the kernel team wants to release lenny with) and 2.6.26 has moved to testing a few days ago. As such, it's a great time to test the daily installer images to make sure our installer for lenny is in a good state. There's still time to fix bugs in the installer, but we need your feedback.

Daily images can be obtained from the debian-installer web site which also contains instructions about how to submit installation reports. I'm particularly interested in reports about installations on ARM and MIPS. If you want to test debian-installer on these architectures, please read my messages on debian-arm and debian-mips.

Frans Pop reported recently that the initramfs did not fit in the flash of the QNAP TS-109 when you used LVM. We had problems with initramfs images that were too large before (on the NSLU2). By default, initramfs-tools uses the MODULES=most setting which puts all modules that might be of interest to booting a machine in the initramfs. This is a good idea on a PC where the hardware can change a lot, but it makes less sense on most NAS devices.

Frans has now changed debian-installer so the MODULES policy can be chosen during the installation. His change allowed architecture specific defaults, so I've changed ARM to use MODULES=dep. debian-installer will now create the file /etc/initramfs-tools/conf.d/driver-policy with a MODULES setting that will override that from /etc/initramfs-tools/initramfs.conf. On QNAP devices, I intend to only support MODULES=dep installations, so please change your configuration if you've installed Debian already. On the NSLU2, MODULES=most will of course continue to be supported.

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)

Someone asked me the other day what it would take to add Debian support for the D-Link DNS-323. Since we support a number of Orion based devices in debian-installer already, adding support for another device is typically fairly easy. I don't have a D-Link DNS-323 myself, but I looked around the useful DNS-323 wiki and this is what I came up. I'm sharing this list in the hope that other people are interested in working on DNS-323 support.

• The Orion kernel in Debian has support for the D-Link DNS-323 but it needs testing. Also, some patches, such as support for the fan speed chip, are not included in the mainline kernel yet.
• flash-kernel (which writes the kernel and ramdisk to flash) needs support for the DNS-323. I actually implemented this in the meantime but it's completely untested.
• oldsys-preseed reads the network configuration from your existing firmware and uses it to configure the network for debian-installer. This also needs support for the DNS-323.
• Some tools to generate proper firmware images need to be packaged for Debian.
• The debian-installer needs to generate a boot image for the DNS-323 (easy once the tools are packaged).
• Apparently the MAC address is not set automatically in u-boot and you have to run a tool called mac_read to set it. This is problematic because at the moment there's no code to set the MAC address in d-i and to make sure the newly installed system will automatically set the MAC address. This needs some work.

Otavio has updated kernel-wedge in SVN to 2.6.26, so I updated ARM and MIPS today. The udebs built after minor modifications and I can also build installer images after having fixed some bugs in the build process. I tested a 2.6.26 based image on the QNAP TS-409 (armel) as well as in QEMU (mipsel).

2.6.26 will bring major improvements on ARM. Orion support is much better and our 2.6.26 has a number of patches from Marvell that help with performance on Orion. Our 2.6.26 also has Riku Voipio's LED driver for Thecus N2100 which has been accepted for the 2.6.27 mainline kernel.

I haven't actually uploaded the udebs yet because I'm waiting for the go-ahead as well as for the new version of the 2.6.26 kernel package to build. But at least we're getting closer to having 2.6.26 as the kernel for lenny.

I've created a web site with information for running Debian on the HP mv2120. The HP mv2120 is a NAS device based on Marvell's Orion platform and has a 500 MHz ARM CPU, 128 MB RAM and two SATA slots.

All components needed to support Debian on the HP mv2120 have been integrated into Debian and Debian installer. However, a new release of the Debian installer is required so installations of Debian testing are actually possible.

Daily installer images are now available for the QNAP TS-109, TS-209 and TS-409. This means that complete installations of Debian testing are possible now.

You can consider the daily image as a beta release of RC1 of the debian-installer for Debian lenny. It should only be used by experienced users and only if you can make a serial console in case something goes wrong. As the name suggests, the daily images change on a daily basis and they install Debian testing which also changes on a daily basis (although testing should be fairly stable since we're close to the freeze of testing in preparation for the release of Debian lenny).

If you install Debian with these installer images, please send an installation report to debian-boot send an email to me so I can let you know in case there are any important news you should be aware of.

There is a web site now with complete installation instructions and other information about Debian on QNAP Turbo Station. If you have any questions or suggestions, please let me know.

I've just changed the behaviour of oldsys-preseed in the case when a static IP address is set in the configuration of the device that is the default setting from the vendor. In the past, oldsys-preseed would try to be smart in this case and do DHCP in the assumption that the users never configured the static IP address themselves and might not want to have that setting. However, Mike (mwester) convinced me that doing DHCP when the configuration clearly says to use a static IP is a bad idea. Apparently quite a few users got confused by the old behaviour of oldsys-preseed. The new behaviour exists as of version 2.0 of oldsys-preseed which will be in rc1 of debian-installer for lenny. This change affects the Linksys NSLU2 and Thecus N2100.

I managed to get my hands on a HP Media Vault mv2120, a nice ARM based NAS device, a few months ago with the intentions of porting Debian to it. Unfortunately, I have been really busy lately and most of my time was spent on adding support for the QNAP TS-109/TS-209 and TS-409 (which required a lot of generic work to get Marvell Orion support into Debian, a new SoC used in many NAS devices, including the QNAP TS-x09 and HP mv2120).

There were a number of things that had to be worked out before Debian would run on the mv2120. The good news is that Marc Singer and Eugene San have done all of the heavy lifting in the last few weeks in figuring out how the mv2120 works and that now it's just a matter of putting everything together for Debian to work.

Here are the issues that had to be worked out:

• Figure out how the rescue mode works and how to construct a rescue image that the device can boot: I knew that the mv2120 had a rescue mode that can be activated by keeping the the power and reset buttons pressed when starting that would request a rescue image via the network. This rescue mode can be used to start the Debian installer. Eugene San figured out how to construct a rescue image that the mv2120 would accept. Marc Singer has also written a tool, uphpmvault, to serve such rescue images from Linux.
• Figure out the best way to make one image that contains the kernel and ramdisk: the mv2120 only loads a kernel and no ramdisk, but a ramdisk is needed to start Debian. I discussed some really ugly hacks with Marc Singer to get the mv2120 to accept an image consisting of kernel and ramdisk but Marc wanted to try something else first. u-boot, the boot loader used on the mv2120, can accept something called a multipart image which can consist of a kernel and a ramdisk. When Eugene San heard that we were trying to load a multipart image, he went ahead and figured out how to construct an image that the mv2120 would boot.

Now that these two issues are resolved, I simply need to put everything together and add support for the mv2120 to a number of debian-installer components. We already have Orion kernel images in unstable that support the HP mv2120 (along with a number of other Orion based NAS devices) and the rest shouldn't take too long.

The Debian installer team has published the second beta release of the installer for lenny (what will become Debian 5.0). I repacked the image for the Linksys NSLU2 with the proprietary IXP4xx microcode so Ethernet will work.

The installer is now available in two flavours for the ARM architecture: arm is the old ARM port whereas armel is the new ARM port using the EABI which offers better support for floating point and other features. Both the arm and armel architectures will be supported for lenny but the old arm port will be dropped after the release of lenny. At this point, I therefore recommend that people use armel for new installations.

The beta 2 installer image for NSLU2 can be found on my site: armel image (recommended) and arm image.

We've had two serious bugs on the NSLU2 recently that both caused the system not too boot anymore. The first one was related to initramfs-tools. Kevin Price reported that after upgrading to initramfs-tools 0.92 the system would hang during boot waiting for the root filesystem. When I booted my NSLU2 and looked at the output, I noticed that no root device was set. When I mentioned this to maks, the maintainer of the initramfs-tools package, he immediately knew what was wrong and uploaded a fix. On the NSLU2, the boot loader doesn't pass a root device to the kernel so we set one in the initramfs itself. The code that loads this config variable is not used by many devices so nobody noticed that this got broken in 0.92 until the package moved to testing.

The second problem, reported on Saturday by Paul Collins and diagnosed today with some help from Kevin Price is also related to the strange way the NSLU2 boots. The NSLU2 has 6 MB available for the ramdisk but due to a bug in APEX (the second stage loader used on the NSLU2 by Debian) only 4 MB are actually used. When you write a ramdisk that is larger than 4 MB but smaller than 6 MB, flash-kernel will happily write the full image, but APEX will only tell the kernel about the first 4 MB. As it turns out, everything works fine on arm with 2.6.25, but on armel some additional SCSI modules are enabled that result in the ramdisk becoming too large. The short term solution is to disable these modules, but really APEX should finally be fixed (patches have been available for quite a while thanks to Gordon Farquharson). Fortunately 2.6.25 hasn't moved to testing yet and this problem only occurs on armel, so few people were impacted.

The nice thing about the NSLU2 is that you can write a new flash image via the network, so you can flash a good image in case your machine no longer boots. Nevertheless, we have to make sure such serious bugs don't occur in the future or that they are at least caught very early. Special thanks go to testers like Kevin Price.