Many people think of solid application which causes not too much trouble when
they talk about ​Free Software.
Most Free Software is given away for free, everyone can extend it as (s)he likes
(presuming the necessary knowlegde) and there is no marketing department which
urges for premature 'final' releases. Administrators often like that Free
Software does not require any license management (if you just use it) and
bug reports are openly shared because of the abundance of company politics which
may try to maintain a zero-defect illusion even if the product is buggy like hell.

But the article's head line is 'Free Software is no silver bullet for niche markets'
so you probably already expect that I will give you some counter-examples to the
cliches above.

Pipe dreams meet real live

So today's example is ​Lx-Office
(​Wikipedia, sorry no English version
available). Lx-Office is a web-based
​ERP and
​CRM system
written in Perl and PHP and distributed under the GNU General Public License.
It includes a module for financial accounting in companies.
The ERP/accounting module of Lx-Office originated in
​SQL-Ledger (​Wikipedia).
After the fork from SQL-Ledger in 2003, Lx-Office was modified to meet German
regulatory requirements.

In Germany, the majority of all tax advisors
(​approximately 80% according
to Financial Times Germany) uses software produced by a German cooperative named
​DATEV (​Wikipedia).
This software is really the heart of a tax advisor's services, different
versions support almost everything from financial accounting and tax calculation
to payroll accounting.

So you can imagine that for a serious accounting software, data exchange with
tax advisors is really a must-have. Though DATEV does only offer properietary
software (which only runs on MS Windows), they sell a
​SDK which contains the
complete specification of the KNE format ("Postversandformat"). With that format
you can share accounting information with your tax advisor (e.g. the routine
accounting is done in-house but the tax advisor should assemble the balance
sheet at the end of the year).

The KNE format is an 'old-style' binary file format with a long track record
(if you include the predecessor, the OBE format which was introduced in the late
'80s). When I wrote libkne, a pure Python library to create and parse
these binary KNE files, I tested my implementation against several real-world
implementations. However, when I used the DATEV export using Lx-Office's demo
server I was very surprised to see that the exported files where not valid
according to the specification!

Export bug known for several years

It turned out that the problem is caused by different date string formatting.
The export module ​DATEV.pm
transforms a string which is presumed to contain a date ('25.12.2008', which is
2008-12-25 in ISO notation) into the KNE binary date format ('251208' - yes, the
KNE format is not y2k-safe). As soon you use a different date format (like
'12/25/2008'), the export just puts in the date string '12/25/2008', ignoring
the size restrictions (6 bytes) and the format specification ('DDMMYY')
completely.

What really puzzled me was that this bug is known for 2 1/2 years and
nothing happened so far. In June 2006 there was a
​post in the user forum which
explained the problem and even spotted the bug in the source code. Only thirty
minutes later, another forum reader filed a
​bug report with
a reference to the post. Six months later, a developer requested more
information (which looks stupid to me, all necessary information was given) from
the submitter but no further action was taken until now (December 2008). That
means that the DATEV export of Lx-Office is non-functional for 2 1/2 years if
you don't use one specific date format!

Looking at the source

As always, we can have a look at the source to reveal the issue:

# Code taken from SL/DATEV.pm (r3482)# https://lx-office.linet-services.de/svn/trunk/unstable/SL/DATEV.pm# Licensed under the GPL v2+subdatetofour{$main::lxdebug->enter_sub();my($date,$six)=@_;($day,$month,$year)=split(/\./,$date);if($day=~ /^0/){$day=substr($day,1,1);}if(length($month)<2){$month="0".$month;}if(length($year)>2){$year=substr($year,-2,2);}if($six){$date=$day.$month.$year;}else{$date=$day.$month;}$main::lxdebug->leave_sub();return$date;}

So the datetofour function gets a date string $date and a boolean flag $six
and returns the KNE date string. The problem is that the function assumes a
certain date format in line 10 in the snippet (line 481 in original file as
of r3482): 'split(/\./, $date)' But this date formatting can be configured by the user so the
function should query the configuration for the format to use.

Conclusions

I presented you one example of a Free Software application which has a serious
known bug that was not fixed for more that 2 1/2 years (though it is probably
only a matter of one or two lines). The project itself is
​backed by two small companies and
the software is used by quite a lot of people (Sourceforge counted
4468 downloads for Lx-Office ERP beta1 between 2008-08-12 and 2008-12-25). The
project follows a traditional 'open source' development approach (public bug
tracker and source control repository, community support through web forums) and
uses a well-known license (GPL 2+). So this is clearly an example of a 'real'
Free Software project.

Nevertheless the project failed to fix a simple bug so that users can not use
functionality which is quite important in many enterprise use cases if you
consider the extensive German regulatory policies. Obviously this functionality
is not important enough for most users of Lx-Office. Probably (speculation!)
many of them are in the 'low budget' segment which does not regularly exchange
financial data with their tax advisors.

Admittedly financial accounting is really a niche use case (highly dependend on
the country you're operating in, laws and policies change on a regular basis)
so the user and developer number is quite small (compared to other software
like Linux, Mozilla Firefox or OpenOffice). But it still gives evidence to my
initial thesis that Free Software is not necessarily a solution for you.
While Free Software in very common use cases can excel their proprietary
competitors (e.g. Apache HTTP), you may find that you should evaluate Free
Software in niche markets very carefully.

Brief remark: 'Batteries included' is the right approach for class libraries

While I described what code caused the bug on a technical level, the real
(technical) problem for me is found below: In Perl 5 there is no built-in data
type to represent dates. So the Lx-Office developers had to fall back on using
strings to pass dates around. If Perl shipped some included module for date
representation and manipulation, probably the bug would have never occured
because things like date formatting would only influence the visual presentation.

So I think that on a class library level Python's approach of
​batteries included is the right one. A
decent(tm) programming language needs to ship modules for date manipulation
(even a less-than-optimal API like in Python is better than a completely
missing one). Just having
​add-on modules for
that is not sufficient because not all developers use them and it's hard to use
multiple independently developed third-party modules with each other because
they probably will use incompatible date representations...