We (the KDE Plasma Team) are sitting at the SUSE office in Nürnberg, Germany right now, kicking off the already 6th edition of Tokamak, which is the name for (most of) our Plasma meetings. A Tokamak is a container for Plasma, which uses magnetic force to keep the Plasma in one (very hot) place. For the Plasma team, it provides a high-bandwidth setting where we can discuss, design, review and hack on the technology behind the Plasma workspaces. This meeting’s topic is Plasma2, the evolution of Plasma into the Qt5 and Wayland world.
First, we agreed on a bottom line: “Plasma 2 will be at least as good as the current Plasma, and probably better in many aspects.” This means that we’ll have to invest considerable effort and time into stabilization. At this point, where we are probably still a year or so away from a Plasma2-based release, making it part of our planning now will allow us to focus on the things that we think, matter. Among that is making sure the transition to KDE Frameworks 5, Plasma 2 and Wayland will be as seamless as possible, and perceived as an upgrade to our users.
But why are we doing this? Why are we putting so much work into it, what’s the benefit for the user?
Why switch graphics stacks?
In the past years, the landscape of graphics under Linux has changed quite a bit. Many things, like memory management of the graphics stack, rendering of primitives, font rendering, and a few other things involved in the process of “getting pixels onto your screen” have changed, and they’ve changed for the better. With a stack based on Wayland (and in extension Qt5), we are able to utilise modern graphics hardware better, to reduce maintainance effort and hopefully grow the community around the graphics stack, and not at least, to make sure that every frame that ends up on the screen is perfect. In the X11 world, we can’t really control it, since we have no idea when something is painted, in which way it is, where it’s painted, and when the pixels end up on the screen. With Wayland, this process of event processing, rendering and blitting is structured and guaranteed to happen in a certain order. In the end, this transition will enable us to put 60 perfect frames every second on the screen. The new architecture also allows us to split the rendering into its own thread, so data processing or event handling in the application doesn’t end up delaying rendering. 60 frames per second will make the UI feel smooth as buttery silk, leading to less strain on the eyes and a nicer user experience.
I’ve compiled an update to the Balsam Professional Plasma Active packages in the last weeks, they are now are available for your upgrading pleasure. While the packages work very well in my testing, they are still only development snapshots, so if you’re happy with your current Plasma Active, and you need to be absolutely sure everything keeps working, I’d advise not to upgrade. In all other cases, you’re in for a good performance kick, a lot of bugfixes and a few new, but important features.Instead of boring you, my dear audience, with a long piece of text, I got out my webcam and recorded a screencast of these packages running on my viewtab (an Atom-based 10 inch tablet). Lay back and watch.
In the screencast, I’m showing the general workspace UI, as well as a few new apps and features, file browsing, microblogging, news reading workflows, which we’ve been improving lately.
The packages work fine on wetab and exopc tablets, and most likely also on other Intel-based tablets. Builds for various ARM flavours are available throught the Mer project. As Balsam Professional 12.1 is compatible to openSUSE, they will also work there. If you want to install the packages in your desktop, be advised that this might mess with your desktop sessions, so that’s essentially at your own risk.
The Balsam Packages are made available by open-slx and built and served from our Open Build Service.
The past weeks, I’ve been working on getting Kwin, the window manager and compositor in Plasma Active (and Plasma Desktop ;) to work on top of OpenGL ES instead of OpenGL. After some updating of packages lower in the stack, especially Mesa and parts of Xorg, we now have working OpenGL ES support on our hardware. Today, I’ve finished packaging it as an option on top of our Plasma Active packages. These packages in the :Devel subsection of the KDE:Active repository in the OBS run on top of Balsam Professional and openSUSE 11.4. We will give this some more testing and improve a few things, in order to move to GLES by default. OpenGL ES is very interesting as this is an API often used on mobile devices, so I’m glad that I can state that we’re ready for this. This of course needs proper support in the drivers, something we can not always solve by ourselves. I have been running this successfully on two Intel Atom-based tablets.
All the props of course to to our Akademy-award winning window management and compositing hero, the one and only Martin Grässlin. He’s been working on OpenGL ES support (and a lot of other features to make kwin “ready for the future”) for quite some time already. OpenGL ES support in kwin has been introduced in the recent Plasma Desktop 4.7 release, a few weeks ago.
So, is it much different? Nope, it’s very much a thing of underlying technology. There’s no noticable performance improvement, but it runs stable and well. Given that OpenGL ES support has only very recently been introduced in kwin, it’s already surprisingly good. There is probably still a lot of room for improvement, which is something we can investigate now and easily test much better.
Froscon
In the screenshot of the Contour shell of Plasma Active, you can see that I’m all set up to go to FrOSCon tomorrow, where I’ll be presenting the ideas and demoing the prototypes, hoping to get some feedback on concepts, and give some understanding of the challenges and opportunities we face in this exciting endeavour. And of course show some serious bling. :) If you’re in the area around Bonn, drop by.
The past week, when working on the Mesa packages for Plasma Active, I might have caused some headache since I broke the compositor in Plasma Active with a few packages I uploaded for easier deployment on test devices. It was not more than an annoyance, because kwin gracefully falls back to non-composited mode in case of graphics problems. In order to get a bit more stability into our deployment process, I’ve now set up a subproject called KDE:Active:Devel under the KDE:Active project on the Open Build Service (OBS) which we use to build the Balsam packages. As we’re moving, development-wise into the stabilization phase for Plasma Active One, this makes testing new things a lot easier, just by switching to the same package from the :Devel branch. Conversely, this means that if you install packages from the :Devel subproject, you should really know what you’re doing. On the bright side, it’ll be easier to keep regressions out of the packages that are deployed on most users’ machines.
Along with these changes, I’ve updated all the packages to the latest state of the art, and worked a bit on our documentation, as we keep getting very good feedback about this. Among the most wanted fixes we’ve introduced is a patch by Aaron that makes konsole usable with the virtual keyboard, making another very powerful tool usable on Plasma Active. I’ve also fixed up some default configuration options, polished up the contour packages and made that used by default. (Those who have plasma-tablet-config on their machine will have to replace it with “plasma-contour-config”, though.) This is another pretty big move, as we now basically regard the contour shell stable enough to make it into Plasma Active One. It’s also very, very shiny I must say, the usual disclaimer about alpha software notwithstanding.
OBS makes it rather convenient merging changes back and forth between these branches. In general, my impression is that OBS works very nicely as a collaboration tool, and solves a very complex problem for us, the “how do we get our code onto the device”. As an aside, it also makes it very easy to build packages locally, so for even shorter development-deployment cycles, one can build locally and rsync packages onto the device. With the right kind of script setup, that takes a lot of the pain away, that development for mobile devices often brings with it. The KDE:Active:Devel repo can be used directly by developers to upload their latest sources in order to deploy them to their testing machines, and we can pull working versions in from there. Rocking.
If you own an ExoPC, and you’re eager to know how to get Plasma Active, our new workspace and set of applications for consumer devices to run on it, this blog article will help you get going.
Note: Plasma Active is in alpha state right now, it is basically usable, but you will find many rough edges. You should not try this unless you consider yourself an early adopter, or if you mind fiddling with bits and pieces. We are working towards an end-user ready product, but we’re not yet there.
What to pick?
There are a few different options to choose from, I’ll quickly explain which to choose under which circumstances.
MeeGo: Works well overall, but is lacking in key areas, for example we do not have a UI to connect to wireless networks yet, and as the device doesn’t have Ethernet (and cables are lame on mobile devices anyway). You can work around this with a trick Marco explains. Choose this option if you want to run and develop for MeeGo
Balsam Professional: Download the Balsam Professional live images from open-slx. This live image provides a fully functional live system without too much hassle. Choose this option if you want to try Plasma Active
openSUSE: Install Plasma Active on top of openSUSE 11.4, it uses the Active packages created by open-slx (me, my employer), but is a bit more laborious to install. Choose this option if you want to run the full experience on your ExoPC, or track progress and hack on Plasma Active
I will explain here how you can get to a state-of-the-art Plasma Active, using what will eventually become the Tablet Edition of Balsam Professional. Balsam Professional is, unlike openSUSE, focused on end-users and the user experience on consumer-level devices. Balsam Professional is based on openSUSE, so you might well be familiar with many of the tools already.
What you need
An ExoPC, or a WeTab
An empty USB stick of at least 700MB
A USB keyboard and possibly a mouse
Note that the installation is possible to do by keyboard only, but a bit more comfortable if you have a mouse available. As the ExoPC does only have two USB ports, one of which will be occupied by the installation medium for the first part of the setup, you either need a USB hub, or a combined receiver for mouse and keyboard. If you don’t have a mouse or the means to plug one in, don’t worry, it’s not really hard to do. In this case, I’d recommend to install the updated kernel package from the KDE:Active repo as soon as the base installation is done, as that makes the touchscreen work, from that point on, you won’t need a mouse anymore. The process should take you about two hours, you might get it done quicker, but should be able to get it running within, say, one evening.
Getting started
The following points provide a detailed guide to installing Plasma Active and the Contour shell onto your ExoPC, using openSUSE. This process is also explained on the wiki, check there for the latest updates.
Install openSUSE 11.4: Download this image, Use “dd” to write it to a USB stick, or use the excellent imagewriter tool to handle this for you. after this step, you should have a bootable installation medium in your hands.
Insert the USB stick into your ExoPC, boot it and install openSUSE 11.4 onto the machine. It’s wise to enable auto-login, and possibly the SSH server during the installation, since this makes your life a bit easier later on. You need a keyboard for this.
The last line increases the priority (lower value means higher priority) for the Plasma Active packages.
Update your KDE installation to the 4.7 release, this pulls in the dependencies needed for Plasma Active. At this point, you still have a traditional desktop, you now update the KDE stack to the 4.7, and get a few updated packages as well (among them Mesa and a new kernel which is needed to make the touchscreen work and brings much better performance):
zypper dup
Accept all vendor changes.
Make sure the 3.0 kernel is installed (“zypper if kernel-desktop”), if not install it with
zypper in plasma-active:kernel-desktop plasma-active:kernel-desktop-base
Install Plasma Active packages on top. This will install the contour shell, some apps and configure your system to run Plasma Active, including tweaks to the defaut configuration that make the whole system more touch-friendly and suitable for mobile use cases.
zypper in plasma-contour-config
After this step, you have Plasma Active on your system.
Reboot to boot the new kernel, the Active shell will start automatically. If you get a black screen past login, use a keyboard and ALT+F2, “konsole” to get a shell and try starting “plasma-contour” by hand. If the command is not found, as root, do “ln -s /usr/bin/plasma-mobile /usr/bin/plasma-contour”.
Install additional packages, such as Calligra Active (package “calligra-active”) Kontact Touch (package: “kdepim4″) or the kdegames4 suite. Bringing you a nice collection of useful software.
Hop into the #active IRC channel on Freenode.net, tell us about your experiences and help others gettting started as well. =)
On Tuesday at 14:00 UTC and on Friday at 12:00 UTC, we will organize online install fests on #active (Freenode.net) where we can help you with installation issues, and where you can share your experience with others. Of course you’re free to drop by and hang around at any time.
(What? We’re back to tacky K-Names? Don’t worry, just using the K to reminisce us of our roots. :-)) The Platform 11 sprint in Randa is now in full swing, while relatively little code is being written by the 24-ish people here (and the occasional visitors from one of the other 3.5 sprints happening in the same building, at the same time), we’re very, very busy. It’s basically work until collapse, sleep and start again. Kevin is applying his kanban magic to manage the sprint and get everybody focused and synched. Kanban Magic means that we’re using a wall and a lot of post-it notes with tasks and topics on them, and we move those post its through different stages indicated by swimming lanes on the wall, froom waiting through design, review to done. The first note has just passed the review stage and is now in done state: our first accomplishment. :-)
As we’re working on issues central to how we all (KDE and Qt hackers) develop, I’m sure you’re impatiently waiting for results to pour onto the Internet. While our first focus is on personal interaction and using the facetime and “high personal bandwidth” to solve hard problems, you can get at least an overall impression of the direction of our work, as we’re tracking our results on the wiki.
What is really good and healthy to see is the number of different stakeholders (sometimes represented by the same person wearing multiple hats). This way we can make ‘reasonably sure’ that we take different point of views into account, and find solutions that work for us all. One might expect that this results in endless discussions, but in practise, most of us are on the same page, and where we’re not, we’re taking the time to sync up and see how much common ground we have, and how we can take advantage of that. There are people from up and downstream, from subcommmunities and companies, and people that all have different stakes in the KDE platforms and frameworks.
A big thanks goes to those who made this sprint possible: first of course to all the participants who are focused, motivated and working hard to produce good results. Then of course to Mario and his excellent team of volunteers who make sure we’re fed, warm, safe and taken care of. There is a number of sponsors without which this sprint would not have been possible, those are the Raiffeisen bank, Swisscom and openSUSE who generously chipped in to get us all together for a focused meeting to improve our foundations. Thanks to you all! We are certainly justifying the energy, passion and resources made available to us by working very hard to produce good results!
We’ve been busy bees in the growing Plasma Active team, so it’s time to post some progress updates. In case you forgot, Plasma Active is a KDE project to create a desirable user experience for the device spectrum, with its first focus to create a system suitable for tablet computers. In my first post about Plasma Active, you can see the basic shell running on a 10 inch Viewsonic Viewtab. In this post, I’m using a Wetab to demo the current state of Plasma Active. The Wetab is one of our test devices. It’s a nice target device since it’s Intel Atom-based, which makes building Plasma Active a bit easier, and thus shortens our development-testing-deployment cycles considerable. The Wetab can currently be gotten from German Ebay for 219€ + shipping, so it’s also quite affordable.
Back to the software, though. Our focus in the past weeks has been two-fold, we’ve done a lot of “small fixes” which greatly improve the user experience. The other class of changes is less visible at this point, but still fun and exciting.
Virtual Keyboard Layout
The virtual keyboard is using a layout that is more suitable for tablet computers, containing more characters on the first, easily reachable “page” of it. This makes text input a lot less annoying (let’s face it, touchscreens are not ideal for typing as they lack haptic feedback, so it can only become so good). There’s still a bunch of things that would make the keyboard better, and of course it has its fair share of bugs, but it basically works and isn’t too annoying, either.
Top Panel and Window Switching
We’ve also done some work on the top panel, holding access to network, power management, the calendar and a bunch of other things. While the panel would slide out a bit in our early versions to make the hit area bigger, we found that this intermediate step is not necessary, we increased the default height of the panel a bit which works nicely. The panel is still meant to be slided out, but for a different purpose. We will be putting a strip of window previews in there, replacing the current appswitcher sitting in the top left corner. Most pieces for the new panel-and-window-switching mechanism are already in place, but it’s not finished yet.
Snazzy new Activity Switcher
During Tokamak, Marco has merged a new, snazzy Activity switcher into Plasma Active. This activity switcher offers a wheel-like interface which you slide in from the right. It has previews (or rather post-views ;)) of your activities, and you use a small slider on those previews to switch to an activity. (These activities right now provide spaces for different sets of widgets, but will be given more meaning thanks to the Contour project, which develops a semantic workspace framework for Plasma Active. As all the parts necessary to make basic activity handling in Plasma Active work, we’ve decided to merge this new switcher already, since the “old” one was really very basic, and wasn’t quite so intuitive, due to lack of visual feedback (i.e. previews).
Try it!
open-slx has created a new Plasma Active image, which can be run live off of a USB stick, you can find the latest version here (spot the plasma-active.current.iso). There are also openSUSE and Meego packages available (the latter being a bit less mature, but we’ve made really good progress in the past days.)
If Plasma Active has spawned your interest, or you would like to find out how you can get your software to run on and integrate well with Plasma Active, get in touch with us, either on IRC, or via our mailinglist. You can find more information on the Plasma Active pages on communitybase.
On Thursday, I’ll be travelling to Berlin for the KDE UX sprint, which is kindly hosted by relevantive in their office in the heart of Berlin. I’ll be meeting Nuno, Celeste, Hugo and a few others there, and we’ll be making plans. Topics are the human interface guidelines, getting more designers involved with KDE, and of course Plasma Active.
A few days after coming back, hell will break loose in Nijmegen, as the Plasma crew holds their Tokamak gathering here. Here means at our new house in Nijmegen in the east of the Netherlands (which is in the west of Europe ;)). I’m really looking forward to having my fellow Plasma hackers here, especially with all the excitement, new ideas and concepts coming along with Plasma Active. I’m sure it will be an epic Tokamak, and a really long one, too. Between first arrivals and least departures, there will be a whopping 12 nights. We’ll likely be doing an Open Day, so if you’re in the region, drop me an email if you’d like to come by to see the magic happen.
Speaking of Plasma Active itself, it’s off to a good start. We’ve spent crazy amounts of hours in very little time before I announced it on my blog, and we kicked off a surge of blog posts about this subject — with more to come. I’m really happy with the positive interest it generated so far, very promising.
With the past two weeks spending most of my time on documentation, packaging and communication, I got back into hacking mode today, and polished up my small metadata engine I had started writing not long ago. It’s working now, you can query all kinds of resources, either by filename, URL, Nepomuk Identifier or simple query term, and it gives you back a list of Nepomuk resources and their metadata. It’s pretty simple, but very powerful. It already provides most of what you need to write a simple filebrowser, or search widget in Plasma Quick. I’ll write a more detailed blog post (including screenshots) once I’m more happy with it, also visually. The basic metadata engine is already in master, and will be appearing in the next update of the Plasma Active packages, probably tomorrow. Now, back to hacking. =)
Today, I’d like to announce to a wider audience a project we have been working on in and beyond the Plasma team. Its goal is to “Create a desirable user experience encompassing a spectrum of devices“, and it is called Plasma Active. A couple of things make Plasma Active special. First, the driver is the desirable user experience. That means that we want to create something, people want, and people want to use. It means we are less technology-focused, but are taken a user-centered approach. Second, we are not targeting a single device, or a narrowly-defined class of devices. Plasma Active is made to run on a spectrum of devices that make up the user experience together. Devices change, and so does the way the user interacts with them. By strongly separating data and visualisation / interaction, we do not re-invent the wheel but adapt to the requirements and expectations of a device, and about how devices work together for the user.
Running Plasma Active
We have a basic, Plasma-based shell right now, which runs on three target devices — and probably some more, but that’s what we’ve tested so far. It performs well, runs stable and is usable with a touch-screen. While Plasma Tablet is quite fun already, do not expect release quality yet, as it is a snapshot of our efforts. Find the download location for the Balsam Professional live image on the wiki.
open-slx has created a Balsam Professional live image based on openSUSE 11.4 running Plasma Active. open-slx (my employer) are developing Plasma Active for openSUSE in the openSUSE Build Service. We’ve also created packages which can be installed online on top of openSUSE 11.4. You can find installation instructions in our Wiki, also for Meego.
Of course you want to run Plasma Active on a ‘real’ device, we currently recommend either the ExoPC (WeTab), the Lenovo Ideapad, or a Viewsonic Viewpad 10. You can find instructions for devices in the Wiki
The demo video shows Plasma Active in action on a Viewsonic Viewpad 10.
Status
There is still a long way to go. We’re missing key functionality, default applications, optimizations all over the place, and more. There is nothing fundamental that holds us back to bringing the full experience users expect to tablet devices, based on our well-known, beloved, proven software stack. We are focusing our first release, which is planned for September already, on tablet computers.
Since fixing a bunch of showstoppers over the past two weeks, I’ve actually started using Plasma Active for some light reading tasks (mostly web and RSS), and I’ve got to say: It rocks your socks. Being able to use a tablet computer which is based on Free software that you created yourself, is real fun. I’ve also handed it to friends who came by, and while they understood it’s an early prototype, I had a really hard time getting my gadget back. And that is only just the beginning. We have an excellent base to build a complete experience upon. In other words, it’s the perfect time to jump in and become part of something great and to help it also making it something really big.
Different goals need different processes
When we put the pieces for Active together, it quickly became clear that if we want to succeed, we also have to rethink some of our collaboration processes. One of my pet peeves has always been that different essential parts of what the user gets in her hands come from different teams. If we want to put something desirable into the hands of our users we need to pull in the same direction. While we needed different skills, these skills have to align in how they’re applied. This makes communication more natural, leads to a more focused process, and ultimately a better result. It’s clear that such an endeavour will only work if enough people in our communities, and the communities around it think that this is a worthwhile thing to spend their time on, and that we can get the people that do to pull in the same direction. The good news, however is that we’ve been able to create a stable platform to do this, in terms of tools, processes, collaboration models and not at least software. That platform is Plasma Active.
Sounds interesting?
If you want to help us shape Plasma Active, and bring its vision to reality, we would like to invite you. Start with having a look at our list of tasks, and if you find something you can help with, tell us, subscribe to the Plasma Active mailing list, or join #active on Freenode’s IRC network. We have documented our ideas, concepts and processes in the wiki.
In the coming weeks, we will keep you updated about Plasma Active’s progress, and we will be able to reveal more of our vision as we give Plasma Active shape by making it become reality.
A question that has bugged me for some time, is “how we can bring our creations into the hands of more users?”, and how we can show the world that a truely open and community developed system can bring great value to more people. How can we overcome the technical barriers that hold back so many people from benefitting from our hard work, all the genius, love and creativity we put into software. Since my first contact with Free software, Linux openSUSE and KDE, we have done some very solid work. We have technically caught up with Microsoft, and are delivering a product that is up to par in many aspects, and better in many more ways. While we have booked immense successes, we have not reached the goal of making the Linux desktop ubiquitous in the desktop market. In a world of iPhones and Android, we even see closed development models based on similar technology as ours being a big success, market-wise, but failing to deliver the full Freedom of a community-driven development model to end users.
Stormy weather on a calm sea
The past years’ development has completely changed how users interact with their digital environment. Where we used one desktop computer for all of our digital needs only a few years ago, there is a wide range of devices for specific use-cases now. This (I think very positive) development has widened the spectrum of devices our software can be used on. It has also effectively broken Microsoft’s monopoly in the market, which is now much more open: concurrent products such as Windows, iOs and Android. Looking at both options, many users experience a gap, however. With the market especially for tablet computers being brand-new, there is very little choice for users. If you want to have a tablet computer today, you can get an iPad in return for your soul or get a blown-up phone built to add your most personal data to The Big Index. If you’re of a more patient nature, you can cross fingers while waiting for an evidently upcoming surge of new tablet devices. If you’re interested in both, control over your data and control over what you run on your machine, bad luck.
While moving away some of their Internet use to other devices with more a more clearly defined purpose, and starting to use the Internet in completely new ways, many users have also found out that computers != Windows ™. New methods of input, and graphical effects allow for a more ergonomic use of all that’s out there. Dramatically increased user expectations demand more intuitive, beautiful and elegant user interfaces and ways for interacting with contacts, content and the web. This demand is I think very positive, for two reasons: users are much more willing to try new UI concepts, which leaves more room for innovation to creative people who really want to do something better. One positive aspect is that the demand for an awesome user experience makes the software running on the device, and the services it is offering more critical the desirability than the hardware, comparatively. Interpreting this as “the power to shape the product is now in the hands of the software developers” is unfortunately (I am a hacker) also very wrong. Let’s get back to that later.
Back to our question (remember, that was: “how can we bring our creations into the hands of more users?”), this leads me to believe that a locked-down market for end-user software is a thing of the past. To no surprise, increased competition comes with more pressure to deliver something really great.
Genetic advantage
Having studied, participated and helped shape Open Source development processes for a few years now, I’ve come to conclusion that the Free software community has three strengths that are critical to its success:
Economic force: We share resources. While we spent much of the past ten years to catch up with Microsoft on the technical side, the Free software development and licensing model simply obsoletes many closed source options. This basically means that you need a really large internal workforce and a lot of appeal to make your product competitive, or that you have to plug into the resources of the Free Software community.
A different agenda,: we are not primarily driven by monetary aspects, unlike our competitors, so we can for example license our software in a way that might not be economically effective at first, but provides much more long-term value. Not being limited by return of investment type obligations, our different agenda often shows that we can address a class of problems where “what is good for the user?” differs from “how do we make money out of that?” completely much better than our competition.
The Magic Spark: Open communities are much more receptive to healthy diversity. We’re many, and we all bring different things to the table. The chances of something genius happening are simply much better in an open and friendly environment, than behind closed doors.
Our chronic fragmentation issue
One of the really hard problems we have to solve though, is the fragmentation. Due to the diversity, we don’t work enough as a team, and while often share the same values, our vision of how our creations end up in the hands of end-users differ wildly. To solve the fragmentation, we have to have not only shared values, but also a development process supporting our vision, and we have to have a shared product vision. Yes, product vision. As bullshit-bingoesque as that sounds, the simple truth is that we have to use our strenghts to create something desirable, we probably won’t enlighten many people with the great value Free software can bring to the table with religion. On the positive side, desirability works very well for me personally. Much of what I do is driven by a sense of creation, and if the output is something that others want, it gives me the accomplishment of having created something of value. Desirability is the primary driver for this, it’s both an excellent product vision, and a fine goal to strive for personally. There is one conceptual mistake about the fragmentation issue. The problem is not that the Linux community as a whole doesn’t work together, the problem is much more that not the right people are working closely together. The real problem isn’t fragmentation, it is the lack of full-product-thinking.
There is much more to the fragmentation issue, though. We’re trying to analyze this problem not from our own view, but from what is necessary to achieve our goal. While we have had limited success to attract UI and interaction designers, that excel as much as many of us do in our own fields, we have yet to shape the process in a way that is both attractive to people who can contribute design expertise, and helps them put their energy to good use. If you have ever seen a graphical artist cringe, when you showed him your finished application and asked him to now make it beautiful, that was a symptom for this brokenness in the process. So in those fields where you’re honestly lacking manpower, you need to work twice as hard to attract new blood. You need to cover the whole process, so this is one of the problems that need solving. Recognising that you lack this expertise (by asking yourself all those hard questions) is the first step. Communicating that you are open to such participation is an obvious second one. Proving that you actually are, and making that visible helps you get further. Defining yourself in terms of a common denominator helps. If you want to reach non-developing contributors, you might want to stress the free culture aspects of your project, if you want to attract designers, make sure people see that design plays an important role in your project. Offer and prepare the tools designers need to do their work well. Paraphrasing, if you ever had to ask a graphical designer to use a compiler, you’re doing it wrong, and you need to fix that.
Natural selection
Once all of the above is realised, the really hard part is of course to find this shared vision of something desirable. There are a couple of interesting aspects around this, many of them have to do with creative and outside of the box thinking, and about creating an environment that supports the growth of these ideas. Let’s look at the process-side of things, however. Statistics tell us that it’s much simpler to find a shared vision among a bigger group of self-selecting individuals than among a smaller one. This means that we have to look across project borders, across comfort zones that have come natural to us — from both sides. From another point of view, to create something desirable, we have to apply the same vision across all aspects of the software stack. This means we have to work from top to bottom. We need to build applications that users want, user interfaces that are beautiful, modern and adaptive, we need to get the technology underneath right, and we need to find suitable (by many measures) devices to run our software on, and it it also encompasses thinking about our collaboration models, taking the good parts and combining them with new insights, tools and processes. It means we need to think in creating a complete process that covers all these aspects from creation into the hands of more people. A self-selecting group has one nasty, but natural attribute: it also means that some people do not take part. This is of course fine, if something is not your cup of tea, that doesn’t have to keep others from drinking it with great pleasure. Support can in some cases be as easy as letting go, and at least not providing pushback to something that might — or might not, this is not a no-risk game — create something truly great in the end, at least for some. Different priorities, agendas or simply envy can cause unproductive friction.
On the more cheerful side, such a group is absolutely killer to work in, being able to work towards your goal among a group that is heterogenous in skill and origin, but homogenous in the direction to take, you can pull amazing amounts of weight. This makes it (relatively) easier to make a difference, and your work is more likely to produce something that makes you happy. A friendly environment and good communication that costs little but gives back much energy is critical factor to create a positive feedback loop, a critical mass to get off the ground, momentum to move and keep moving your dream to completion. While participating early requires recognizing such a vision, and probably a certain willingness to take a risk, to endure uncomfiness in the beginning, it allows you to shape important aspects of that vision. A vision only goes so deep, making it come to life reveals all its facets, to you, but much more to those that hold your creation in their hands and recognise its value.
Unicorn or horse?
It is a common myth that great ideas just spring into existance. While there surely needs to be a spark, turning great ideas into a success is also very much hard work. Without checking my facts, I’d say it’s a reasonable assumption that all the years of hard studies, and understanding many things new and old, crediting the apple for hitting Isaac Newton is probably wildly irrational. Conversely, you might study all your life, and never get hit by the proverbial apple. There is a way to make this apple more likely to hit you, however. Obviously, being well prepared, with all the tools and knowledge needed is a first. But you also need to answer all the hard questions. You need to look at the complete spectrum of aspects of your potentially genius idea. It means leaving your comfort zones, talking with others, being receptive to their ideas and incorporating them into your vision. That sometimes means that you have to take a step back from that concrete picture in your mind, and rethink what you are really looking for. This can be very hard, but doing this in a team of people with different background can help a lot (note that not everybody in this team of domain experts needs to take part of your group, you’re after the input they provide. You don’t have to convince them, you have to find the right answers to the questions they pose. Spotting a unicorn among a large herd of horses is much more a self-reflection game than a convince-and-defend battle.
At the same time, you have to recognize when people give you input without actually wanting to help you understand all the details, sometimes you get advice, even pushback because someone does not think it is good to drive attention away from something that is more important to them. The truth lies in the middle, of course. While you have the right to enthuse people about your ideas, you also have to play nicely. Notwithstanding altruism and the general rule of “don’t be an asshole”, being too aggressive about your own project will drive others nuts. The more success you have, this worsens. Higher trees catch more wind. In a way the amount of shit you see flying in your direction can be seen as a matter of success. It’s generally not productive for your own goals though to actually engage in this way, unless absolutely necessary. Check twice to be sure. Negative energy can have a desastrous effect on your productivity and on the joy and direct motivation you get out of your work, and that is in fact true for everybody directly involved. Ignoring the naysayers for naysaying is often a much better way to keep sane, than constantly paying close attention to it, trying to find the one good point they might have out of a stream of dung coming your way. It helps a lot when you recognize these patterns, learn how to mitigate communication going awry, and deal calmly and cool with potential real issues at hand. Do not forget to put mechanisms to shield yourself in place, in case it runs out of control. Do not underestimate that creating and maintaining a playing field that is fun for all to use is critical. Try to not make the neighbours angry, either.
Communication and scalability
Now let’s imagine you have this great idea. You know that you’ve something big in your hands, and for the sake of simplicity, it’s a truely genius idea by all reasonable and objective measures. In other words it truely kicks ass. Moreover, you have figured out most of the technicalities, so we even can be sure it’ll actually work. This just has to become a success. But how?
I’ve seen some really great ideas not coming to fruition because a key person ran out of breath. Imagine being a 17 year old kid, becoming a rock star overnight. Suddenly, playing the guitar exceptionally well is not enough anymore. You have to make sure that all the interest doesn’t fire back on your ability to ‘to your thing’, you need to think about how to deal with all the sudden interest. It’s a good idea to prepare that early on, so that you don’t have to explain everything to everybody in great detail. Writing down all the answers to the little questions you answered is a very much needed thing. If you want to convince people of a great idea, you have to give them the chance to understand these answers. If you can’t keep up with answering people’s questions, and you answer the same question in great detail over and over, that might be a sign that you should have put together an FAQ, or something that presents your idea in a more comprehensive way, and in a way that is easy to understand from the point of view of someone who might only spend a short amount of time seeing your idea. Clear, targeted documentation helps to mitigate the ‘running out of breath’-problem.
… aaaaand?
Now you expect a real conclusion? I certainly have something on my mind already. (What would your own little private view of the world be without the Answer to the Ultimate Question of Life, the Universe, and Everything, after all?) But let’s leave that for another day, maybe a Thursday.