Interviewee: Paul Cooper

In this interview we talk with Paul. In specific, we talk about:

• Getting started with the GNOME project
• Devices targeted by GNOME Mobile
• Differences between GNOME and GNOME Mobile
• Establishing a design approach for meeting the needs of users and devices
• The potential for virtualization on mobile devices
• The relationship between GNOME and providing kernel and hardware support

Sean Campbell: Paul, tell us a bit about your background, your relationship to GNOME, and how you got involved.

Paul Cooper: I’ve been working in GNOME and open source IT for a bit more than 10 years now.

I guess it started as a career when I was working as a systems and database administrator in the Mathematical Institute at Warwick University. We used Linux and open source quite heavily in our infrastructure. We also had a department head who liked to make promises but didn’t always like to assign budget to them. So, sometimes, we had to make things happen with little or no budget, which led us to use open source software quite heavily.

I found out about GNOME purely as an interested user; it looked like it would make my life using the computer more enjoyable and easier. When we rolled out a new lab right around the time that GNOME 1.0 was coming out, we decided to use GNOME.

Putting that lab together, creating user accounts, setting up a default look and feel in terms of how the panel and applets were loaded, and various other aspects of administration was my first real involvement with GNOME.

On the basis of that experience, I wrote the first system administrators’ guide to GNOME, which I hope is no longer in any Google cache, Wayback Machine, or the like. [laughs]

A lot of other, much smarter folks have rewritten all of that documentation, and obviously, the technology has changed completely since those days.

Beyond that, I wrote and edited little bits of documentation here and there, but I was really more of a hanger-on to the project at that point–someone who was there evangelizing and tracking. I was talking to people about it, helping in the local Linux user groups to submit bug reports, and that kind of stuff.

I was not heavily involved in the project until almost 10 years later, when a bunch of us here in the UK decided to put together a bid to host the annual GNOME conference, which is called GUADEC.

The conference travels much like the Olympics, and every year people bid to host it. It was probably about three years ago now that a bunch of us, primarily myself and a now-colleague called Thomas Word, decided to put together a bid to host that conference.

Thomas and I had met while doing various trade shows, where we put together a GNOME stand to help get feedback from people who were using it and to show new people about GNOME. Somehow, our bid to host GUADEC in the UK was successful, and we hosted GUADEC in Birmingham last year, 2007.

Those are my community involvements with GNOME. Quite separate from all of that, I started work at a company called OpenedHand. We help companies build amazing devices where they sell software primarily based on the GNOME Mobile project.

I helped with business development and just generally building the company, which has been acquired by Intel. Now, we’re working on the Moblin project which, again, is based on GNOME.

Scott Swigart: You alluded to the fact that GNOME is particularly well suited to mobile devices.

Paul: The GNOME Mobile project is really a subset of the GNOME Desktop technology, with the addition of some other pieces that are ideally suited to mobile devices.

When we talk about mobile, we’re not necessarily talking about mobile phone handsets, although it could well be used for that. We mean a much broader range of consumer electronics and embedded devices–really, anything that has a UI.

Scott: When people think of mobile devices, some people immediately think about netbooks, and some people think of handsets. From the perspective of GNOME Mobile, what falls under the umbrella of mobile?

Paul: Netbooks are at the large end of the spectrum, and the OLPC devices are also built on GNOME Mobile technology. Then you have things like the iRex eReaders and some of the Garmin GPS devices, which are also built on GNOME Mobile stuff and Linux.

Then there are so-called MID devices like the Nokia N810 and similar Atom-based devices.

Another thing we worked on was the Vernier LabQuest, which is an educational device for data capture and analysis. They have a catalogue of something like sixty or seventy different types of sensors for things like wind speed, temperature, weight, acidity, water flow, and others.

Then at the other end of size and power are mobile phone handsets, where OpenMoko, LiMO, Purple Labs, and Azingo are using subsets of the GNOME Mobile stack.

There’s really a very broad span of devices.

Scott: What are some of the fundamental differences between GNOME Mobile and the parent GNOME project?

Paul: We strip out a lot of the old deprecated stuff that still needs to hang around on the desktop for backward compatibility, and there are also mobile-specific components like matchbox, a window manager that’s highly tuned for mobile integrated devices. But the idea is that we use, and optimize, the mainline codebase as used in the Desktop, in the same way you have the same core Linux kernel from a phone up to a huge supercomputer.

Scott: How does the decision making process go around that? For example, one project might choose Empathy as their IM client, while another one will choose Pidgin. Someone also has to choose to make one particular change to the user interface over a different one.

Is there a distinct decision-making process for GNOME Mobile, or is it just all rolled up under GNOME’s broader decision-making process?

Paul: One of the differences between GNOME Mobile and the GNOME Desktop is that with GNOME Mobile, we’re really trying to build the foundational pieces that someone would use to create a specific device, rather than creating the entire interface and application space as well.

Whereas if you download all of the source for GNOME Desktop, and use something like Gentoo or Linux or Scratch and compile it all yourself and build it up, then you end up with a desktop that you would recognize with applications that you can use.

Within GNOME Mobile, we’re more about the foundational pieces that someone could use and custom tailor and build on top of to create a unique experience, so it’s really not the same type of end product as the desktop.

Sean: What are some of the more interesting observations or findings you’ve come across as you build for mobile devices?

Lots of companies have gone through various gyrations over the years, attempting to build functionality that would make a PC easier to use in a small form factor. Typically, they either try to up-level some platform that’s for a small device, or they down-level some functionality that is more common in a PC environment.

They go through various flashes of inspiration or pain, depending on how you want to look at it, and generally, they figure out that their approach doesn’t really work.

Since you’ve been involved in the project, what are the things that you’ve bumped into? What have been those flashes of pain or inspiration in trying to work with the mobile device, as opposed to a traditional PC?

Paul: One of the most important things I’ve learned is that the things that tend to be most successful don’t start with the technology–they start with what they’re trying to enable for the user. They have a user centered design approach and let the technology fit into that.

Scott: Considering somebody like Nokia, to some degree they take on the responsibility for figuring out what their end users want.

They own the experience, but they have the GNOME Mobile community-developed codebase as a foundation to build upon, so they’re not starting from scratch.

Do you think of GNOME Mobile as more about providing a good foundation for device manufacturers, rather than trying to be the complete end user experience?

Paul: Yes; our approach is very much to provide building blocks that they can mold to their device’s capabilities and what their users want to do with it.

Scott: That seems quite different from the approach being taken by GNOME for the full desktop, which tries to provide more of a complete experience that is fairly consistent from one distro to another.

Mobile GNOME might be so heavily customized that the user doesn’t even really realize that it’s GNOME underneath.

Paul: Absolutely. The basic reason for that difference is that all desktop or laptop machines are fundamentally the same, in terms of broad capabilities and how you interact with them.

There’s a keyboard, mouse, or trackpad, you have a screen at least 800×600 or bigger, and users have a certain expectation. The environment is very consistent, compared to mobile customer devices.

I’ve got a Sony Ericsson K850I with a quite small screen. I also have a Nokia N800 with a much bigger screen, but no keyboard or keypad of any kind. The phone doesn’t have a touchscreen, but the Nokia does. Some phones may have accelerometers, some may have GPS.

The usage models and how you interact with various devices is very different. It’s almost impossible to have a single interaction model or interface design.

Sean: Have you seen the recent news about VMware’s push to get into a virtualization stack for mobile devices? They made a big announcement the other day about working in that area to make it easier for users to switch among profiles and different OS architectures.

People have been talking about this type of advance for some time, but VMware seems fairly aggressive about it.

There may not be a direct impact on your efforts, but do you have any observations around virtualization on mobile devices, and what it might help you achieve in the future?

Paul: I saw the headlines, although I haven’t researched this story too far yet. Like everything in the mobile space, what we were doing with desktop machines five or 10 years ago is roughly where we are in terms of processor and storage capabilities in small devices today.

Virtualization is clearly a possibility on devices, and I am a bit curious to understand how exactly it will be beneficial–what the end user benefit of virtualization is.

Most of the benefit I’ve seen from virtualization has been on the server side. When I’ve seen it used on client machines, it was for IT professionals and developers to have multiple environments for development and testing–like running Windows and Linux on a Mac or multiple versions of a particular operating system to test with.

I’m not sure your average man in the street is even using virtualization on their desktop, so I really wonder why they would want to use it on their phone.

Sean: It seems that it’s predominantly targeted at the OEMs, but there are potential end user benefits, as well.

It will be interesting to see how it works in practice, but I’ve seen some discussion of being able to switch your user profiles between handsets from different manufacturers, regardless of what OS is running.

Because it’s abstracted, you could theoretically move your profile information from a Blackberry to a device running Windows Mobile or Symbian. It’s the same as when you hear people talking about compartmentalizing desktop apps into a VM, so migrating to another bare metal machine is simply moving the VM.

Scott: My impression is that a lot of input devices are handled deep down in the kernel, so that multi-touch functionality like the iPhone uses would require pretty deep changes to a system, beyond something like the GNOME shell.

Similarly, an OEM could design a stylus that might have a pen on one end and an eraser on the other end, and it would know how hard you’re pressing. I know at least on Windows that requires support really deep down.

Do you have sense of how to support those new human interface interactions if the GNOME project has to work with deeper things like the Linux kernel? How does that collaboration happen?

Paul: There would be some drivers that would need to be written in the kernel, but work would also be needed at the level of X. That would need involvement of the X.org project.

There’s already support for stuff like styluses and Wacom tablets in there, and we support those types of devices. Pressure sensitive input, having a pen and an eraser, and multiple pens that do different things are already supported, and there is development work going on within X to support multi pointer systems.

There is a conference called the Linux Plumbers Conference, which is one of the forums where this type of collaboration across the kernel, X, and the plumbing takes place. It’s not just for display devices, but also for sound, printing, and anything that cuts across these various areas.

Scott: So, the Linux Plumbers Conference is basically for these people at different layers of the stack who have to collaborate. It requires something deep down, but it needs to be surfaced in an architecturally sound way so that the things above it can really take full advantage of it. Is that where a lot of that work happens?

Paul: Yes. It also provides an easy way–even within companies that employ developers across those various projects–to get in touch and cross those boundaries.

Scott: Talk a little bit about the kinds of things that the hardware manufacturers contribute. I would guess that Nokia would have very specific things that they would be interested in to deliver the experience they want. Intel is obviously building chipsets and wants things to make use of the capabilities they put in the silicon.

Is a lot of what you see from the corporations that kind of deep hardware support?

Paul: It’s really a whole range of things. Most companies involved with GNOME Mobile provide some basic level of maintenance to the core components. Others push the capabilities and add features in areas that are particularly important to them.

In terms of hardware companies, it’s not something we may see in GNOME Mobile, but obviously they’ll be adding driver support in the kernel and X where it’s relevant to their hardware.

Other companies are involved that aren’t necessarily silicon providers. It can be the organizational structural support of building into their purchasing agreements, or putting pressure on their suppliers to provide open source drivers for their hardware.

Work in that area can be very useful. Although it’s almost tangential to GNOME in a sense, because we’re not at the level of hardware drivers, without them, we can’t run on a platform.

It also includes coming up with new software to add into the library. The GNOME Desktop and GNOME Mobile are not static projects–we have a six-month release cycle. We just released in October the first coordinated GNOME Mobile release that ties in with the standard six-month release cycle.

It was a base platform to get started, and now we’re considering new components to add to the platform. There’s a long list of incubator projects under consideration. Various companies involved in GNOME and GNOME Mobile have been working on parts of these libraries, developing them, using them, and adapting them for their devices.

Scott: We’ve asked a lot of stuff that’s interesting to us, but what do you feel is the more interesting stuff going on around GNOME Mobile right now?

Paul: We’re in an interesting period. A lot of what we’ve been doing recently is just getting our house in order, as it were, and tying the base platform into the standard release schedule. Now we can start to add to the platform and build out more capabilities.

It could be something like Clutter, which is a library for building interesting UI interfaces and user experiences based on OpenGL and GLES chipsets. Or it could be something like GuPNP for integrating uPNP services in devices.

Now, the pieces that we can make to build new devices become much more interesting.

Scott: Thanks, Paul. That looks like a pretty good place to wrap up.

Bookmark this:

Interviewee: Adam Williamson

In this interview we talk with Adam. In specific, we talk about:

• What’s new in the latest Mandriva release
• Relating directly to the users instead of the developer community
• Differences between user priorities and developer priorities
• Deciding what should be included in the distribution
• What will become of the “year of the Linux desktop” idea?
• The future of open versus closed development

Sean Campbell: Adam, please give us some background on you and on Mandriva.

Adam Williamson: Sure. I’m the community manager for Mandriva, which is my most important role with the project, but like everyone else here, I do about twenty other things as well.

I’m also the bug tester, I maintain several packages, and I do a lot of public relations community announcement stuff. Mandriva is one of the leading Linux distributions. It’s been around since 1998, so it’s one of the older ones. It primarily has a desktop focus, and we’ve got a strong international community.

Sean: Since you just released the most recent version, walk us through the most significant features you added to that release.

Adam: The biggest new feature is that we are using KDE 4 as the default desktop. We had a sort of testing version of it in previous releases, but it was more for playing around with than really using. For this version, KDE 4 is the default, so when users install, that’s what they will be using, out of the box.

That change brings a lot of great new features with it, like the plasmoids, the new file manager, Phonon, and all that good stuff. We’ve also overhauled our tools and our install. We’ve given them a completely new appearance, so they look nice and it also improves the ergonomics a bit.

Aside from that, there’s a whole laundry list of stuff. We’ve got GNOME 2.24, as well as LXDE, which is good for netbooks. We have really good netbook support in this release–we test things on the Eee PC, and we also have it working on the Aspire and the Wind. We’ve improved the boot speed quite a lot.

Something that I personally am involved in is support for working with mobile devices: Windows Mobile, BlackBerrys, and things like that, and I’m pretty sure we have the best support for that out of any distribution.

Sean: I remember from our previous conversation that you guys have invested a lot of time in mobile device support. Looking back historically, what particular challenges have you overcome in trying to integrate mobile device support?

Adam: That’s actually my stuff. It started with the 2008 Spring release. One of the nice things about Mandriva is that it’s a very flexible system to work with. About two weeks before 2008 Spring came out, my partner–who works for a cell phone store–brought home a Windows mobile phone. I plugged it in and couldn’t do anything with it. I couldn’t even look at what was on there, let alone start synchronizing it, so I decided to make it work.

There’s a framework called SynCE for Windows mobile devices that plugs into a thing called OpenSync, and then you need an OpenSync front end to actually synchronize anything. It’s a very complicated process, and at the time of 2008 Spring it was even messier because lots of this stuff was broken.

It involved getting OpenSync, SynCE, and a front end called Kitchen Sync all packaged up properly, and patched and working together. It was a matter of little bits of talking to various projects and getting patches and working out a couple of things that I had to fix myself.

I also had a BlackBerry lying around, so I got on a bit of a roll and I thought, well, I’ll get BlackBerrys working as well. It’s one of those little inspiration challenges, and the interesting thing is that it’s something that probably real people do more than distribution people. Your average distro guy probably doesn’t use something like a BlackBerry or a Windows Mobile phone; it’s not his work system.

But in my role of community manager, I know there are quite a lot of people out there who would find this quite useful. It’s kind of something that falls between the cracks for a lot of distribution developers, because they just don’t work that way.

Sean: Given that you’re the community manager, what are the features in Mandriva that you feel the development community rallies around–and you don’t really have to work hard to get them to throw their effort in–and what are the features that you have to sometimes say, “Hey, I need you guys to help out over here?”

Adam: In most companies, the community manager talks mostly with the development community, but I actually work mostly with the user community.

Our development is very collaborative between the community and the internal developers. It’s all done in Cooker, which is the open development distro; we don’t do anything behind closed doors. We don’t really have to drive anyone to work on any particular area, because we find that people tend to work on areas that are useful.

We don’t have a community manager in the sense of someone who directs the development community and says please do this, please do that. We’ve been doing community development for a long time, practically since we started, and we’ve got a lot of long-term contributors who understand what needs to be done. It’s really not something that we’ve had a problem with.

Sean: Given that you’re more focused on the user community, what kinds of things has the user community asked for that you realize are going to take longer to implement than the community thinks? This issue seems to come up a lot, when users are calling for a specific feature, but since they’re not software developers, they may not really understand that what seems like a simple request might take much longer than they think.

Adam: I know exactly the situation you mean–they’re asking for the moon on a plate, but they don’t realize it. The classic example is someone coming into the forums after they try out Mandriva, and it’s the first Linux they’ve tried.

They say “well, why doesn’t my wireless card work?” and “why doesn’t this USB Bluetooth adapter work?” and “Linux is just rubbish! Why doesn’t all this stuff just work straight away?”

I find all that a bit funny, because I came in around 2001, when you’d have the exact same tenor of post on mailing lists or Usenet at the time. The difference is that back then, it would be, “Why doesn’t my network card work? Why doesn’t my graphics card work?” We’ve gone from broken graphics cards to broken Bluetooth in five years, which I think is pretty good, actually.

[laughter]

Adam: But the thing is, problems are getting smaller and smaller as we go along. So I sort of view this as an encouraging message of progress more than anything else. They complain about things that don’t work and as you say, it’s not their fault, because you have to have quite a bit of technical knowledge to understand why it is hard to implement certain things.

Scott Swigart: You mentioned that you worked on the mobile stuff because it was interesting to you, but you also suggested that isn’t necessarily the way a lot of the Mandriva developers work. They might not have experienced the same pain as some of the other users. What do you think are some of the typical places where the itch that a user has is different than the itch a distro developer has?

Adam: One straightforward example is anything you can do from a console. I work remotely, and I’m more graphical than most of the technical guys on the distribution because I’m sort of moonlighting–like, I work in gedit. So when I go to the Paris office, I see a developer’s desk and it’s ten xterm instances, and you can’t see anything graphical underneath that.

I have another good personal example, even though it’s been superseded a bit because Kate and GNOME can both do it. But back around two or three distributions ago, I noticed that there wasn’t any easy way to launch a graphical text editor as root.

You could just open a file and edit it. You know developers are not going to notice this, because they just do things from a console. It’s natural for them just to go “su vi” or something.

So I came up with just a little menu entry that used consolehelper to launch gedit as root. A lot of people found this really, really useful. I do various things writing documentation on the Wiki. I had to write down “open a console, type su, enter your root password, and then type kwrite or gedit filename,” and I thought that was a bit silly.

Why can’t I just click on an icon and open a root text editor? A developer wouldn’t even notice a little thing like that or consider it necessary, but to users, it’s quite a big deal.

Scott: I got my start on Unix systems, so I’m used to the ten xterm windows, and I remember kind of feeling like GUIs were garbage to some degree. The command line was fast, and you could do exactly what you wanted.

You could pipe stuff to grep, you could filter it, and it was just way faster than clicking a million text boxes to say what you wanted. But that’s fundamentally different from what users have been conditioned to expect with Macs and Windows and that kind of stuff.

Talk a bit about the evolution of developers coming to terms with understanding the idea that users just aren’t going to be interested in learning a lot of command lines to be productive and happy on Linux.

Adam: That’s an interesting area, and it’s something that Mandriva has been on top of for a long time. If you go back a ways to the Mandrake days around 2000 to 2003, we were the distribution that did this kind of thing.

Mandrake was the big one, because we had the Mandrake Control Center, the Mandriva Control Center, which is a big graphical thing that lets you configure a lot of the system. That has always been one of Mandriva’s strong points, but it’s definitely evolved over time.

It used to be that a lot of new Linux users who were not top-level technical gurus wanted to open up a console and learn how to pipe stuff to grep and so on.

Now, a lot more of the new users are people who genuinely don’t want to learn that stuff, and it’s possible to run a modern distribution–not just Mandriva but a bunch of others as well–without ever having to do that kind of stuff.

That is definitely a development within the last two or three years. I think it’s fair to give Ubuntu a bit of credit for that, because they put out a graphical product that you install and then feel like you can actually use it as a graphical modern everyday desktop.

Prior to 2005, a lot of people tried Linux for a day or two and quickly realized that they weren’t actually going to be able to use it without learning a whole bunch of technical console crap. They saw that, and they rejected it.

Scott: Right. And Shuttleworth has always been happy to don his flame retardant suit and make himself absolute flame bait. He’ll post something on his blog, and the Linux community will absolutely eviscerate him and say, “I don’t even understand whether this guy gets Linux.” But it gets people talking.

Adam: Yeah, I do think he’s good at that. I’ve never met Mark. I know Jono Bacon at Ubuntu, and he is a great guy. He says that Mark’s a great guy and I’m sure he is, but he does have a great naive act where he says, “Well why can’t we just click a button and do this?”

[laughter]

Everyone’s like, “Well that’s insane. There’s never been a button for that!”

Sean: There’s never been a button in there. There shouldn’t be a button there. And he goes, “Well everybody wants a button to be there.” And everybody eventually goes, “Yeah. OK.”

[laughter]

How would you contrast your business model and approach to packaging and distribution for users and for businesses versus Ubuntu?

It seems that some of what you do is very similar to Ubuntu, in terms of the way you position yourselves, the way the distro is built, and the audiences you target. At the same time, another portion seems more similar to Red Hat, in the sense of your enterprise focus.

Adam: Mandriva has a very wide presence; we’ve always been an “absolutely everything including the kitchen sink” type of distribution. I guess it’s kind of an historical thing, because as I say, we started off a long time ago.

The Linux world was much smaller then, and we were at the time a comparatively large company. It was pretty normal and feasible to take 30 guys and have a web server and a distribution that worked as a server, a desktop, a firewall, and just about anything else.

We are trying to make things a little more focused these days. For the 2007 release, which would be about two years ago, we dropped several versions of the distribution that were editions. We dropped the PowerPack Plus and Discovery commercial editions.

Now we only have one commercial edition, and we sort of simplified the rest of the range. The idea is to focus a little more on Mandriva Linux as mainly targeting a desktop user base and then to separate out corporate server and corporate desktop a little more as a separate corporate line.

The Red Hat comparison probably works best as sort of a mini Red Hat idea. We have the Corporate line and then we have the Mandriva Linux line, which is more an end user community based kind of thing, a little bit like Fedora.

Sean: This was the year of the Linux desktop. Do you feel that one of the things that inhibits that is the fact that every piece of the Linux desktop wants to “market itself” as independent? Users get kind of confused because they get the platform, and Vista hasn’t exactly rocked the world either.

People go in and buy a box that says Vista on it, and it doesn’t say “Volume Shadow Copy version 5.8,” which relieves them of the clutter of feeling like they have to understand whether 5.8 is better than 5.7.

I wonder sometimes whether it’s important for the Linux desktop to fuzz the boundaries of the distribution, sort of the way Ubuntu has done, in order to relieve the user base of that kind of adoption complexity.

Adam: This is definitely my personal view and not the view of Mandriva, but I don’t think there’s going to be a year of the Linux desktop. I think desktop computing is going to become mostly irrelevant before that ever happens. Everything is going to go to mobile devices.

There’s going to be some kind of convergence in the space between netbooks and cell phones and smart phones. We’re going to wind up with a science fiction vision of the device in your pocket that does everything. But that’s just my personal view.

In terms of your question, though, I agree that what you describe is a drawback in a sense for the Linux desktop. I kind of gave up focusing on how to win all the users in the world a couple of years ago.

[laughter]

Adam: Instead, I focus on how to keep making the product better, and how to serve the users we have. I think it’s legitimate to view Linux as something for maybe 20 percent of the most technically inclined users who like to tweak and are curious.

That leads one to the view that maybe what we have isn’t perfect for everyone in the world, but it’s a good product in its own right. It does what our users want, and we’re just going to keep refining it and focusing it and improving it and growing that group of people gradually.

Everyone knows that Apple is never going to have more than 10 percent of the desktop market or something, but no one seems to think that’s a problem. That’s what Apple is supposed to be.

Scott: We could probably talk about Apple all day, especially in terms of the Apple enthusiasts that complain about Microsoft not being transparent.

Adam: Right–Apple is 10 times worse. Apple is the black box, and you have no idea what the hell is going on inside. What comes out is usually pretty good, but if you want transparent development, Apple is not the place to go.

Scott: We had a conversation with somebody a while back about whether proprietary software will continue to exist, or whether it will all go open source. Their point of view was that there’s always going to be room for a great product, regardless of how it’s developed. It sounds to me like the goal with Mandriva is really to be a great product, rather than to espouse open source.

Adam: Actually, we do care a lot about open source, and it’s important to stress that. Otherwise we get a lot of hate mail.

[laughter]

Adam: We’ve always had a free distribution. Since 1998, we’ve been releasing Free with every release. Everything we develop is always free software. We do believe in a lot of the arguments that free software development is inherently a better way to do things. If you go too far the other way, though, you end up with GNewSense, which the FSF loves, but no one uses.

Most people want a great product. If you develop a great product then people are going to use it, and we definitely focus on making Mandriva a great product. We love open source, and we try to push open source development. We got things like RadeonHD and Nouveau in the distribution, trying to push for open source components in place of proprietary ones.

Scott: Open source is a collaborative way of developing. You’re less likely to produce features that nobody’s going to use, because if there really were such things, nobody would write them. Users know that they’re unrestricted in how they use the end product. In other words, basically, my personal view is that the ethos of open source delivers value to the end user, even if they don’t buy into the philosophy of open source.

Adam: I have an interesting take on it because I work in this little nexus. As I said, I interact with users directly every day. I maintain stuff for the distribution, but I don’t code. I’ve never been an engineer, even if I’ve learned how to fix tiny little things just by trial and error and using Google.

But I can actually see everyday occasions where open source helps me and helps the users, even though neither of us have a clue how to write a garbage allocator. There are still instances where it’s important and really useful to me to be able to grab the code or do other things that are directly possible because of the open source nature of the environment.

You can talk to authors, you can download a project, and you can look at the documentation. You can email the author, and he’ll probably get back to you within a day. You’re not going to get anywhere trying to do that at Microsoft–you can try to email the author of Windows Media Player, but it’s just not going to happen.

I see positive outcomes from things like that literally every day in my work, where open source helps people directly.

Scott: I think we’ve come to the end of our time. Thanks for talking with us today.

Adam: Thank you–it’s been a pleasure.

Bookmark this: