Desktop Shells, Usability and Trackers. Oh My.
A while back, I read with great interest [Vincent’s blog entry](https://www.vuntz.net/journal/2008/10/22/494-desktop-shell-from-the-user-experience-hackfest-general-overview). I also heard from my fellow Canonicalites about the progress made the GNOME hackfest. I am rather interested in the opportunities before us with the GNOME platform and a new approach to the shell, so when I read [Owen’s update](https://blog.fishsoup.net/2008/11/22/gnome-shell-status/) I may have actually drooled. Instead of grabbing a tissue, I instead grabbed `jhbuild` and built said shell. Instructions for the brave are [here](https://live.gnome.org/GnomeShell). Its actually pretty simple, so no real bravery required.
Things have changed a lot in computing in recent years. Back when GNOME 2.0 was released we were not faced with the plethora of use cases that we are confronted with today. Social networking, online services, the cloud, collaborative editing, (micro)blogging and other such buzzword compliant technologies are now a staple in not only the life of technical types like us, but regular people: even my dad has a blog. In recent years the industry has pointed its innovation-ray squarely at people and what people do. We are no longer expected to dance to the computer’s tune, but it dances to ours.
The GNOME community has been on something of roller-coaster reacting to this, and the subsequent potential changes in focus and interface concepts. Many have called for GNOME 3.0, or whatever it is codenamed this week, but for too long it might as well have been called *Project Vaporware*. GUADEC after GUADEC it was discussed, there were many ideas, but no design document, implementation plan or approach. I even talked to Stormy about personally taking some time off and getting some key people in the same room to discuss this. Shortly after those discussions, the hackfest happened (nothing to do with me), and I am tickled pink at the opportunities that have arisen from it.
On this topic, I would like to raise an important question, and one that I would be delighted for the GNOME community to think about, and the wider Free Software community to think about too. Your comments, as always, are welcome.
In recent years we have not only seen a change in focus in how computers are used in people’s daily lives, but we have seen an evolution in community. Years ago, if you wanted to be a part of our community, you really needed to be a hacker. You needed to be able to code in C and know what on earth a memlock or a refcount is. Beards were optional, but generally recommended. As time progressed, out community diversified – documentation writers, artists, advocates, testers and more came on board. One such role that joined our merry bandwagon has been *interaction designers*.
Matthew Paul Thomas, Seth Nickell, Celeste Lyn Paul, Calum Benson, to name a few. Across our community we are developing skills and expertise in how people work with interfaces. I myself have always had a keen interest in this area, but it has largely remained a hobby. Those who commit the majority of their time to this important science have read, refined, explored and questioned the nuances in how we connect human psychology to practical interfaces. This kind of input is *incredibly* valuable. We need to be encouraging these contributors to be involved in the design stages of our interfaces and applications, be contributing perspectives on high-level goals and significant and highly visible areas of the stack such as the gnome-shell, be involved in consistency across applications with style guides and toolkit design, and importantly, be regularly testing and evaluating existing experiences so that we can learn more about where we stand today in an effort to make tomorrow a more usable place. A good example of this is Matthew Paul Thomas’s [Empathy and Pidgin usability evaluation](https://mpt.net.nz/archive/2008/09/07/empathy-pidgin). Those kinds of assessments are superb.
Few would disagree that these contributions are important, but we have not yet figured out how to merge these contributions into the development process. Unfortunately, all to often, these valuable contributions get lost, seemingly ignored and never implemented. The reason for this is twofold.
Firstly, when an upstream developer receives a set of interface recommendations and changes from an interaction designer, for them to be implemented it requires that he or she either (a) agrees with those recommendations or (b) has faith in the designer and their recommendations. I would like to imagine that most upstream developers would be able to put their faith in the abilities of the designer, trust their judgement, and implement designs that they may not be 100% in agreement with. I suspect not though. I suspect that in all too many situations, upstream developers receive good solid designs that they may not really agree with, and despite resounding evidence to suggest the design is a better approach, they choose not to implement them.
This though leads us to the crux of the issue. What we need to fix is how interface design recommendations are communicated and recommended to upstream projects and distributions. In software, if something goes wrong, you can file a bug in a bug tracker. If you need to communicate with an upstream, there is a mailing list. If you need to obtain source code, there is a source repository. Where though is the natural home for communicating interface design ideas, fixes and discussing and debating common problems in existing interfaces? The popularity of bug trackers has been largely due to the structured nature in which the data is stored – they are highly searchable and work well with a developer’s workflow. This has made them more suitable than general communication channels like mailing lists. Bugs appear on mailing lists, but participants almost always recommend the poster to file a bug report.
We need tracker for interaction design fixes and proposals. We need to understand how to structure, communicate, discuss and implement interaction ideas more effectively. I would love some interaction designers to sit down and hammer on this question for a little while. How can we not only structure ideas but also tie them elegantly into actual development? How can we structure and come to a conclusion on an interaction concept and then hook in the implementation of that concept? An ideas forge is not enough – an organised list of never-implemented ideas is not much more useful than a disorganised list of never-implemented ideas. We need to understand how to smooth how the interaction rubber hits the development road.
I think this is an important problem for us to solve, and if we get it right, we could reap the benefits of so many brilliant minds out there whose brains are wired to understand interactions as elegantly as possible. Just imagine what could be possible.
Jokosher Interview
[gnomedesktop.org](https://gnomedesktop.org/) recently did an [interview with the legendary Laszlo Pandy](https://gnomedesktop.org/node/4067) who is one of the two lead developers of [Jokosher](https://www.jokosher.org/). It is a great read. Go Laszlo!
Jokosher has made some insanely great progress in recent months – it is solid, stable, and multi-channel recording is largely complete. I am hugely proud of everything Jokosher has achieved, and hugely proud of the continued efforts from the folks still involved (I am not so involved anymore in the project due to other commitments).
This, combined with the rocking efforts of Edward and co with [PiTiVi](https://www.pitivi.org/wiki/Main_Page) are helping desktop multimedia production be an area in which a rocket science degree is no longer required. We should thank the unsung heroes of the GStreamer world for making much of this happen.
I still remember fondly how I felt at GUADEC in Spain at the Fluendo beach party, and after Johan’s hi-jinx, I ended up with Wim Tayman’s badge. Becoming Wim Taymans for an evening is like being touched by god…
A question…
Knock knock?
The Diversity Level
In the past I have talked quite a bit about diversity in this blog. Diversity is critical to the future development and growth of communities, and the strongest communities are ones with a strong sense of equality and diversity, and a governance infrastructure that supports and celebrates that diversity.
Importantly, diversity is closely connected to *evolution*. The essence of diversity is in all of us, but the social acceptance of said diversity is a slower moving animal. There are obvious large social progressions in diversity – gender and race equality being one such example – but within every community and human grouping we see diversity and evolution moving forward, hand in hand.
Typically when talk about diversity, we use these common examples. Gender. Race. Sexuality. Class. Although important, these poster-children of diversity can sometimes focus the attention away from more subtle and potentially potent forms of diversity that we can encourage, explore and celebrate.
George B. Graen, author of *Dealing with Diversity* talks about these different types of diversity that we have before us. His interesting hypothesis is that not all differences are equally relevant or important in all circumstances. He broadly divides this diversity into *surface-level* diversity which are readily observable characteristics such as the one we have just discussed — race, gender, or age, and *deep-level diversity* which points us towards important but less readily transparent entities such as personality, values, and attitudes.
Now we are rolling.
I am really keen to explore how we can build diversity in these areas of personality, experiences, perspectives and beliefs. Often these more hidden kinds of diversity teach us life’s most valuable lessons, and we typically learn these lessons for whom we share a deep-level of diversity. I am not suggesting surface-level diversity is unimportant, and I want to be clear here, I am not talking about equality, all equality is important, but I am keen to explore how we can grow this sense of deep-level diversity.
But is deep-level diversity a productive and pro-active area in which to focus our efforts? The cards may well be in our favour – Graen suggests that surface-level diversity appears to be waning:
> “In a study of 45 teams from electronics divisions of three major corporations, Pelled, Eisenhardt, and Xin (1999) found that the effects of surface-level diversity (age) on emotional conflict diminished as a function of team longevity. Similarly, Chatman and Flynn (2001) found that demographic homogeneity (race and gender) was less predictive of team cooperation as team members interacted with each other”.
Interestingly, at the same time, and in another research study, deep-level diversity is growing:
> “In a study of 144 student project teams, Harrison, Price, Gavin, and Florey (2002) found that surface-level diversity negatively affected early cohesion in the team. Over the course of a semester working together, surface-level diversity became less predictive, whereas actual deep-level diversity (measured by conscientiousness, task meaningfulness, and outcome importance) and perceptions of deep-level diversity became increasingly important to team social cohesion and performance”.
Although the experiment may seem a little abstract, Graen suggests that “*as team members interact, attributions about underlying differences based on race, gender, and age are likely to be minimized; however, the underlying differences in terms of personality, values, and attitudes are likely to have an increasingly negative effect on team cohesion and performance*”.
In a nutshell, as a community, diversity is everywhere. We have so many opinions, viewpoints, perspectives, recommendations and other reactions to stimulus, and at every step we need to foster and encourage open and frank exchanges of debate, and to bring balance to this debate. The Ubuntu Code Of Conduct, one of the most important documents in the community that I frequent most of the time, draws attention to understanding and respecting this deep-level of diversity, but the Code Of Conduct is sometimes misinterpreted as simply” *don’t be an asshole*”. It means far more than that – it encourages us to not only take responsibility for our actions and our reactions, but to also use this diversity as an opportunity to learn and grow; turning differences into opportunities for personal development and learning. If we are ever going to win this fight, we need to cherish and respect this deep-level diversity. The importance of this is not something we can enforce with actions, bullet-points, success criteria or other organisational devices – it boils down to us always remembering why we are doing what we are doing, and standing shoulder to shoulder, connected by our diversity to help us grow and take on the challenges before us.
Announcing The Ubuntu Hall Of Fame
“*May the HOF be with you*” – Obi-Wan Kenobi
A few months back I met in London with Daniel Holbach, Graham Binns and James Westby for a short sprint. I had flown Daniel over for the purposes of a face-to-face catch-up and to record some MOTU videos for the [Ubuntu Developer Channel](https://www.youtube.com/ubuntudevelopers). It was a productive few days, and in our many meetings we sowed the seeds for an idea which I am proud to announce today.
As I have mentioned in previous posts, one of the most important aspects of community management is in breaking down workflow and understanding how to improve it. We have done this in a number of areas in the Ubuntu world with bugs, patches, LoCo Teams, events and key parts of the wider community picture. When we launch any initiative we pay close attention to the growth and impact of that initiative on the community and this often gives us an insight into the rock stars in our community – the contributors who do lots of good, measurable, referencable work.
When I meet with the horsemen, we regularly talk about these rockstars in our community. On every call we get jazzed about their contributions to Ubuntu. Although we knew about many areas of contribution – people who are rocking on 5-A-Day, new MOTU and core-dev developers, people who are doing great work in the forums etc, our approach was somewhat incomplete. Although we horsemen focus on these rockstars and none of this information is private, the figures and statistics that show off this good work is spread across different places. In addition to this, we were concious that we are always only seeing part of the picture – what about rockstars in translations, upstream bug triage, the sponsorship queue, Launchpad contributors etc? Every time someone rocks a part of our community, they should be recognised.
This raised another issue – some people can be *measured* as rockstars – we can count their contributions in the community, but some people span a range of different kinds of contribution, many of which can’t be measured statistically. We wanted these people to be recognised as well and write a more personal showcase of their efforts. With these driving considerations, it was now time to be inspired by Guitar Hero. I know, I know, that may seem a little odd, but stay with me…
There are many fascinating communities out there outside of Free Software, and gaming comunities offer many insights. One such example is Guitar Hero – the online collaborative play aspect of Guitar Hero an interesting part of how they have built a faithful following of players. Where this really piqued my interest was in how high scores play such an encouraging role to members of that community. Players really put in the time to practise and get their scores up and enjoy the sense of peer respect that results from this in the Guitar Hero fishbowl. Interestingly, when we launched 5-A-Day, complete with the contributor and team rankings, we also picked up on a strong sense of pride by participants in their scores. We have also seen similar results from pride over karma in Launchpad. Our community is built on pride and respect, and I was keen to explore how we could centralise this.
While in the meeting room, I grabbed a pen and started fleshing out a design. Daniel, James and I then set to refining the functional and visual design and I took a snap of my penmanship:
After a number of follow-up calls, a functional specification and some testing we are now proud to announce the [Ubuntu Hall Of Fame](https://hall-of-fame.ubuntu.com/):
Many thanks to Stuart Langridge for producing the design, Daniel Holbach for plumbing in the data from Launchpad and Kenneth Wimer for producing the snazzy Rockstar button.
Let me explain a few elements of the Hall Of Fame. Firstly, as you can see, the Hall Of Fame includes a number of boxes that look like this:
Each box contains the statistical data about the topic for the box, but it also contains a simple single-line description detailing what the data shows. To find more data that is related, there is a *More…* link – click that to drill into more stats. The final point to note is the (i) symbol in the top-right of each box – this links to a page that outlines how to get involved in that part of our community.
Another key feature of the Hall Of Fame is the *Featured Contributor*. Here we will be showcasing contributors across the community that are doing excellent work. Here we will write a little blurb about what they have done, their achievements and their personality. Importantly, we have added a feature in which you can click the *Thank
My hope is that the Hall Of Fame will quickly become a showcase in which the wider community is proud to be featured on, either as a *Featured Contributor* or inside one of the many boxes. We have many ideas about how we can expand and improve on the site to foster this sense of pride, but we are keen to hear from you all with your ideas about additional features that you would love to see, and importantly, what additional HOFBoxes (those boxes with stats) that you would like to see. Which areas of the community should we be showcasing, and how would you measure them?
![Want To Be a Horse[wo]man?](https://archivedblog.jonobacon.com/wp-content/uploads//2023/03/clark-tibbs-oqStl2L5oxI-unsplash-1080x675.jpg)
Want To Be a Horse[wo]man?
Just a quick note to let you all know that I am still looking for a fourth horseman or horsewoman to join Daniel Holbach, Jorge Castro and I. The role involves reporting on the progress and growth of the Ubuntu translations community, growing and expanding the community, working with LoCo teams and working with upstream translators and projects. If you are smart, hard-working and think outside the box, we want to hear from you. Also, just for the record, an appreciation of death metal is *not* a pre-requisite. 🙂
Curious? Well, go and [read the job description](https://webapps.ubuntu.com/employment/canonical_UTC/) and follow the instructions to apply. Please *no not* contact me directly to make your application, just follow the instructions. 🙂
Lowering The Theming Barrier with CSS
[Andreas writes](https://www.andreasn.se/blog/?p=91) about some of the work going into the GTK CSS Engine.
> “Back at GUADEC in Birmingham, when Garrett proposed using css-markup for widget themes, I thought it sounded a bit too cracky to be doable. Rob’s recent work, however, looks really sweet and since every designer and his mother out there knows css, this is a great way to lower the barriers of theme creation”.
The basic idea is that GTK (and as such GNOME) themes can be created using the well established Cascading Style Sheets technology that web designers the world over are familiar with. This is something I was [blogging about](https://archivedblog.jonobacon.com/?p=572) back in 2005 after some discussion in the Tango project (unfortunately, the original link to the discussion seems to be dead).
What excites me about this is not the seemingly obvious technical coolness of the idea, but the fact that it breaks down the barrier to implementation and experimentation in an important, creatively fuelled part of the desktop experience – themes.
Themes are objects produced as a result of artistic creativity. Great themes are constructed by those with a strong eye for colour, interaction design, and aesthetics, and an understanding of the emotional and practical effect of this sandwich of visual considerations. The problem is that different brains work in different ways, and visually creative thinkers typically communicate their art via more direct means – painting, sculpting and drawing – they use their hands to produce the art directly. Abstraction and interface typically has no place in the traditional creative arts. Computers have made this kind of artistic expression insanely more complicated, with paint packages, 3D modeling software and other applications, all expecting the artist to understand the rules of interaction defined by the computer. We have since produced a generation of artists who have figured out how to squeeze their creativity into this computer shaped box.
What excites me about the CSS GTK engine is that it makes logical sense to build on a body of knowledge that the creative community has already worked hard to aquire. Artists and designers the world over have spent years learning CSS and figuring out how to represent their creative intentions via this language. The language and its structure has been refined over the years based on feedback, and is now an elegant and well understood means of visually depicting content for different types of media – screen, print, mobile and more.
I believe that a CSS driven theming engine is going to open up GNOME theming to a whole new demographic of potential contributors, and sites such as [GNOME-Look](https://www.gnome-look.org/) are going to become the bubbling pot of exciting new visual potential in the desktop. I hope that our friends in the Qt and KDE world are going to do the same.
Even though I am not a part of the work going on in GTK CSS support, I would urge the developers of this support to focus their efforts on one key area though – soliciting feedback from artists. To make this a success, artists need to help drive the CSS support to be as flexible and complete as possible. Andreas talks about this intention already:
> “Rob is in great need of designers to test these things out in the wild though, so if you’re a designer with css knowledge who always wanted to create widget themes, don’t hesitate to check it out from svn and give it a shot”.
The key here is going to be simplicity – artists need to be able to test the software easily and communicate their thoughts just as easily. I would urge you folks to produce distribution packages so you can bypass the expectation of using svn, and have a clearly defined process so artists can share what challenges they face and how support could be built in to improve this. This could be achieved by website forms, artist interviews, assessment of CSS themes and surveys.
There are so many areas in which we can make the many collaborative opportunities with Free Software easier, and I am excited that this important area is getting such quality focus. Great work folks. 🙂
On Feedback
Ubuntu is a big project. Hundreds of teams, thousands of contributors, millions of users. Every day the project grows by a fraction of a percent, but the fraction is bigger than you might think. With such a wide ranging and diverse community, growth in the project happens at an intense rate. We are not the largest collaborative project in the world, but we are not small, thats for sure.
In addition to this existing Ubuntu-focused diversity, now let us roll into the mix the deep relationship that Ubuntu has with a great many other Open Source projects. There is the obvious connection to Debian, but we also have an extensive relationship with a range of upstreams – GNOME, KDE, X.org, OpenOffice.org, Mozilla and more. With thousands of Ubuntu contributors interfacing with thousands of upstream contributors and millions of users, the jigsaw puzzle is rather large. With so many interconnections between communities, one of the problems is that a person can only see so much of the picture any one time. Part of the skill of a community manager is to try and see the full picture.
This has been something on my mind for a long time – how can we see the great many interconnecting lines between different parts of community. In effort to make progress this area, I have worked closely with my team to build some metrics to understand our community. These metrics are mostly based around bugs, but they give us a solid idea of how to see additional parts of the picture. But metrics are one thing – they show progress and they show the timeline of progress, but they don’t provide good solid *feedback*. They don’t help us to *fix things*.
Like any Open Source project, we get our fair share of criticism about what we do. Although I cannot guarantee that we will always make the right choices every time, I can guarantee that we make every effort to make the right choices based on informed evidence. The work that my team and I have been working on recently is to help better make those choices. To achieve this we have been on something of a feedback shopping spree.
Much of this started back when Jorge and I started work to improve our upstream bug story. As I talked about in [previous entry](https://archivedblog.jonobacon.com/?p=1302), bugs are an important mechanic in how Open Source projects communicate and we want to make all of the points of interaction as painless and as smooth as possible. We broke down the workflow and discovered we needed to know about the problem, and with this mind we threw out an upstream survey to some upstream projects that we work closely with, and a general survey that anyone could contribute to. We then evaluated some of the comments from the survey and continued work to develop the upstream report. The feedback helped us to craft a tool (the upstream report) which has helped us focus our efforts in the right areas. Subsequently, we have seen a marked improvement in linked bug reports between Ubuntu and upstream.
As part of this feedback, we were told that our patches could be better. Patch quality typically falls into two key areas – *quality* and *discoverability* – people want quality patches that apply easily and they want to be able to find them intuitively. We have since made this a priority and I asked Jorge to post a patch survey to a number of upstreams and also solicit more general feedback. Jorge did an excellent job here, and this survey will help us drill down in more detail how we can improve our patches. The aim here is to firstly produce best practise around patches – to help our community and our staff at Canonical not only produce technically proficient patches, but to understand what upstreams like to see in a great patch. Thanks to everyone who has participated so far. I am looking forward to the outcomes of this research and its impact on how we work with upstreams.
Feedback is a useful tool and I recommend all Open Source projects to make use of it. When sitting down and exploring ways in which you improve your governance, processes and methods of interaction, it is tempting to become to wrapped up in technical processes. It is tempting to try and produce technical solutions to social problems, but many of the problems and issues we can face within a specific community or the wider Free Software world are cultural, social and habitual divergences in practise. Feedback, and the simplicity of providing objective feedback can be a fantastic antidote to the production of unnecessary processes that attempt to solve half-understood problems. Bureaucracy is the ultimate enemy, but decisions without enough feedback from those who your *solutions* will affect, are just as potent an enemy.
Banshee Kickin’ It
Just wanted to throw out a big woohoo to Bockover and co over at [Banshee](https://banshee-project.org/) for [kicking out Banshee 1.4](https://banshee-project.org/download/archives/1.4.1/). I am a big fan of what they are doing, and they are doing some really neat work. The 1.x series is really kicking. 🙂
The only thing I would really like to see and what is missing for me is StreamTuner integration – I would love to see a huge catalogue of online radio stations available. I like that StreamTuner scans online services for the available catalogue. I used to listen to these stations a lot – there is some incredible music out there.
What would be an interesting feature would be a workflow in how we listen to, consume and share music. So imagine this:
* I listen to an artist either on an online radio station, on Last.fm neighbourhood radio or something else.
* I like what I hear, and Banshee provides one click access to learning about the artist. It can show me a single page with the band’s Last.fm and wikipedia content, a discography and if free music is available, I can click a button and it will download it to my library. This would provide a great workflow for when you hear something you like (which can often be only a few riffs) you can fill your library with all available content.
It would also be great to have a feature for sharing music legally. Imagine I have a bunch Free Culture music in my library. It would be great to have a button to make those songs easily available to others to transfer to their library, over IM or other online service, maybe using the (CC) branding and logos to help this along.
Just thoughts, but congrats guys on a fantastic release!
The Shade Of The Ecosystem
One of the things I love about human nature is that it can be so unpredictable at times. It is this essence of the human condition that generates untold surprise and pleasure, tender moments that define us in so many ways. Unfortunately, the very same condition causes clued-up people to write [essays of total unparalleled nonsense](https://www.happyassassin.net/2008/10/28/why-i-dont-like-canonical/). I know I am a bit late to the party, but I felt compelled to write a few words.
[Adam Williamson](https://www.happyassassin.net/), community wrangler at Mandriva, a friend of mine, and someone who I have shared an over-sized coffee with, has posted a vitriol filled rant entitled *Why I don’t like Canonical*. In his diatribe he claims that “*what Mr. Shuttleworth did with Canonical and Ubuntu was divebomb the distribution pool*”, going on to assert that “*Ubuntu is fundamentally in a position of deeply unfair competition within the Linux distribution market*”. He goes on to claim that we ‘orrible people at Canonical have been “*patently unfair*” in producing Ubuntu and believes that Mark has used his millions to shake up the distribution economy unfairly. He says that Canonical is “*not remotely self-supporting and does not plan to be self-supporting in any reasonable timeframe*”.
Bollocks.
Lets take a look each of these delicious nuggets of nonsense and break them apart.
Lets first of all focus on Adam’s belief that we have “*divebomb[ed] the distribution pool*” and that we have been “*destructive to the ecosystem of Linux vendors*”. I am not entirely sure how exactly the impact of Ubuntu has been destructive to distributions. Red Hat is profitable, Novell is so too. Linux has been growing extensively as an Operating System and moving into more and more markets. Netbooks are shipping a range of Linux distributions. Oh, and according to Adam himself, Mandriva “*is currently not profitable, but its losses have been reducing steadily for a while, and we are projected to hit break-even reasonably soon, if all continues according to plan*”. Strange, if Ubuntu was so destructive, surely Mandriva would be making more losses instead of fewer? Of course, Adam may be referring to the impact of Ubuntu on entirely free distributions with no commercial backer such as Gentoo and Debian, but in his article he builds a metaphor around a wood carving economy and a rich man. I don’t think Adam will be losing sleep about Gentoo and Debian tonight.
With his focus clearly on Canonical as the poisoned challis, he asserts that “*Canonical doesn’t have a business plan, it has a collection of vague aspirations and a distinct tendency to throw money all over the place and hope it sticks somewhere (viz. Ubuntu Server)*”. He goes on to refer the “*pile of flimflam that is Canonical’s services page*” and encourages us to “*compare it to a real company’s*”. That *real company* he refers to, rather interestingly, is not Mandriva, but Red Hat. Oh and just for good measure he says that we can be compared to Microsoft for such a flagrant abundance of problem solving, George Washington style-ee.
Friends, I can assure you that our business team does not have “*vague aspirations*”. Quite the opposite – they are a pretty determined bunch with a nose for where we can monetise Ubuntu, and they live and breath the goal of getting Canonical profitable with a passion; they are not exactly sat around playing Frozen Bubble and twiddling their thumbs. But importantly, a very significant focus in what we do is to deliver Free Software to people. We are all (business team included) incredibly passionate about Free Software. We believe that Free Software is positive for IT, positive for technology, positive for culture and positive for business. Even though Adam criticises us for ShipIt and sending out millions of free CDs, the reason why we do that is to get Free Software in people’s hands easier, and I would argue that that significant investment has been worthwhile. How is this a bad thing?
There is no reason why Canonical can’t have a strong commitment to Free Software and build a profitable business around Ubuntu to not only help further the development of Ubuntu and Free Software, but to bring it to new and exciting markets, such as laptops, netbooks and more. To do this, our senior management team have invested extensively in business operations across the company, touching every aspect of what we are working on. And this has reaped rewards including deals with Dell, netbooks, custom engineering, ISV and OEM relations
Sure, when Canonical started out life it was a heavily engineering based company, but this is no different to every other tech startup. It usually starts out with a bunch of geeks in a garage, except in our case it was a bunch of geeks in Mark’s kitchen. When the early incarnation of Ubuntu was ready, Canonical expanded and diversified, adding products, business units, training, administration, HR, and more. This is not any different to any other company. If Mark really had no interest in making money, why would he build Canonical as a business? Why not just register a charity? It just doesn’t make sense.
Adam’s assertion that we “*throw money all over the place and hope it sticks somewhere*” is also naive. We have a desktop product (Ubuntu Desktop), a server product (Ubuntu Server), a mobile/embedded product (Ubuntu Mobile), a netbook product (Ubuntu Netbook Remix), a development portal (Launchpad), and a systems management product (Landscape). We also invest in the bazaar project and various other Free Software projects. None of these to me seems particularly unusual. Every Linux distributor has a desktop, server, mobile and netbook products, and with Adam’s angst based around the Linux distribution world, I fail to see how we are throwing money at the problem – I see us producing products that compete.
But this is the crux of the issue. Adam’s carping seems to be founded in the norms of a free market. The Linux distribution space is one with a theatre of characters, and each of these different characters has notable and less-notable points, us included. I can understand how people may disagree with our decisions, but I fail to see how investing a lot of money in Free Software is a bad thing. Mark has invested heavily in Ubuntu because he believes in Free Software and believes it is important in technology, and he believes that he can build a business around it. I am not expecting you to believe him or even believe me, but I fail to see how this investment is a bad thing. Whats more, its not just us – the same goes for Red Hat, Novell, Intel, Collabora and others. Many of those companies invest hugely – Red Hat do excellent work in many areas of the stack, Novell hire people like Miguel and Bockover to work on Free Software, Intel do extensive driver and stack work, Collabora work on multimedia technology. I didn’t see Adam complaining when IBM invested [$1bn in Linux back in 2001](https://news.cnet.com/2100-1001-249750.html). Adam goes on suggest that Mark has been somewhat selfish about investing millions of dollars of his personal wealth in Free Software; “*I think, if he’d been willing to be more selfless, he could have had a more positive impact with a plan which worked together with the existing ecosystem instead of just blowing it out of the water and saying ‘it’s my way or the highway’*”. Astonishing. Not because Mark is my friend and the founder of Canonical, but I find that perspective astonishing when applied to anyone who has invested so much time or money into Free Software and to accuse them of being selfish.
Personally I am intensely excited about the market around Free Software. I am excited that Canonical shows such promise and that there is healthy competition with Red Hat, Novell, Mandriva and Xandros. I am also excited about the ecosystem of smaller development companies – companies like Collabora, Opened Hand, KDAB, BitRock, ThinkOpen, Imendio, Songbird, Fluendo, and hundreds more across the world, all managing to make a buck with Free Software in new and different ways.
And you know what the best thing is? When we all stand shoulder to shoulder against Microsoft, whatever the flavor of Free Software desktop, thats a pretty big army…