The Fedora 7 release, due on May 24 (though it appears
that schedule may slip a bit), marks
the beginning of a new era for
this distribution. As that release approaches, a number of issues have
come up which merit some attention. Here's a review of some events in
One of the core developments in Fedora 7, so to speak, is the merging of
the "Core" and "Extras" distributions. As of the next release, it is all
simply "Fedora." Given the nearness of the release, one would have thought
that this merger would have happened some time ago. As it happens, that
merger is just being finished up now. Much of the ground work was done
over the preceding months, leading up to the actual joining of the
repositories, source management subsystems, and build systems happening
now. As of this writing, the new source archives and build systems are up,
but the flow of packages into the Rawhide distribution has not resumed.
There has been a small amount of concern voiced by a few maintainers of
packages formerly found in Extras. In the good old days, they could post
an updated package at any time and have it go right into the repository. Now
that there is only one repository, the whole thing is currently frozen in
the run-up to the release. How to work in the new, unified environment is
still not entirely clear to all Extras package maintainers. Overall,
though, the number of glitches from the merger appears to be small - so
far. More information can be found in the draft
Red Hat's distributions have long been known for including software which
is not necessarily completely mature. Over the years, this company has
pushed in bleeding-edge technologies like ELF binaries, glibc2, SELinux,
and more; the end result has often been a combination of user pain and
accelerated development of the code in question. Fedora is in many ways
the true descendant of Red Hat Linux, and it continues the practice of
packaging very new technologies. Some users are beginning to wonder if
that practice has gone just a little too far this time, though.
The software in question is the Nouveau driver. This reverse-engineered
code is an eventual replacement for the binary-only drivers supplied by
NVIDIA. Someday, Nouveau will be the driver of choice for people with
NVIDIA hardware, but today is not that day. The Nouveau driver is still in
heavy development with a lot of problems to solve before it is ready for
production use. But Fedora 7 includes it anyway so that people with
an interest in trying out the new driver can do so.
Fedora 7 does not enable Nouveau for any system unless explicitly told to.
In theory, anybody who turns it on should know what they are getting into;
in practice, at least one user has already been
burned by trying Nouveau in a situation where it did not work. So some
voices have been heard to say that Nouveau has been included ahead of its
time and should be removed. Fedora developers still want to include it, though:
It is turned off by default just like the new Intel xorg driver in
FC6. That did help in users providing feedback when they turn it on
manually. It fits our mission of progressing Free software. This is
a important project. Anything that we can do to help is worth the
Others say that a project as important as Nouveau should not be subjected
to a tide of disappointed users who were lulled into trying the code before
its time by their distributor.
Chances are that Nouveau will remain. There is one remaining issue,
though: Nouveau is currently co-packaged with the stable "nv" driver that
people are actually expected to use. So Nouveau cannot be updated without
pushing out a new nv package. Given that Nouveau can be expected to evolve
considerably over the life of Fedora 7, impediments to the packaging
of updated versions seem like a bad idea. There is talk of splitting
Nouveau into its own package, which seems like a more than reasonable way
of solving this problem.
Finally, there is the issue of Python 2.5. That is the current version of
the language, and the version which will be shipped with Fedora 7.
The only problem is that the Zope content
management system, which serves as the base for Plone (and others), does
not work with this version of Python. So the current plan is for
Fedora 7 to ship without Zope or the packages which depend on
Back in the days when Red Hat Linux fit on a single CD, a core component
like Python would not have been updated until everything which depended on
it was ready for the change. In fact, Red Hat Linux was glacially slow to
move to Python 2 for just this reason. Fedora is a much larger
distribution which lacks the same sort of firm central control, so it has
become much harder to delay an update like this. And, unlike Debian,
Fedora is unwilling to delay a distribution release until all such issues
are worked out.
Some Zope users would like to see Fedora ship a "compat-python24" package
so that Zope will continue to work. There is some opposition to this idea, though:
As the python maintainer, I am *STRONGLY* opposed to a
compat-python24 package. Because at the end of the day, bug
reports will get filed against the wrong python package (because
end-users aren't going to know or case). Security problems are
still going to end up having to be dealt with and likely through me
because the CVE will originally get filed against python and no one
will think about compat-python.
Jeremy Katz, the maintainer quoted above, would like to see a rule allowing
a package maintainer to veto the addition of older "compat" packages so
that they could avoid having to deal with these sorts of problems.
He seems likely to win this particular argument, meaning that there will
probably be no Python 2.4 in Fedora 7. The implication is that
interested people will end up creating a set of Zope and Python 2.4
packages for Fedora 7 and hosting them on a third-party server
somewhere. It will be a small amount of extra hassle for affected users,
but that can be worked around. The issue of security support (crucially
important for a complex, network-facing system like Zope) should be
considered by anybody wanting to run this code, however.
There have been suggestions that the
maintainer of the Zope package should undertake the task of making it work
with the version of Python found in Fedora 7:
I believe very strongly that it _is_ the package maintainer's job
to work with upstream code to make it work with Fedora, and this
kind of thing _is_ a packaging issue.
There's a reason we have Fedora package maintainers instead of just
automatically pulling in upstream tarballs and building them with
rpmbuild -ta. It's because the role of the package maintainer is to
make the package a _part_ of Fedora -- that's what makes Fedora a
coherent distribution and not just a semi-random collection of
In this view, making Zope work with Fedora's version of Python is much like
making it work with SELinux or Fedora's init scripts setup - just part of
the job of making a package for the distribution. Once again, this role
was probably easier to carry out back in the single-disk days. In any
case, the current Fedora Zope maintainer is not going to port Zope to
Python 2.5 - that is apparently a rather large job.
This, too, will pass, and Fedora 8 may well be able to welcome Zope back
into the fold. In the mean time, though, the Fedora developers are trying
to figure out just how their distribution should react to issues like
this. As Fedora evolves and becomes more open to the community, it will
have to better define its policies and set them down so that developers
know what to expect.
Comments (20 posted)
Back in early March, a company called the Olliance Group held a gathering
of about 100 corporate manager types at a resort in California's wine
country. This "Open Source
" has now produced a 16-page
. It is, indeed, an interesting look at how a certain part
of the corporate world views free software - though, perhaps, not entirely
in the ways its authors intended.
When a self-appointed "think tank" gets together to talk about free
software, one is right to be cautious. When one of that event's top-level
sponsors is Microsoft, an extra degree of nervousness seems appropriate.
The other top-level sponsor, naturally, is Novell; the remainder of the
list is NEC, Unisys, Jasper Soft, OpenLogic, and SugarCRM. Not the most
community-oriented bunch one could have come up with.
LWN readers will be glad to know that "Overall, the CIOs unanimously
agreed that open source is viewed as a viable option in software
procurement decisions for their companies." Once they made that
admission, however, this group started to raise its complaints about open
source, many of which could have come from the 1990's. The first was lack
of support - evidently there still is not enough commercial support for
open source software. The report notes that "this is something the
open source industry will have to address to increase adoption by
companies." One would think that if there is truly a need for more
support these companies would see that need as a business opportunity
rather than an obligation.
Another problem, it seems, is interoperability:
CIOs desire greater interoperability built directly into open
source products. This is an area where proprietary solutions
maintain an advantage over open source, as it is far easier to
integrate and use a suite of proprietary applications that are
guaranteed to interoperate and that have common interfaces that
make it easier for end-users to learn and use the suite.
This is a surprising claim, given that free software developers generally
work toward interoperability with everything. The next claim is just as
Open source lacks compliance with many standards when compared with
proprietary solutions. These standards include universal standards
such as ISO, and industry-specific standards (financial industry
standards, health care industry standards, etc.). It was
acknowledged however, that open source offers some advantages in
the area of technology standards through its openness and
transparency and its ability to facilitate the creation of de facto
standards such as Eclipse and ODF.
The description of OpenDocument
as a "de facto standard" borders on the dishonest. The various reasons why
certain "industry standards" may not be supported as well as others are not
Think tank attendees bemoaned the fact that monetizing open source remains
challenging. Then, there is this problem:
Open source generally
depends on a corps of motivated volunteer developers to develop
features. Often, the features that developers are interested in
working on are different then features that customers are
requesting. For example, Openoffice customers want more Visual
Basic macros to ensure interoperability with Microsoft Office, but
OO developers have not been all that interested in building VB
The idea that a company whose business model depends on better VB support
could devote resources to the creation of that support is not mentioned
anywhere in the report.
Licensing is an issue which is mentioned several times in the report:
Open source licensing is a big source of confusion due to the
number of open source licenses, and a lack of understanding on how
licenses impact business, as well as how licenses interact with one
another. Some licenses require technology to be shared with the
community, other licenses require attribution, and numerous
licenses have different ways of dealing with software
patents. Furthermore, many licenses are incompatible. License
proliferation, confusion and incompatibility are barriers to the
continued growth and adoption of open source.
Clearly, we would be better off with the simplicity, compatibility, and
fairness found in proprietary software licenses. Beyond that:
Think Tank participants bemoaned the lack of a business-friendly
license that adequately addresses issues such as copyright,
patents, attribution and indemnification. While nobody was
suggesting "yet another license" as the solution, the
dissatisfaction by commercial vendors and customers with the
existing licenses was clear.
It would be most enlightening to see what this "business-friendly license"
would involve, but the attendees apparently ran out of time before they
could elaborate on that point.
The GPLv3 draft was also discussed, with a generally negative response.
These issues also point to the need for better governance of open
source contributions. Currently, projects have many different
standards governing code contributions - some communities
vet the code, some require contribution agreements to be signed and
others have no such requirements. The lack of standards and
governance on contributions raises concerns on the source and
legitimacy of code that is incorporated into projects.
This is a claim that needs to be backed up: despite the intense attention
which has been given to the provenance of code in a number of high-profile
projects, the number of real problems has been exceedingly small. If the
attendees of this think tank wish to claim that the code found in free
software projects is less likely to be legitimate than proprietary code,
they need to come up with some evidence to that effect. Sadly, space
constraints appear to have prevented this evidence from being included in
Other worries include a lack of open source developers - their numbers are
not keeping up with the growth of the industry. The fact that quite a few
developers are coming out of universities is considered to be a good thing,
but not without reservations: "However a concern was expressed that
due to the popularity of open source development at universities, graduates
may be lacking key skills such as sound architecture, defining customer
needs and product management." We also hear that open source "tends
to fragment easily," presenting problems for vendors. "Commercial
open source tends to be less fragmented, while 'pure' open source tends to
be more fragmented."
All is not bad, though. Open source offers "flexibility in procurement"
and "flexibility in deployment" where "companies can mix and match open
source software as they please" - despite all of those interoperability and
standards compliance problems we heard about earlier. Faster product
cycles are seen to be good, as are faster bug fixes. Plus:
In addition, there is "perceived" value in the ability to fix or
enhance open source code at the CIOs pleasure even if the vast
majority of user organizations do not .
This "perceived" value is as close as this report ever gets to any sort of
There is plenty more to look at in this report, but perhaps it is best to
finish with this observation:
Finally, OSS and proprietary models continue to converge.
Proprietary companies are taking elements of the open source model,
including faster development cycles, and free, downloadable trial
versions. OSS companies are taking elements of the proprietary
model, by offering support, updates and indemnification.
This report gives no space to the developers of all this software, beyond
complaining that both their numbers and their motivation to implement
Visual Basic macros are insufficient. There is no thought toward
maintaining healthy development and user communities, addressing
problematic legal issues, or contributing back to the community in any
way. These are people who see free software as a well from which they can
draw resources for their businesses, but that software is just a raw
material. They want to repackage and sell that material in as proprietary
a manner as possible.
If this group represents the future of the open source business community,
we could be in real trouble. A look at the list of sponsors given at the
top of this article is cause for comfort, however, as most of the companies
which have found real success with free software chose not to support this
event. So there is reason to believe that this "think tank" is not
representative of the wider business community, that, instead, it's a group
of leaders of businesses who wish they were doing better at
"monetizing" free software.
Comments (43 posted)
LWN readers need not be told that this publication is strongly biased in
favor of free software. So it should come as no surprise that we follow
the path we preach for others. The entire LWN operation is based on free
software, from our desktops to the web servers. We are a free software
success story, just like all those other companies using free software.
Chances are, however, that many of those companies share the one exception
which can be found here at LWN: our business accounting is done using a
well-known, proprietary, small business bookkeeping tool. It has all the
problems associated with such tools: it holds our company data in an
opaque, proprietary format, it does not interoperate with the rest of our
operation, it does not work as reliably as we would like, and it
occasionally forces an expensive upgrade to a new version for no clear
reason. Plus there's that proprietary operating system that the
bookkeeping application depends on.
Various attempts to replace this application have failed to take off. It's
hard to replace a functioning, important business subsystem, and, frankly,
free alternatives in the business accounting area have been slow to reach a
mature state. Your editor has recently become determined to change this
situation, though. Enough is enough.
A new accounting system will have to meet a number of needs. To begin
with, it must be able to import accounts and historical data from the
proprietary application. It should operate in a multi-user,
network-friendly manner. We need all of the usual accounting functions,
from double-entry bookkeeping to easy export of data to our accountant to
the creation of the occasional pie chart. And we would really like the
ability to integrate it with the LWN site code, since so much of our
commerce goes through that code.
There are numerous projects in this space. Your editor's list of
candidates at the moment includes (in no particular order):
- GnuCash: this application is mostly
aimed at personal finance (see this review from 2005), but
it does have some business features built into it as well.
- SQL-Ledger: a longstanding
web-based business accounting system. The code is GPL-licensed (this
week), but its owner (DWS Systems, Inc.) has not always distinguished
itself as a community-oriented operation.
- Ledger-SMB started as a fork
of SQL-Ledger. It has gained significant community support and
diverged significantly in a short period of time.
- Lx-Office is
another SQL-Ledger fork. It appears to be aimed at the needs of
- Compiere is an "integrated ERP
& CRM solution" which happens to have an accounting module built
into it. Like SQL-Ledger, Compiere is the product of a single company
which has not always been as open as its user community would like.
- Adempiere is a fork of
Compiere with a stronger community focus.
- TinyERP is billed as "the world's
most advanced open source ERP & CRM." It appears to have an
active community and a fair amount of documentation - as long as one
doesn't mind reading a little French here and there.
- Lazy8 is a general ledger package
written in Java. It appears to be less feature complete than many of
- OFBiz is an Apache "enterprise
automation software" project with an emphasis on supporting electronic
commerce. It is covered by the Apache license and is used as the base
for a number of other applications, both free and commercial. Free
applications based on OFBiz include Neogia, opentaps, and SourceTap.
- Project Open is a
web-based system with an emphasis on project management.
- ERP5 is "a full featured high end Open
Source / Libre Software solution published under GPL license and used
for mission critial ERP / CRM / MRP / SCM / PDM applications by
industrial organisations and government agencies." The current pace
of development on this project appears to be a little slow, though,
judging from the traffic on its mailing lists.
- Quasar is a formerly
proprietary package which was released under
the GPL at the beginning of 2005. Unfortunately, it appears that
not a whole lot has happened with this package since then.
- Several proprietary accounting packages for Linux exist as well. If
your editor determines that none of the free utilities is yet up to
the task, he will venture into this area. But one can hope that
entrusting a vital business function to another proprietary package
will not be necessary.
As one can see, there is no shortage of alternatives to look at; no doubt
LWN readers will know of a few which your editor missed. Working through
this list will be more than enough to keep an editor busy for some time;
since your editor has no particular passion for accounting, it's also
likely to make him somewhat grumpier than usual. It's clearly not a topic
which can be covered in a single article. So expect a series of
installments as your editor heads into the accounting jungle and tries to
figure out whether it's possible to run a business completely on free
software or not.
Comments (38 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Stability v. security fixes; New vulnerabilities in dovecot, elinks, gimp, moin, php, ...
- Kernel: More stuff for 2.6.22; The return of kevent?; The trouble with volatile.
- Distributions: How Debian packages a number; New releases: 64 Studio 1.3.0, EnGarde Secure Linux, Community Edition, Gentoo Linux 2007.0 plus new installer, Slax Tools; openSUSE survey results and 10.3 roadmap; Ubuntu Mobile and Embedded Edition
- Development: DOSEMU reaches version 1.4.0,
KDE Games plans, Qt Jambi GPLed, Sun GPLs Java SE development kit,
new versions of Samba clustering, mnoGoSearch, eSpeak, ADempiere ERP,
project-open, GnuPG, Linux Libertine, Cyphesis, Claws Mail, buzztard,
PHASEX, Boxtream, PHP, monotone.
- Press: The Tux500 campaign, OLPC and open source, Robert Love goes to Google, Linux
promotion in Japan, Ian Murdock's work at Sun, OpenBSD developer interview,
Sys Admin tips, Metasploit Framework review, Mono's Silverlight browser
plug-in, the upswing in Linux certification.
- Announcements: EFF legal primer on DVD decryption, OLPC Nepal volunteers,
Dell Joins Microsoft and Novell, Future of Mozilla Customer Support,
Sun Java announcements, report on commercial open-source, Netfilter Workshop
CFP, LinuxConf EU, O'Reilly Tools of Change for Publishing.