Leading items

Episodes from the evolution of Fedora

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 Fedora land.

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 post-merge FAQ.

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 effort.

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 Zope.

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 packages.

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)

A think tank's view of free software

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 think tank" has now produced a 16-page report [PDF]. 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 surprising:

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 examined.

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 macros.

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.

Another problem:

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 the report.

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 freedom-related issue.

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)

The Grumpy Editor's next project

This article is part of the LWN Grumpy Editor series.

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 German companies.
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 the others.
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
Next page: Security>>