Leading items

Large educational Linux deployment for Brazil

Numbers like 52 million are attention grabbers, especially when they refer to students getting access to Linux. That's the number of Brazilian public school students who will have access to Linux-based educational computers in some 53,000 labs spread throughout the country. As reported on Mauricio Piacentini's weblog, the Brazilian government already has 17,000 of the labs up and running and plan to be fully rolled out by the end of 2009.

The project, called ProInfo, is run by the Ministry of Education (MEC) for Brazil. Piacentini heard about it at the recent Fórum Internacional Software Livre (FISL) conference, which is held annually in Porto Alegre, Brazil. He noted that the project is not only providing computers and infrastructure, but also a "Linux Educacional" distribution with free educational and entertainment software along with other "open content".

The distribution is Debian-based using KDE 3.5 as its desktop. Packages from the KDE Education Project (KDE-Edu) and KDE Games Center (KDEGames) were included. The project customized the interface, adding a quick navigation bar at the top (seen at left). This is the second version of the distribution incorporating feedback from installations of the previous version. The distribution ISOs, open content, and some documentation (all in Portuguese) can be found at the MEC ProInfo website.

There are various different lab configurations that ProInfo has devised that depend on the nature of the location of the school. Urban labs have equipment for up to fifteen students whereas rural installations have power-friendly hardware that can support up to five users. There is also a configuration targeted at schools for people with special needs that has a large display and accessibility tools added to the distribution. ProInfo also has a project that sounds much like OLPC, except in Portuguese: Um Computador por Aluno ("One computer per student") that plans to bring 150,000 laptops (possibly Intel Classmate PCs) to students over the next year or so.

Some have quibbled about the number of students estimated, but even if it is overestimated by a factor of two or three—which seems unlikely—it is still an enormous project that will impact a huge number of students. Free software is perfect for these kinds of projects, because it can reduce the hardware requirements significantly, eliminate licensing nightmares, and provide a look "under the hood" for students who are interested. Computer skills are largely portable if some of those students end up using other operating systems in the future, but because they are using free software now, any documents, pictures, music, and other data files will be able to move with them.

Folks from the KDE project are justifiably proud of this deployment. It uses KDE 3.5, but plans are afoot to work with MEC to explore using KDE4 down the road according to KDE hackers Piacentini and Aaron Seigo. Many have been concerned about the future of KDE 3.5, but the project has always maintained that it will be around for a long time. As Seigo says:

Proponents of the other desktops or distributions should be cheering this deployment as well. There will probably be lots of lessons learned that can apply to other projects in Brazil or elsewhere that standardize on a different set of software components. This is an exciting project for the free software community. But even more importantly, it is great to see so many of these tools become available to those who have not yet been exposed to them.

Comments (4 posted)

Sun and corporate open source

Over the last couple of weeks there has been an interesting set of articles posted on various weblogs on how Sun is managing its open source projects. As more companies try to get involved with free software, they may find things to learn from this discussion. So here are a few thoughts on corporate open source.

It all started with a posting by Ted Ts'o which stated:

The posting drew responses from Dave Neary and Alvaro Lopez Ortega, among others; both the original messages and the responses to it are worth reading in their entirety. In summary, the responses say that (1) Sun really is trying to be a good open source player, and (2) Sun has done as well as could be expected, that the creation of true open source communities is hard.

The first part can only be true. Sun has been the source of a great deal of free software, including packages like OpenOffice.org which are found in almost every Linux distribution. This company has released its core operating system as open source, and it is making noises about, finally, making Java truly open at all levels. There are few companies which have contributed code at this level, and that should be recognized. Beyond any doubt, Sun is contributing to this community.

What people question, though, is Sun's interest in creating real communities around its open source projects. These projects are notoriously hard to participate in and contribute to. As Ted points out, OpenSolaris currently gets less than one patch per day from outside the company, the project's governing board is made up entirely of Sun employees, and its (non-distributed) revision control system lives inside the Sun firewall. External OpenSolaris developers have known to quit with messages like:

OpenOffice.org, too, remains hard to work with; thus the many discouraged comments on the ooo-build wiki from developers who want to get things done:

The key to what is going on here can be found in many places, including in Alvaro's posting:

The real issue is control; Sun does not want to relinquish control over how its projects evolve. This is not a particularly uncommon situation with corporate-controlled projects; these projects will always be subject to the controlling company's agenda. Thus, no developer is likely to be successful in projects like:

• Adding features to MySQL which provide the functionality which is otherwise being reserved for the "enterprise" offerings.

• Adding packages to Fedora which make Red Hat's legal department nervous.

• Adding features to projects owned by the Free Software Foundation which, in the FSF's opinion, are not consistent with its goals; support for loading Emacs modules from an external repository is one example.

• Making any changes to Firefox which could threaten Mozilla Corporation's revenue stream from Google.

Companies which control open source projects in this way are generally acting within their rights; they may even be acting in their own best interests. The software is still open source. But the retention of this sort of control will have an effect on the community which builds around the software. In many cases, it can have the effect of preventing the creation of that community in the first place.

And that, too, may be what the company had in mind. There are a number of company-controlled open source projects which, by all appearances, are mostly for show and bragging rights. The company does not really seem to have much interest in developing a significant external community. In cases like this, if the software on offer is valuable enough, the result will often be a more community-oriented fork. Projects like ADempiere, LedgerSMB, and Cinelerra CV result from this kind of frustration.

Opinions clearly differ on whether Sun is truly uninterested in the creation of outside development communities for its projects, or whether it simply is having a hard time letting go. If the latter is the case, then Sun might be well advised to follow Dave Neary's suggestion and create a separate, non-profit foundation for the development of OpenOffice.org. Sun's apologists are right when they say that turning a large blob of proprietary code into free software is a hard thing to do. But it's harder if you don't give the community the power to help; in the case of OpenOffice.org, there would appear to be enough of an interested community to make a real go at it. This might be Sun's best chance to show that it can create real development communities around its software.

Comments (16 posted)

On the conviction of Hans Reiser

On April 28, a California jury found Hans Reiser guilty of first-degree murder. There has been a lot of speculation in the press, both before and after the conviction, on what the loss of Mr. Reiser will mean for the Linux community. Much of that speculation, it seems, lacks an understanding of what Mr. Reiser's role in the community really was. Your editor will take no position on whether his conviction was correct or just. But there are things to be said about what this conviction will mean.

Hans Reiser was, of course, the designer (and, to an extent, implementer) of the reiserfs filesystem. When it was merged, reiserfs had the distinction of being the first journaling filesystem for Linux which was intended for general use; it also offered good performance in some situations, especially those involving lots of small files. Reiserfs saw a significant amount of use and was adopted by a handful of distributors. There are, doubtless, quite a few reiserfs deployments still operating out there.

Mr. Reiser's role in reiserfs development and maintenance ended some years ago, though. He stopped work on it when reiser4 development started, and even opposed the incorporation of improvements done by others. Reiserfs continues to be maintained independently of its creator, though there is not much interest in adding features to it at this point. Reiserfs is nearing the end of its run, and nothing which happened this week has changed that situation in any way.

There is more concern about what will happen with Reiser4, Mr. Reiser's next generation filesystem. Many reports have suggested that current events spell the end for this project, but it is worth taking a look at the longer history. Reiser4 is not exactly new; it was first posted in 2002. Mr. Reiser made an unsuccessful effort to get it merged for the 2.6.0 kernel, and frequently thereafter. He blamed commercial interests and politics for his failure in this regard, but the real situation is more straightforward than that.

Reiser4 tried to do a number of things very differently from other filesystems. It included some very non-POSIX semantics which raised red flags within the development community. There was a multipurpose reiser4() system call which implemented a wide range of features and included an in-kernel interpreter for a special language. There was a low-level plugin mechanism which raised concerns (not all justified) about varying on-disk formats and proprietary formats. Reiser4 did many things at the filesystem level that others thought should be done at the virtual filesystem level instead. The "files as directories" feature, beyond striking people as strange, opened up a wide range of trivial deadlock scenarios.

In summary, this code was nowhere near ready for inclusion into the mainline kernel. Kernel development projects which are done in isolation often encounter this kind of surprise when they are finally posted to the development community.

Over the next few years work on reiser4 continued. Many of the problems were solved by simply removing most of the features which made reiser4 unique, turning it into just another filesystem. Once you have just another filesystem, attention will turn to performance; in this case, many people found that they got benchmark results which differed from those posted by Mr. Reiser. Community interest in this filesystem fell over time, and the development rate fell as well. There was still work happening to prepare reiser4 for the mainline kernel when Mr. Reiser was arrested, but it was moving slowly.

Perhaps the biggest obstacle to the inclusion of reiser4, though, was the confrontational approach taken toward the rest of the community. When developers pointed out problems with reiser4, Mr. Reiser had a tendency to question their motives rather than pay attention to what they were saying. His interactions with the community were characterized by statements like:

A number of developers reached a point where they simply chose not to engage with him any more. By rejecting the development community, Mr. Reiser remained forever an outsider to it.

And that is why the practical effect of Mr. Reiser's conviction on the community will be relatively small, at least in the short term. As brilliant as he is, his effectiveness was limited by his disregard for the rest of the community and his certainty of always being right. He could have accomplished much more with a different approach.

That said, his loss is unfortunate. He did prove able, over a number of years, to raise funds for Linux filesystem work, and the community benefited from that work. Some of the reiser4 developers are still interested in working on that code, and they still submit patches. But now nobody is paying them to do that work, which puts the whole enterprise in danger. There are limits to how long reiser4 development can be carried forward as a labor of love.

The biggest loss, though, is elsewhere. More than anybody else, Mr. Reiser put a lot of thought into what our systems should look like in the future. He saw capable filesystems as the way to make our systems far more powerful than they are now. In a world where the filesystem was the only namespace of any significance on the system, all objects would be equal and the number of potential connections between them would explode. His long-term goal was not (just) better benchmarks; it was to create a filesystem which could serve as this all-encompassing namespace. It was a radical idea, and, perhaps, impractical. But our future comes from ideas like that.

After a few relatively quiet years, there is now a flurry of activity around Linux filesystems. The challenges in this area are large, but we have many highly capable developers working on the problem and there can be no real doubt that Linux filesystems will continue to be among the best available anywhere. But that development community has lost a voice which, for all its faults, had some unique and innovative things to say, and we are all poorer for it.

Comments (33 posted)