Greg Kroah-Hartman recently gave a talk in Portland, OR on Canonical's contribution to the core of Linux. The talk was at the first Linux Plumbers Conference. The conference was designed to get as many of the core Linux developers together and talk face to face.
One key point to open-source software is upstreaming and downstreaming. Project developers, like Mozilla's Firefox, are the core of a product. Downstream companies grab and reuse the code of the upstream core team. So when Ubuntu pulls down Firefox, they package it for their users.
When users have problems they report them to their provider. So if I notice a bug in Firefox I go to Canonical's launchpad and file a bug. What should happen is that bug report, once verified, should go upstream. This means that the bug may be fixed by Canonical, or may be fixed by Firefox. If Canonical fixes it then they push that bug fix upstream to Mozilla, and downstream to their users. So not only do Ubuntu users get the bug fix, but all users of Firefox get the bug fixed as well.
This sort of collaboration amongst upstream and downstream users across the web of providers is one of the most powerful parts of open source software.
Another important aspect of open-source software is that upstream doesn't have to accept patches from downstream. If Canonical fixes a bug, but the patch for the fix does not meet Mozilla's quality standards, or Mozilla doesn't consider it a bug, that is fine. Canonical is responsible for producing what it views as is best for its users. Ubuntu users could also demand a feature in a product, and Canonical could implement it an upstream it, and the upstream could not accept the new feature. For example, Ubuntu users may want to use Firefox as a file-system browser. Canonical could add this support and send it up to Mozilla. Mozilla could simply conclude that being a file system browser is not part of its vision and not implement these changes. Other downstream could get these patches and put them in their product if they wish, or not if they don't.
What is important is that downstream communicates with upstream so that all downstream users of a product are able to benefit from each others work.
Back to Greg and the LPC. Firefox is none of their concern. They are interested in the core of what makes up the Linux OS. Firefox is not part of the OS. It is simply a browser that happens to run on Linux (as well other OSes.) The LPC is for people who work on core parts like the kernel, xorg (the graphical part of Linux), and other specific components.
Greg has two arguments:
So, in practice Ubuntu doesn't actually upstream to projects, they upstream to Debian. Debian accepts what they like and then upstream that up to the main project. The problem, according to Greg, is that these never make it back to the main project, and thus never trickle down to the rest of the OSS community. The accusation is basically that Canonical is not acting a good member of the community, effectively free riding off the rest of the group. His proof is in the low number of contributions to the core of Linux.
In the context of the LPC this makes sense. So what if Ubuntu has made major strides in fixing problems, and implementing new features in Gimp, Gnome, various translations, Nautilus, etc. In the context of LPC these are not important, just like an engine designer is not concerned with the improvements made in a car's dashboard.
Greg's mistake is pointing this out as if it is relevant. He completely misunderstands Canonicals place in the Linux ecosystem. Mark Shuttleworth did not set out to build a stable and secure operating system. Linux had been both stable and secure long before he come on the scene. The problem was that the stability and security of Linux was out of the grasp of users. It took months to learn how to install Linux, and then even longer to figure out how to use it. It was like having a car that never broke, but was more difficult to drive than a space shuttle. The strengths of Linux where irrelevant as it was obfuscated from usability by the average human being, indeed even the average computer geek.
So Mark set out to build on top of the Linux's greatness, and conquer its weakness. He wanted to bring Linux to the masses. He built a distribution that is easy to use and install. Linux is still not easy enough. In fact, no OS is easy enough. The fact of the matter is that every OS has really crapy usability. Mark is looking to fix that problem, and to make Ubuntu not only more user-friendly than Windows and Mac OSX, but to bring it to the level of usability that users are expecting of our future technology.
This is why you see him personally attending to bugs like this one. When you look at his comments, he is only commenting on the usability aspect of the bug, not the technical aspect of the problem. When you read his interviews he is always talking about the user experience. You will never hear him say that in the next version of Ubuntu he wants to bring killer features to the file system, or really great caching in the kernel. These aren't the things that he stays up late at night thinking about. He understands that there is already a really large team of great engineers working on these problems. He also understands that Linux lacks such a team for fighting for usability and the end-user experience.
Marks fight and Greg's fight are different fights on the same team. Greg is the butcher and Mark is the chef prepping the plate that is going to make the customer want to come back. The two should be patting each other on the back for doing such a great job.
One key point to open-source software is upstreaming and downstreaming. Project developers, like Mozilla's Firefox, are the core of a product. Downstream companies grab and reuse the code of the upstream core team. So when Ubuntu pulls down Firefox, they package it for their users.
When users have problems they report them to their provider. So if I notice a bug in Firefox I go to Canonical's launchpad and file a bug. What should happen is that bug report, once verified, should go upstream. This means that the bug may be fixed by Canonical, or may be fixed by Firefox. If Canonical fixes it then they push that bug fix upstream to Mozilla, and downstream to their users. So not only do Ubuntu users get the bug fix, but all users of Firefox get the bug fixed as well.
This sort of collaboration amongst upstream and downstream users across the web of providers is one of the most powerful parts of open source software.
Another important aspect of open-source software is that upstream doesn't have to accept patches from downstream. If Canonical fixes a bug, but the patch for the fix does not meet Mozilla's quality standards, or Mozilla doesn't consider it a bug, that is fine. Canonical is responsible for producing what it views as is best for its users. Ubuntu users could also demand a feature in a product, and Canonical could implement it an upstream it, and the upstream could not accept the new feature. For example, Ubuntu users may want to use Firefox as a file-system browser. Canonical could add this support and send it up to Mozilla. Mozilla could simply conclude that being a file system browser is not part of its vision and not implement these changes. Other downstream could get these patches and put them in their product if they wish, or not if they don't.
What is important is that downstream communicates with upstream so that all downstream users of a product are able to benefit from each others work.
Back to Greg and the LPC. Firefox is none of their concern. They are interested in the core of what makes up the Linux OS. Firefox is not part of the OS. It is simply a browser that happens to run on Linux (as well other OSes.) The LPC is for people who work on core parts like the kernel, xorg (the graphical part of Linux), and other specific components.
Greg has two arguments:
- Canonical's contributions to the core components of Linux are too small.
- Canonical does not upstream their core work very well.
- Ubuntu is too many degrees downstream to effectively get its work back to the core.
So, in practice Ubuntu doesn't actually upstream to projects, they upstream to Debian. Debian accepts what they like and then upstream that up to the main project. The problem, according to Greg, is that these never make it back to the main project, and thus never trickle down to the rest of the OSS community. The accusation is basically that Canonical is not acting a good member of the community, effectively free riding off the rest of the group. His proof is in the low number of contributions to the core of Linux.
In the context of the LPC this makes sense. So what if Ubuntu has made major strides in fixing problems, and implementing new features in Gimp, Gnome, various translations, Nautilus, etc. In the context of LPC these are not important, just like an engine designer is not concerned with the improvements made in a car's dashboard.
Greg's mistake is pointing this out as if it is relevant. He completely misunderstands Canonicals place in the Linux ecosystem. Mark Shuttleworth did not set out to build a stable and secure operating system. Linux had been both stable and secure long before he come on the scene. The problem was that the stability and security of Linux was out of the grasp of users. It took months to learn how to install Linux, and then even longer to figure out how to use it. It was like having a car that never broke, but was more difficult to drive than a space shuttle. The strengths of Linux where irrelevant as it was obfuscated from usability by the average human being, indeed even the average computer geek.
So Mark set out to build on top of the Linux's greatness, and conquer its weakness. He wanted to bring Linux to the masses. He built a distribution that is easy to use and install. Linux is still not easy enough. In fact, no OS is easy enough. The fact of the matter is that every OS has really crapy usability. Mark is looking to fix that problem, and to make Ubuntu not only more user-friendly than Windows and Mac OSX, but to bring it to the level of usability that users are expecting of our future technology.
This is why you see him personally attending to bugs like this one. When you look at his comments, he is only commenting on the usability aspect of the bug, not the technical aspect of the problem. When you read his interviews he is always talking about the user experience. You will never hear him say that in the next version of Ubuntu he wants to bring killer features to the file system, or really great caching in the kernel. These aren't the things that he stays up late at night thinking about. He understands that there is already a really large team of great engineers working on these problems. He also understands that Linux lacks such a team for fighting for usability and the end-user experience.
Marks fight and Greg's fight are different fights on the same team. Greg is the butcher and Mark is the chef prepping the plate that is going to make the customer want to come back. The two should be patting each other on the back for doing such a great job.
No comments:
Post a Comment