Persistent Blockers
Some of the blockers for mainstream Linux desktop usage are lack of legal codecs, hardware integration and certain types of basic functionality like software suspend not working reliably. This is not news, of course, but rather the typical gripes people have had for years. Even as much of the Free software has reached the point of being true-blue entries in the top echelons of functionality and quality, some of these issues continue to nag at us unanswered.
These are things that the KDE community itself can't really fix, at least not by simply writing KDE-based software. I always figured, and said as much whenever the topic came up, that eventually Linux would be shipped by system integrators who would invest in an "OEM" version of a Linux-based OS. They would take (or so I thought anyways) a distribution that already exists and has commercial support behind it and do much as they do with Windows and gussy it up for their combined hardware/software offering. At this point in the product chain consumers are forking out hard currency for product (the computer) and there is some profit margin in there, helped along by the lack of a Windows license (hopefully, anyways =). This money could be used to purchase the needed bits, such as codecs and fonts. By adding just a little bit of "final primping" Linux would finally be a complete product. Instead people want a system with a lower price point and the cool feeling that comes from seeing Linux being an option on a system integrator's website.
So when Dell announced that they were going to be shipping Linux laptops and the Canonical marketing powerhouse started cranking out the stories about it, I figured this could be the start of this development. Unfortunately, someone (Canonical?) forgot to tell Dell (or they just didn't listen?) that more than simply slapping Ubuntu on a laptop was needed. The result has been that reviews from the likes of the Wall Street Journal are starting to appear and they have not been particularly flattering, even going so far as to warn people away from Linux and Ubuntu.
What could have been done?
When it comes to the desktop I don't expect the Dells of the world to understand their part in the game; and I've come to not expect the Linux distributions to understand their part in the game either. Sadly we're in a position where distributions, who have many of the wrong motivators for this kind of work such as an emphasis on packaging ease versus system continuity or differentiation versus broadly applicable solutions, hold many of the cards when it comes to serving as advisors in creating these products.
So it is that Linux distros tend not to take a Dell-like opportunity and say, "Look, we'd love to do business with you. We have a lot of opportunity here, but it needs to be done in a way that we'll actually make significant sales over a period of time necessary to keep both of us investing in this. Let's not just ship whatever we can today, let's make a product that actually works for the end user market. Let's remember that we're trying to break into an established market, so we need to be a bit disruptive and very much a quality offering ..." That's the point where discussion about adding control panels for the touch pad in the laptop arises; or how to get a legal DVD playing stack in place; etc ...
It would likely take another year or so of work when it is all said and done and certainly some outlay of finances, but then there would be a product that would have a chance in the marketplace. So why doesn't this happen?
Decisions Made At The Wrong Times And In The Wrong Places
If you were to walk up to a random KDE community member who is working on KDE 4.0 and asked, "So, what's this KDE4 thing all about?" you would almost certainly get a nearly standard answer despite that answer not being recorded on any website (which is something we really should fix, btw =).
They would likely tell you about the 'pillars of KDE' (Phonon, Solid, Decibel, Oxygen ...), about the increased portability (Linux, BSD, Solaris ... but now also native Windows and MacOS) and about the new generation of applications that are taking advantage of the latest capabilities of our underlying libraries such as Qt4 (Marble, Dolphin, Okular, Kalzium, KDE Games, KOffice..). It's a voluminous story, but you'd get the same general answers from just about everyone.
Even more impressively, if you asked why something like Phonon and Solid were important you'd also get the same general answers: portability, future proofing, simplicity and continuity of API .. leading to better applications that work better for the end user.
KDE people have done a pretty good job of building a shared vision, even though it's been independently implemented. While most of us agree on what KDE4 is about and aimed at, we haven't had massive technical design meetings that span the entire project to cement this vision into place. Instead, each group of people working on a given aspect of KDE have internalized these ideas and concepts (often with their own personalization of them; we're not automatons, and that's a good thing =) and used those concepts as an ingredient in formulating their own direction. This has been messy at times, but a chef is judged on the food served rather than the state of the kitchen.
Back to the Dell/Canonical offering... What is it about? Heck, we could repeat that question about a lot of Free software desktop projects right now and I bet the answers would be pretty similar: meanderings, usually in the form of silence. This includes the Linux kernel where we have been, for instance, gifted with inotify which really isn't up to the tasks demanded by the modern desktop user. Do they know what we need, or why we need what we need? Indeed, when it comes to the desktop, what is the Linux kernel about? While the community is currently obsessing about schedulers, we're missing some pretty fundamental understandings as to what we want the kernel to achieve. As a result it's a hodge podge.
There have been moments where Linux flirted with desktop vision: project utopia which led to HAL was a good example of this. Regardless of what you think of the quality of the resulting implementation, HAL is getting the job done and it started with a clear statement of intent and everyone could answer that all important question: "What is it about?" There is a connection between being able to clearly answer that question and having something appropriate at the end of the development cycle.
However Dell, Canonical and others like them (those two companies aren't unique in this way) are not in a position to be able to create the basis for answering The Question properly. They are too far removed from the technological design and vision process and they have an incompatible (not bad, just incompatible) set of priorities for doing so. This is not something to be fixed, because doing so would probably break them in other ways that wouldn't be good for their survival.
The Question(tm)
So here's The Question put clearly: what is the Free software desktop about?
Honestly, I couldn't tell you in clear terms. I can tell you what KDE is about, but as soon as I start adding in all the other pieces things get fuzzy really fast. Those "other pieces" include all kinds of software: kernels (Linux, OpenSolaris, *BSD), printing (CUPS), groupware (Kolab, OpenGroupware, ...), directories (OpenLDAP, Samba ..), virtualization (VirtualBox, ..), media (ALSA, GStreamer, NMM, Xine, MPlayer ..) and on and on. What do we have in common when it comes to what we want to achieve? What will those achievements look like?
Is there a place where project leadership from each of these groups comes together to create such shared vision? Or even just to share their vision so we know what each other are thinking, needing and wanting? I can't. I originally had hoped that the Linux Foundation's Desktop Architects Group would provide that place, but it has turned into a set of working groups focussed on implementation issues. That's useful, but not the only thing we need. In fact, we're already pretty good at implementation, while we're less than good at coordinating the driving factors behind those implementations. The result is a scatter-shot set of software that the Dells of the world have a hard time packaging for the consumer market; lots of great pieces, but no real whole.
Let's Find a Solution!
Can a Linux distribution company fix this? I don't think so, because they don't affect the vision in the upstream projects. I do see Mark going around trying to inject interesting ideas into these projects, but at the end of the day they tend to be yet more external thinking rather than a well formulated and internalized foundation that spans projects providing holistic direction and vision.
The amount of "external thinking" being thrown around is at all-time highs right now and to be honest most of it is extremely ill-informed. Concurrently, processes for the incubation of internally driven focus creation is nearly non-existent.
The Desktop Architects group has become pretty firmly footed in implementation issues; don't get me wrong, the topics are extremely important but they are near term ("Horizon 1") issues. Requests for a 6-month-heart-beat for software projects is another short game concept which is apparent when the road to long term development is explained after the fact rather than being a part of the process formulation itself. Horizon 1 is critically important, but is not a perpetual source of improvement on its own.
If this trend continues, we will pay for it in the long term because that internal focus creation is the source of long term ("Horizon 3" for the management crowd) R&D. In turn, this is where useful "Horizon 2" (mid-range) results emerge from along the way if competently nurtured. Ever noticed how many free software desktop projects have started falling into a rut of uninteresting development? That's Horizon 1 obsessive/compulsive disorder at work.
Let's Find A Solution, Take 2
I do think we can inject exciting vision across the Free software landscape; I seem to remember it being there years ago actually. However, I have come to believe we need something slightly new: a place where people from the various creative projects can come together with each other in relative peace and quiet to share sweet spots, pain points and their own internal vision and motivations. The theme should be to keep asking The Question with each until The Answer(tm) starts to crystallize. This vision will be pretty amorphous and ever evolving and certainly not come in the form of a typical management lackey's five sentence vision statement summary. It will also be slightly unique from the individual project's "native" vision as it will be the summation of a greater set of thoughts; and that's perfectly Ok.
Then like the pollinators of beautiful flowers, the participants will need to take the germ of The Answer back to their respective projects and start the conversations there. This will allow a coherent strategy to self-emerge: each project will personalize The Answer for their own cultural context, but it can start to become a common thread woven recognizably through all of our tapestries. This will result in a coherent set of technologies that fit together nicely as a whole product; in fact, the path to tying that whole product together will likely become self-documenting so that system integrators will get a How To out of it all as a bonus and actually stand a chance in hell of getting it Right.
How To Support The Solution Process
OSVs (operating system vendors), ISVs, customers and system integrators could show their full support by funding but not attending such events themselves. This will avoid tainting the process with their own priorities which are not conducive to this particular kind of exercise. It needs the creative projects, not the productizers (yes, there is some overlap but it's pretty easy to keep them separated).
Enthusiast in our communities can show their support by accepting the process to be most likely a bit messy and even not very comprehensible from the outside. Instead of using that as a reason to voice ill-informed concern and thereby putting pressure on the relatively fragile process of maintaining the context necessary to build The Answer, support (even in the form of hopeful silence) would be great.
The friendly media can support the process by not reporting on the process (I know, counter intuitive =). Honestly, there really won't be much that's interesting to report on. Trying to invent reportable results is part of why some attempts at this process have drifted towards short term goals as they are results you can show and measure in time for the next magazine article printing. There's lots of other stuff to report on, in any case.
Free software projects can support the process by showing up and honestly engaging in the conversation; send your system thinkers who are daring enough to think about big picture issues and be ready to start taking the resulting ideas into serious consideration when working on implementations, most of which already kick ass but miss the sort of continuity we need to create a whole product for client side computing. Server oriented projects can think about their client-side roles or the role of the client on the server-side and engage on those terms (or not at all if there is truly no cross-over).
When and Where?
This is the part where the man behind the curtain emerges to show his empty hands. As they say: I got nothin'. This is just an idea, a set of thoughts spewed stream-of-consciousness style from my mind, through my keboard and out onto the Intarweb. As one person I can not implement this myself. As one project, even an amazingly vibrant one, KDE can not implement this on its own either. Hopefully the idea will start to percolate about and eventually we'll find a forum for creating The Answer(tm). I'm willing to help as I can (which isn't much before 4.0 comes out), and I think KDE is in a great place organizationally to contribute to the process.
Until we get this, or something like this, moving ... we'll just have to deal with the ascendancy of the Free software desktop remaining slow (though continuous) and with the on-going disbelief from the mainstream markets and those who analyze and report on them.
12 comments:
That was quite long and engineerish piece :)
However it is quite obvious (to me at least) how it could all be done in ca. 2 years - get past 50% market share and just crush the competition. Simple ~10 point initiative could do it if it received some resources.
Hint: over-engineering is not the key to success.
@anonymous: "That was quite long and engineerish piece"
it's just my nature =)
"how it could all be done in ca. 2 years "
yes, it's certainly a multi-year initiative. it took us ~3 years to accomplish it (as much as we have, anyways, it never ends) in KDE, so i would expect it to take at least that long given that we'd be dealing with greater diversity and higher latency.
"over-engineering is not the key to success."
indeed; in fact, this is hardly about the engineering itself as it is about the motivations and targets for said engineering. we don't need to change the creative process, we need to adopt some shared context (aka "vision").
Excellent post!
Thanks for sharing you interesting thoughts with us :)
Aaron,
Here's a radical thought that spells out more clearly some of the challenges that you point out.
1) Distributions have a vested interest in not seeing a universal form of software installation in Linux.
Solution: Do away with distributions and create an operating system that can be heavily customized.
How: Get the Linux Foundation and OEMS to buy into the idea of supporting a single code base for desktop linux at the kernel level. This single distribution would also be supported with hardware/software management tools that were desktop neutral and could have different front-ends implemented (network manager is a good example of this type of design).
There would be lots of resistance, but if this desktop distribution was of a far higher quality than everything else, there is no reason to believe that users and, eventually, distributors/distributions would not flock to it.
Distributions would need to be more willing to invest in a common foundation in the same way that HP/IBM et al. have been investing at the kernel level.
Differentiation would come in the quality, pricing and language availability of their support options.
Differentiation would also come in the way of specialized task-specific distributions. While the base would remain common, distributions could specialize in ways that matter to their users: a musician's distribution, a ready-made distribution to use in a school environment and so forth.
Would the above encounter lots of resistance? Of course, but we would save so much energy by working from a shared base and shared bug database.
Right now, Mandriva fixes something in their tools and that fix isn't in any way helpful to a Suse developer. A lot of this repetitious grunt work could be shared, resulting in more efficient use of development resources.
Does it make sense for each distribution to implement its own battery monitor or wifi widget or partitioner?
Three elements to gain adoption of this type of proposal:
1) Discussion among the respective leaders of different communities of this type of proposal and some supporting public statements from people whose views on these issues are taken seriously.
2) A consorted push by OEMs to get distributions onboard.
3) Some courage to really break out of our current mold and really think outside the box.
You know, these short blog entries of yours are getting rather terse. Could you expound a little more in the future?
:)
Big Sis
Hello Aaron,
interesting read, I take you are on your way to become Free Software President now :-)
I am surprised inotify you said not to be good enough? How do you mean that?
My thinking of how Linux is and has become successful is that it's because of the diversity in both directions and implementations.
There were still people making bash 3.0 while you were not looking.
And there still are people who optimize the scheduler, although it's good enough for us.
You may not believe it, but trust me, KDE3 is good enough for many things already.
That alone, and nothing else makes sure, that when a user comes to table, that his expectations are way exceeded.
We have tremendous shells (bash, dash, tcsh), so we have and get more tremendous kernel schedulers.
And we have a KDE version that's very nice to work with.
I wouldn't want to tell anybody to not work on something. It may not be put to use or end up useful. But that's people's choices.
Everytime somebody says "Don't do this thing, do that other thinginstead." a discussion is going the wrong way.
You can say "Don't do this that way, but this way instead, because of reasons I have here."
If you cared deeply enough and understood how it's flaw, how about detailing that to LKML and other BSD/Solaris *-dev?
It's not like you won't get the attention. And it's not like Linus didn't make Gnome patches to prove his points.
What you need to and should do, is to raise the interest in providing interfaces in the kernel that KDE needs.
The best way would be to make sure these are generic needs, by making Gnome, Xfce and other friends agree.
When they can be demonstrated, you can try and convince people to implement these, and they may be accepted by the different kernel groups.
But then, I am surprised, that KDE cares much about inotify. That's a problem hidden in "fam" and alike servers, which seemed to work last time I looked?
Yours,
Kay
PS: Has ANYBODY ever thought threw that captchas prevent blind people from partipating?
Thanks for your complex and interesting blog post.
Your choice of titles for your last two blogs is quite amusing, because when I read this one, I thought "wait, this is about Free Software". It is about the nature of the large (upstream) community projects, to be exact.
1. In a free software project, you don't influence all your neighbours. Take KDE - you certainly can influence the KDE-oriented distributions, but you don't really influence the Linux kernel, the CUPS printing system and others. Why? Because your vision is not identical to theirs (sincerely speaking, I don't think Apple's CUPS cares much about what KDE would need).
2. In a large community project, you don't influence all your participants. I am sure Aaron Seigo's vision of KDE is shared by many of the top KDE developers and users, but is it shared by all of them? My answer is no, based on the reactions of users on my small, but critical review of digiKam's UI. The comments show that the users seem to think that digiKam targets professional photographers and power users mainly (which is not a bad thing, just a fact), even though the KDE4 vision is aiming at someone else.
Another example of this is the Linux kernel - many professional contributors to it are paid for its functionality on servers, not desktops. That means even if you had a patch improving the state of Linux on the desktop, it would also have to not harm performance on servers at all. And such patches are hard to produce and the procedure is hard as well.
Which brings me to:
3. The whole point of downstream (distributions) is to overcome points 1 and 2. The (K)Ubuntu community talks to all of the upstream projects and unifies their different visions into one product with one vision.
Compared to all the upstream communities combined, the Kubuntu community is quite small, which also keeps its vision consistent.
If the project foo doesn't aim at the same things we do, we can do something about it - we can either not ship it in the default desktop or patch it to fit our needs.
That is why it's so dangerously easy to let patches rot downstream - because we can and we don't have to argue with the half of the foo community (the part that doesn't share our vision and wants foo to be for themselves-power users) to push our patch upstream.
The idea of creating an "upstream distribution" that somebody suggested seems impossible to me. If all upstream projects had the same goal and no developer would fiercely defend his own vision, there would be no KDE and GNOME, just one Linux. And that is not likely to happen ever.
Long story short: Downstream is there because not every upstream Free Software Project that is related to the mythical Linux Desktop has the same aims. Downstream can do what upstream cannot - reshape several projects to meet one single goal.
PS: Sorry for addressing just a tiny bit of your post.
In terms of legal DVD playback I had perhaps naively believed that was an easy problem for an OEM to fix since the physical DVD drive itself would count as one license already bought and paid for and they be able to use their clout to avoid paying again. Maybe that too much wishful thinking and isn't so simple in practice.
Bunnies can't dance!
I understand it's tough for Ubuntu, it's hard even for enterprise distros, which have teams of engineers working on such deals. Ubuntu has to learn a lot in the enterprise area, and preloads are quite tricky.
Moveover, with their usual (with a grain of salt) principle "Take and don't give back" it's quite hard to support something for which they have large community, but very little own resources (which are unfortunately often needed to fix the preload crap).
Excellent posting Aaron. I too have been disappointed in how the first pre-installed Linux products have been rolled out. Slapping Ubuntu on a hardware platform that is fully supported by linux drivers is the easy part. Adding the integration support that makes the product meet the expectations of the consumers is quite a different thing. I have been in communication with some of the Dell folks and have been providing feedback to them in these areas.
To meet the expectations of consumers, mp3 playback has to just work, DVD playback has to just work, ripping CDs to mp3 (I know ogg is better, but we are talking about consumers here) has to just work, and sensitivity control of the touchpad has to just work.
Without audio/multimedia support out of the box (no googling, no command line, no Ubuntu forums), the pre-installed Linux consumer desktop will be still-born. CNR is coming soon and this will make it much easier to purchase and install all the audio/multimedia support. However, an OEM should just include these costs up front so that everything works out of the chute.
To focus on the positive, the following areas meet or exceed the experience on windows: getting updates, web browsing, file management, network shares, cd/dvd burning, talking to iPods (once mp3s are ripped), version upgrades, image editing, printing (brand new models are still a problem), and video production.
You are totally right.
Unfortunately, distributions dont want to go away, and they are jealous of each other.
The biggest culprits are actually COMMERCIAL distributions. Just look at how much influence they make on the "free software" or "open source" aspects...
Linux people often attack Microsoft, but at the same time they dont see how quickly they are slaves of their distribution.
I applaude the linux from Scratch team to make a difference because their information makes the world a slightly better place.
Post a Comment