Plasma Netbook Reference Platform
A couple days ago I downloaded
a build of the Plasma Netbook Reference Platform (PNRP?), threw it on a USB key and for the first time ran it on an actual
netbook. Up till now I'd been running it either on my laptop or on funky "developer devices" hooked up to a normal monitor. Putting it on one of the first-gen EEE PCs was really eye-opening. The whole form of the user interface makes so much more sense on a smaller screen, and it worked right out of the box quite nicely. There were a few issues here and there, and some new issues related to design came to light as I sat there watching P. use it (he loved it, and is now back to using that rather old netbook now because of the new interface on it). This is exactly what we hoped for when getting PNRP up and running: being able to easily see it in the proper context and get working quickly and effectively on improvements. Since my experiment with P and the old netbook, there have been two new builds and I'm about to update his USB stick to today's version.
Some have also been asking how this relates to the Kubuntu Netbook effort. Kubuntu put out a tech preview of Plasma Netbook and continues to ship a netbook version. Why didn't we go with Kubuntu, then? Well, that question is a loaded one. In particular, it implies that only by sticking exclusively with Kubuntu would Kubuntu's efforts be validated. To me, those efforts stand on their own as being great and valuable and it's still something I encourage and support personally.
The openSUSE Build Service gives us two new things, however. One is a new set of tools that makes the "test, feedback, change, test again" and "try, change, publish alternate" workflows easy beyond belief (and the tools work on all major distributions, including *buntu, Fedora, Mandriva, Debian..). Plasma Netbook wins and that means our users win, regardless of the distribution they ultimately use it on.
The other thing using OBS gives us is another distribution joining in and getting involved. Instead of Plasma Netbook being theoretically available everywhere but only available in an "out of the box" configuration specifically for netbooks with one distribution (Kubuntu), it's now available "out of the box" for netbooks on openSUSE as well. I hope that number of out-of-the-box-for-netbook distributions continues to grow, and grow faster.
Testing and growth is precisely the reasoning behind the PNRP. It gives people something to play with and improve upon, but it also gives those who would package up Plasma Netbook a gage by which to measure what a Plasma Netbook release should look like (that's why it's called a ("reference"). This will only help to improve Kubuntu Netbook and will lower the cost of entry and raise the chance of success for any other OSV (or OEM) who wants to engage with Plasma Netbook.
Summary: we're working together with as many groups as we can to float everyone's boats higher. It's not a choice between one or the other, especially not when there is a "Help everyone!" option for us to choose.
Take a moment to take the
Plasma Netbook Reference Platform for a spin and discover just how easy it is go get that thing on a USB stick and booting on your netbook. The ease of a live CD, the speed (and persistence between boots) of a hard disk install. Huzzah!
We Do More Than Chase Taillights
The community press is fairly awash with stories about Linux on tablets. Why now? The iPad. This is what we're best at it, isn't it: chasing other people's taillights. Ok, that's a bit dour and we are actually really good at creating new stuff too. But when someone else comes out with something great, we steamroll off with amazing momentum to react. The word "react" is an interesting one: it's the combination of "re", which indicates repetition (it can also mean, funnily enough in this context, "backwards"), and "act". While reacting is important in not letting Free software be end-run by the good ideas of others, we also need to be proactive. The prefix "pro" can mean this: "a prefix of priority in space or time having especially a meaning of advancing or projecting forward or outward".
The good news is that we are often proactive and there is a lot of interesting work being done in Free software. The concept of "activities" are big topic right now for us in Plasma, to pick just one example, and they aren't to be seen outside of Free software. There are many such examples to pick from, but there's something about our proactive work that fails us. After all, why aren't the MacOS or Windows fanboys railing on about the need for activities on their platform? (Ok, besides the fact that they are still a work in progress on our platform; but I predict when we ship them fully formed, that still won't change the answer.)
These companies do something we don't which we ought to be doing: not only are they proactive as well as reactive in creating technologies, they tell people about what they've done.
If the press, driven by our promotional efforts (across Free software, not specifically/only KDE people), spent the same effort publicizing our proactive efforts as they do our reactive ones it would be wonderfully (or painfully, if you are competing with Free software ;) apparent how well F/OSS does on the innovation front.
Defining Ourselves By Successes
We also need to learn how to define ourselves by our successes and see our failures as interesting, expected and required by-products of the road to those successes. There are people in the community who look at our success in countries around the world and discount it all as being "not relevant" because it isn't in the country they live in, and therefore conclude Free software has failed generally. Similarly when we talk about using KDE (or other F/OSS) software in production usage, instead of defining our successes and positioning ourselves in line with them we too often discount all possible usage of that software because of failures that affect only a portion of the market. This leads to us eliminating ourselves from entire market segments that we are perfect for just because we aren't (yet? :) universally perfect.
This would be akin to Apple telling nobody to buy the iPhone just because they don't feel they, as a company, are a great fit for the enterprise or that due to the lack of multitasking the iPhone is a poor choice for a variety of use cases. Those are both statements of truth, but that communication would do a great disservice to those whom the iPhone does work just fine for by preventing them from trying it. Now, if we made the iPhone we'd make double sure people know it wasn't ready for the biggest of enterprise usage and how our lack of multitasking is a "real issue that makes us not ready for production usage". Yes, we would be able to take the iPhone and destroy its potential success in the market. This in spite of many of the people I know who are "guilty" of this behavior thinking the iPhone is a great product, a feeling they have because they have been made aware of the benefits clearly and because it is a product, faults and all, that is clearly defined by its successes.
Note that Apple does not ignore (all) failings: eventually the iPhone OS will do multitasking. Nor do they try and say that it currently does indeed do multitasking. They aren't saints (I'm not a fan of their use of legal pressure and ultra-secrecy), but we can learn from some of the things they do well. I also love their approach to the enterprise by seeing sales to enterprise customers as "collateral successes". They don't perceive themselves to be a failure because they don't do well in the enterprise, they are a success because sometimes they win even in places they do poorly. Imagine if we had that same healthy viewpoint of F/OSS? There is no excuse not to.
So not only do we have to be proactive (as well as reactive) in creation, we have to be able to define ourselves by our successes and speak openly to the people who are well served by those successes.
Speaking Openly About Our Failings
In my opinion, the best place to speak about our low points is with each other, where "each other" is defined by "the people working on those things". This is how we can identify and fix those issues. I'm not advocating actively hiding them from the public, but talking with each other about them is the best way to see improvements be made.
When we decide that our first action will be to broadcast what we see as problems via, say, our blog we are setting up a very nasty situation, especially if we're talking about someone else's work. We may not have the whole story, and spreading half-facts or even incorrect information does not help anyone.
It reminds me of a story about a guy who was spreading rumors about this other fellow called, for ease of story-telling, Bob. Bob and the rumor monger have a discussion about the rumor and it turns out it was largely a misunderstanding. The guy apologizes for the misunderstanding and expects it to be all better between them from that point forward. Bob says it's more complicated than that, and to illustrate he takes the guy out to a bridge and brings along a feather pillow with him. Atop the bridge Bob tore open the pillow and the feathers blew in every direction on the winds that swept the river valley below. Bob pointed out that while he realized ripping the pillow was not the right thing to do, the feathers were still spread out everywhere and were now beyond his ability to get them back.
When we blog, we're ripping open a feather pillow into the Internet.
Just as important, when we discuss things between team mates in the context of the appropriate mailing lists, irc channels, etc. then we give each other the opportunity to respond without pressure and in context. People, being people, respond much better with greater performance with that kind of approach. If your goal is just to piss people off, then don't do such a logic, reasonable thing. If your goal is to see things improved, then discuss it with the people involved first. Then go blog about it and document the warts, but this time with accuracy and all parties aware of what's coming.
Of course, if you get ignored or the responses returned are indicative of being in need of a wake up call (e.g. there's denial at play) then maybe press the issue by taking it to a wider audience at that point. I've personally called various people to task in the past via my blog, but before doing so I try to ensure that I've first attempted (in some cases for months!) to get the issue dealt with either privately or in the appropriate context. There are times when the unfortunate is necessary.
In KDE, this is very rarely the case.
