Some people have characterized this as “Red Hat vs. Novell.”  This is the wrong way to frame this.   True, Dave at Novell is the one who is largely responsible for the XGL work and the X hackers at Red Hat are some of the primary authors of the aiglx work.  However, there’s been a huge number of external contributions to the aiglx work from outside of Red Hat and one of the primary components of aiglx (the pixmap to texture extension) actually comes from the XGL!  It’s just where it’s integrated that’s important.  At worst, it’s a competition, at best, it’s inadvertent teamwork.

The irony here is that what we’ve done with the aiglx work means that we run on a lot of the open source 3d drivers, but we don’t run on the NVidia binary driver.  But NVidia says that they will be adding support for the extension in their next major driver release, which means that the aiglx code will run on a pretty wide variety of cards under Linux.  (I don’t know about the ATI folks – they have been mum on the subject.)

The important thing to realize about aiglx is that it’s a method to incrementally improve the desktop.  If your driver supports it, you turn it on.  If you don’t it still works.  And it turns out that building a window manager takes years of work.  Sure, you can get one that’s working properly in a couple of months but you spend years adding support for all the old strange legacy clients that are out there and adding enough features to make it usable for a wide variety of users.  Simply put, it’s easier to add compositing manager capabilities to a working window manager than it is to turn a compositing manager into a working window manager.  What I’m really hoping will happen is that we can take all of the really well-polished features that are found in compiz and get them into metacity.   Because that’s where the real value is in compiz – not the window management capabilities, but the great 3D effects it has.  It would be great if we could get the best of both worlds and deliver a unified solution.

o Building an emulator so that people can have a playpen for testing and feel some of the experience

o Building tools to generate system images from existing Fedora packages.

We haven’t been focusing that much on the base desktop experience, instead we’ve been largely focused on getting some of the base tools in place so that we can build a stable, maintainable distribution. So when you fire this thing up it’s going to look funny, but you have to understand that it’s just a test bed. We’ll be focusing on base look and feel for the unique properties of the OLPC display in upcoming releases, and it’s something we’re hoping to have some participation from people in the community.

Over the next couple of weeks we’ll be launching a site for collaboration on the OLPC base software as well as tools for people to build their own images and help out with the project. There’s a huge amount of work to do on the base system, including fixing power management, driving the best possible performance out of what is a small system and fixing the huge number of memory problems that exist. Red Hat will be making the investments in tools to enable people to participate in fixing those problems and we should be able to see tangible results. We’re looking forward to the challenge.

The link to the emulator and instructions are available on Daniel Berrange’s people page. A couple of technical notes: this was done on FC4, and we haven’t tested it widely on other systems. I had to rebuild a bunch of these packages on my FC5t3 machine and make some minor changes to the spec files. The other two things I had to do were to

1. make sure to restart dbus to get the services recognized properly and

2. make sure that when I pointed the simulator to the disk image (the olpc-simulator create command) I had to make sure I used the full path to the disk image, otherwise the olpc-simulator start would just silently exit. Other people I talked to stumbled over these issues as well, so I figured I would pass them along.

Anyway, keep an eye on this space for more information. I’ll post as we make more progress.

Of course, on the flip side these early morning hours before the crash comes are hella productive.

<tony> it was always one little thing on the PDP-8, too

Linux Expo 1997

LinuxAsia 2006

I’ve been in India for a few days now, battling jet lag and having some very interesting meetings with people in government and private industry. The meetings I’ve been having all seem to have a running theme: how do we take all of the incredible talent that India has to offer and channel it into open source? If nothing else, the sheer number of people who are involved in the IT industry in India should mean that they should be leaders in the open source community, right? Well, that doesn’t seem to be the case. I think that most people who are in the open source world would tell you that compared to the number of people in the IT industry in India that the number of contributors in open source that are Indian is disproportionally low. So the question has been: why?

Onto another seemingly unrelated topic: programmers in the US. In the US technologists, programmers and the like are actually looked down on. Look at the words used to describe them: Geek. Nerd. Dork. Socially inept. Never gets girls. Etc. I would say that for the people who do get involved in the technology industry in the US often do so because they love it, and they are good at it. They are drawn to it because they have a passion for it.

Back to India for a second. Another constant theme in my meetings this week has been descriptions of people who are in IT schools in India. For students who are in schools to which we suggest that they get involved in open source software in India often ask “how will doing work in open source software help me get a job?” Very often they will do that task, submit a patch, fix a problem, and then vanish. There’s little ownership of that code, which is a basic tenant of working in open source. I believe that this is because the primary motivation in a lot of IT work in India is not love of technology, but because work in IT is a clear method for upward social mobility. Now, there’s nothing wrong with that, but it means that the incentives for working in an open source community aren’t there.

So back to my original question: assuming that open source software is a side effect of technology-loving people who want to work together, how do we turn this into a strategy for building open source leaders in India? The current methods include trying to get early students involved in projects by breaking tasks down into pieces that they can easily digest. But I suspect that this doesn’t take into effect the right motives that create leaders in open source. I think instead of taking the approach of trying to get as many people involved as possible, and hoping that open source benefits from them, we instead take the approach of building a program that selects those people who are involved because they clearly love technology and want to work together. A mentorship program that identifies people with passion as its focus would probably draw out the right people who want to work in open source and hopefully turn them into leaders as they move through school.

I know that these guys exist in India. My conversations with Atul Chitnis, RKVS Raman, and various other folks here in India bear this out. But I think that everyone gets quickly bogged down in the numbers of people instead of trying to target those folks who do this for the love and the passion of technology. Those are the people we need to find in India, because they are the future leaders in open source. The question should not be about “how many” so much as “who.”