Archive for November, 2008
Posted on November 30, 2008 - by jono
Money. Stability?
Something struck me yesterday, while Firefox 3 was throwing a hissy fit. Is there some kind of correlation between the amount of money invested in a project or product and instability? I know this sounds like a bit of a negative question, and I don’t mean to rag on the Firefox folks, but it seems that as more money has been pouring into Mozilla Towers, the quality has been compromised. At first I thought this was just on Linux, but it seems to be on Windows too.
This is by no means an issue specific to Mozilla though – look at Microsoft with Vista. They filled the worlds largest boot full of money and poured it into the Vista machine and…bang! Instability. The more I think about it, the more examples occur to me.
Is it money directly? Or is it really that more money means more staff employed and instead the quality failure is due to management and coordination problems? Maybe it is more users that causes the problems – more users means more needs and requirements which maybe cloud the QA process? Alternatively, do the quality problems really exist, or are our expectations higher than they were? Do we expect more of our two examples, Firefox and Vista, than we did many moons ago?
I would love to hear your thoughts and experiences on this folks. I wonder what hints we can uncover.
Posted on November 26, 2008 - by jono
Housekeeping Improvements
Just a few quick jonobacon.org housekeeping notes.
Firstly, I have added a little sidebar section that displays those rock and roll readers who have posted the most comments. The ranking is over the last year. Our Top 10 is currently:
- Vadim P. (19)
- Adam Williamson (15)
- ethana2 (13)
- mrben (10)
- Tom Mann (10)
- Wolfger (9)
- Alastair (9)
- Tom (8)
- andylockran (8)
- Eugenia (8)
In the sidebar it will link to the equally rocking websites of those rocking rockstars. Rock on. Rock.
There is still all to play for. There may well be prizes. You people deserve nice things. Even you, Williamson. 
I have also added a few other subtle niceties on the site, go and see if you can find them. Speaking of which, if anyone wants to see any features added to make the discussions that little bit more fun and productive, do let me know.
Posted on November 26, 2008 - by jono
The Flow Of Ideas
I have been thinking a lot recently about the flow of ideas in and around Open Source projects. A few days ago I asked for feedback about how we can better structure interaction ideas. The blog entry gathered some great feedback: thanks to everyone who contributed. With this work I am keen to understand the bottleneck between a well researched, well specified and documented interaction concept and its ultimate implementation. It is this contention between walled designers and walled developers that causes so many great ideas to be lost, never seeing the light of day.
Understanding and resolving this contention is important for GNOME. If we compare and contrast the KDE and GNOME approach to revitalised desktop interactions (read: KDE 4 and GNOME 3), we see two very different approaches. The KDE team discussed, designed and documented a big picture approach. They mapped out a design of what they wanted to see and then encouraged the community to implement said vision. And you know what, they did a damn good job. Although still a touch rough around the edges, KDE 4 is a huge achievement of defined direction and coordinated implementation.
But that approach is not the GNOME approach. GNOME is a playground for experimentation and ideas. We need to stop trying to take the KDE approach of mapping the big picture and rallying the troops to implement it. It just isnt going to work that way: we have tried to do this for the last three GUADECs and have produced relatively little.
But look at what innovation we have produced. Tomboy. GNOME Do. Beagle. Empathy. Abiword. The Slab. The new FUSE applet. Deskbar. Gimmie. Dashboard. F-Spot. Banshee. The list is endless. The GNOME community has a history and culture of experimenting with ideas and approaches. Some of them sink, some of them swim, but there are two important attributes in each of these ideas – they are small, self contained units and code is available. Just look at Owen’s recent post as an example. We had all read Vincent’s post with interest, but when Owen showed us some code that we could check out and play with, the idea really started to develop legs. Another example is GNOME Do. I think most of us were a bit sceptical of the idea of GNOME Do at first, but the subsequent implementation and positive reported workflow experiences has made people sit up and not only take notice of GNOME Do, but its primary interaction characteristics.
So, it is clear that the GNOME community is an incubator for lots of small experiments and ideas, some of which work well and some of which don’t. Our challenge is in how we continue to encourage the flow of ideas and how we merge the flow of successful ideas into the central body of what we call GNOME
If we decide this is the right approach, we need to not only foster an open environment that encourages experimentation, but we also need to foster an environment that encourages useful experimentation. We want to ensure that successful experiments can be merged easily and quickly at a technical level. One potential approach to this is to encourage uses of popular and agreed infrastructure. We have this to a degree in the project already (languages, toolkits, source control systems etc), but I suspect this will shake out naturally and we will continue to see dominant technologies such as Python, Mono and C being used, and increasingly new technologies such as Clutter and Telepathy.
For this approach to succeed we need to think carefully about the workflow of an idea moving from the functional experimentation phase to the merged phase – the technical implementation and maintenance, the politics we want to avoid, the decision making process of how we evaluate ideas etc. This is where I feel we should be focusing our debating glands. Lets flesh out these processes and encourage this environment of experimentation and exploration, Just imagine what we could achieve if we could figure out effective methods for communicating interacting concepts effectively to developers, developers hacking on small implementations of those ideas and the those ideas garnering popularity and being merged into the desktop. In many ways this is a very Free Software approach – scratch an itch, refine it with collaborative development and then merge. If we can figure out these questions together, our new GNOME could actually happen.
Posted on November 25, 2008 - by jono
Ubuntu Free Culture Showcase II: This Time Its Personal
I am epically excited to announce our second Ubuntu Free Culture Showcase this time for the Ubuntu 9.04 Jaunty Jackalope release!
The Ubuntu Free Culture Showcase is an opportunity to bring the best of two great worlds together by showing off high quality Free Culture content in Ubuntu. At the heart of Ubuntu’s ethos is a belief in showcasing Free Software and Free Culture, and with each development cycle we present the opportunity for any Free Culture artist to put their work in front of millions of Ubuntu users around the world. Although the space restrictions are tight, and we are limited to how much content we can include, the Ubuntu Free Culture Showcase is an excellent opportunity for artists everywhere.
The winning submissions will be made available on the shipped CDs and download images of the Ubuntu 9.04 release. Every user will be able to find the content in the Examples/ folder in a home directory.
With this competition we are now not only accepting submissions for audio and video, but also graphic/photo submissions. This opens up the competition to all of you budding photographers and artists. We have a winner to find for each category, and the competition closes on 6th February 2009.
Entering the showcase is simple:
- Your submission must be one of the following:
- Audio Entries – no larger than 1MB in size – made available in Ogg Vorbis format.
- Video Entries – no larger than 2.5MB in size – made available in Ogg Theora format.
- Photo/Graphic Entries – no larger than 0.5MB in size – made available in PNG or JPG formats.
- All entries must be licensed and distributable under the Creative Commons Attribution ShareAlike license.
- Upload your submission somewhere online (there are lots of free hosting solutions available such as archive.org). Do not email any of the organisers or judges with your submissions.
- Add your entry to one of the submission tables at http://wiki.ubuntu.com/UbuntuFreeCultureShowcase.
- When the deadline for submissions closes, our panel of judges will pick a shortlist, and the Community Council will then pick the final winners from the shortlist.
The deadline is 6th February 2009 and you can read more about it at http://wiki.ubuntu.com/UbuntuFreeCultureShowcase
Posted on November 25, 2008 - by jono
Desktop Shells, Usability and Trackers. Oh My.
A while back, I read with great interest Vincent’s blog entry. 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 I may have actually drooled. Instead of grabbing a tissue, I instead grabbed jhbuild and built said shell. Instructions for the brave are here. 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. 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.
Posted on November 24, 2008 - by jono
Jokosher Interview
gnomedesktop.org recently did an interview with the legendary Laszlo Pandy who is one of the two lead developers of Jokosher. 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 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…
Posted on November 22, 2008 - by jono
A question…
Knock knock?
Posted on November 20, 2008 - by jono
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.
Posted on November 19, 2008 - by jono
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. 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:
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?
Posted on November 18, 2008 - by jono
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 and follow the instructions to apply. Please no not contact me directly to make your application, just follow the instructions.
-
Flickr Photos
