1. Looking Red Hat's recent press releases and web site lately, it reveals a new, stronger effort to shift focus further into the Enterprise and leaving Red Hat Linux to the hands of the community for the home/desktop market. This seems to leave a "hole" in the previous target of Red Hat at the "Corporate Desktop market". The new Red Hat Linux might sound like "power to the people", but to me sounds like an action that will have consequences (good & bad) in the quality, testing, development of what we got to know as your "corporate/desktop" product. Given the fact that Red Hat is the No1 Linux distribution on the planet, do you think that this new direction will slow down the Linux penetration to the desktop market?
Havoc Pennington: In my view it's a mistake to create an "Enterprise vs. Desktop" contrast; these are largely separate dimensions. There are enterprise desktops, enterprise servers, consumer desktops, and consumer servers. Quite possibly small business desktops and servers are another category in between.
I don't think we'll see a slowdown in Linux penetration into the desktop market. In fact I hope to see it speed up. Today there are many large software companies making investments in the Linux desktop.
2. How have things changed internally after the [further] focus shift to Enterprise? Is your desktop team still fully working on Gnome/GTK+/X/etc or have developers been pulled into other projects that are more in line with this new focus at Red Hat?
Havoc Pennington: We're still working on the desktop, more so than ever. (Including applications such as Mozilla, OpenOffice, and Evolution, not just the base environment.)
3. In the past (pre-SCO), Red Hat has admitted that was growing wary of patent issues that might arise in the future. Do you believe that desktop open source software written by many different individuals around the globe might be infringing on patents in some cases without the knowledge of these developers? At the end of the day, we have seen some patents that were issued so shortsightedly that many have said that writing software is almost impossible nowadays. What kind of solution for this issue might OSS software developers find, to ensure a future that is not striken by lawsuits left and right?
Havoc Pennington: As you know we've been more aggressive than other Linux vendors about removing potentially patented software from our distribution, specifically we took a lot of criticism for removing mp3 support.
One strategy for helping defend the open source community is to create defensive patents, as described here.
These licenses contain a "Termination for Patent Action" clause that's an interesting approach.
Political lobbying and education can't hurt either. These efforts become stronger as more people rely upon open source software.
4. What major new features are scheduled for GTK+ 2.4/2.6 and for the future in general? Once, you started a C++ wrapper for GTK+, but then the project got sterile. Do you believe that Gnome needs a C++ option, and if yes, do you believe that Gtkmm is a good one? Are there plans to sync GTK+ and Gtkmm more often and include it by default on Gnome releases?
Havoc Pennington: GTK+ 2.4 and 2.6 plans are pretty well described here.
One theme of these releases are to make GTK+ cover all the GUI functionality provided historically by libgnomeui. So there will be a single clear GUI API, rather than "plain GTK+" and "GNOME libs" - at that point being a "GNOME application" is really just a matter of whether you follow the GNOME user interface guidelines, rather than an issue of which libs you link to. This cuts down on bloat and developer confusion.
The main user-visible change in 2.4 is of course the new file selector.
The other user-visible effects of 2.4 and 2.6 will mostly be small tweaks and improved consistency between applications as they use the new standard widgets.
At some point we'll support Cairo which should allow for some nice themes. Cairo also covers printing.
Regarding C++, honestly I'm not qualified to comment on the current state of gtkmm, because I haven't evaluated it in some time. I do think a C++ option is important. There are two huge wins I'd consider even more important for your average one-off in-house simple GUI app though. 1) to use a language such as Python, Java, C#, Visual Basic, or whatever with automatic memory management, high-level library functions, and so forth; 2) use a user interface builder such as Glade. Both of those will save you more time than the difference between a C and a C++ UI toolkit.
- "Interview with Havoc, Page 1"
- "Interview with Havoc, Page 2"