FLOSS: The Software Hare that Beats the Proprietary Turtle?

Here’s another installment in my series of blog posts analyzing the European Commission’s free/libre and open source software (FLOSS) report. In prior posts, I’ve discussed how the report is a call to action for Europe’s policymakers, that FLOSS’s popularity is growing, and that many FLOSS developers live in the EU. In short, the report contains ambitious policy proposals to transform Europe’s ICT sector through industrial policies — I’ve called it the new Airbus project for the European economy. As I get further into the report, however, I’m becoming more skeptical of the report’s overall claim that open source software can rescue Europe’s software industry.

Here’s why – the authors go to the extreme to show FLOSS in a good light, without giving much emphasis to how FLOSS has so far achieved its growing and respected status. Why do I care? Well, I haven’t read much critique on the report, and it’s often fun to be the dissenting voice. And I’m sick of hearing that open source software will rescue the planet from the evils of commercial software and the capitalist system that spawned it. I know that TLF readers are savvy enough to stay away from such absolute statements, but many others in the blogosphere aren’t.

Moreover, at the public policy level, there’s a lot of confusion I’m anxious to clear up between open source the license and the community development model that will often characterize open source software. Finally, I’m becoming more interested in free and open source software on a personal level, which can be technically challenging and at times overwhelming.

So…here I’ll analyze the report’s claim in Section 7 that “FLOSSers Work Faster”.

To make the assertion that FLOSS development is faster than comparable proprietary software development, the authors compare survey and model data on the effort needed to generate the 221 million lines of code in the Debian FLOSS project. That bit of data is neither conclusive nor convincing, and the authors surely know that the license used for a piece of software says nothing about its development model or the speed of its programmers. Nonetheless, there are some good reasons to think that FLOSS programmers should work faster than developers of proprietary software.

First, FLOSS developers can freely borrow code from other FLOSS projects, saving time in design and coding. Most licenses governing FLOSS software permit its incorporation, modification and redistribution.

On the other hand, proprietary software developers also re-use chunks of code from previous efforts, especially with firms that crank-out multiple versions or a suite of related products. Ironically, The Chairman of the Association for Competitive Technology is a Belgian expat whose company, Sax.net, creates reusable components for proprietary software developers. So the notion of borrowing code probably doesn’t produce a substantial productivity advantage for FLOSS developers.

There’s a more compelling explanation for why FLOSS developers should work faster than their commercial software brethren. It starts with an observation that the important early FLOSS projects were imitations of existing products, or — as the authors put it — “FLOSS projects for which proprietary software with similar functionality exist.” [p51]

Although there are important exceptions (e.g. Apache, Sendmail, Perl), FLOSS developers have focused much of their effort on writing software that imitates features and functionality in existing commercial software products. For example:

Linux, the best-known FLOSS project and the operating system of over 70 million users, was conceived to re-create the widely-used Unix operating system.

OpenOffice, the productivity suite that has been downloaded by over 31 million users, admittedly imitates the interface and functionality of Microsoft Office, and boasts compatibility with all Microsoft file formats.

MySQL is a FLOSS database engine that was designed to emulate commercial database software from Microsoft, Oracle, and IBM. MySQL now has an installed base of five million systems, the largest of any database engine. Another open source vendor, RedHat, offers a FLOSS add-on product to give MySQL a user interface that imitates Microsoft’s Enterprise Manager for its SQL Server database.

Samba imitates the functionality of Windows servers for use with Linux and Unix servers.

In an example that goes beyond imitating applications, the Mono development platform mimics the development framework of Microsoft’s”.NET”.

In projects like those listed above, FLOSS programmers should work faster when they are imitating the workflow and features of software that someone else has already developed. There’s just no need to burn all those man-hours in use-case analysis and screen design when developers decide to create a FLOSS equivalent of, say, Microsoft Word.

With Imitation Comes Reward—with less Risk

Second, many FLOSS projects avoid important risks, meaning less time is spent on market tests, dead-ends, and do-overs. By imitating software that’s already in use, a FLOSS developer instantly escapes two critical risks that keep ordinary software designers up at night:

There is less risk that an imitative software development effort will fail because of limitations in technology, since it’s already been demonstrated that the software can be developed and can operate with acceptable performance characteristics.

There is less risk that imitative software, once created, will not find acceptance by users. The original software that’s being imitated has already proven user acceptance, often after spending significant sums on marketing and user education.

If a proven piece of software has already met the test of customer acceptance, there’s no need to spend months doing user trials and beta tests. Just test the FLOSS product side-by-side against the original. If the FLOSS product is a close copy, you’re good-to-go.

Finally, the authors of the FLOSS report claim less need for centralized coordination and management [p.53-54]. That seems credible when you consider that individual programmers can easily work alone, without the help of designers or system analysts, when they set out to imitate individual components of an existing product.

But after any software is shipped and in wide use, management and coordination become relatively more important than programming. Managing the integration, testing, and distribution of bug fixes, enhancements, and new versions is an ongoing ordeal. It may take fifteen minutes to code a bug fix, but fifteen days of effort to test and distribute the fix to users. Even Linus Torvalds, the chief coder behind the widely-used Linux operating system, now spends most of his time managing relatively small changes to the kernel.

Is Faster Better? Sure, Sometimes.

Even if the data don’t support their conclusion, the authors desperately want to believe that FLOSS developers are more productive than their commercial counterparts. And given that so much of the early FLOSS development has been imitations of existing software, you’d expect FLOSSers to be faster at cranking out the code.

SHARE: 12 comments