Hiding In Plain Sight: On Being More Transparent

Hiding In Plain Sight: On Being More Transparent

One of the most elemental components of Open Source and thriving community is transparency. We depend on and define transparency as a high priority so that the community feels engaged and informed as it grows, reacts, and nurtures new challenges.

Transparency though is not a single construct; you can’t look it up in the dictionary and get an actionable plan. It is highly dependent on the specific community, it’s size, and how it works.

We have a pretty well defined and transparent governance infrastructure in Ubuntu: our *Community Council* governs the community, our *Technical Board* reviews and approves technical processes and policy changes, and our many team councils (*Developer Membership Board, Regular Membership Boards, Forums/IRC/LoCo Councils* etc) do an excellent job in maintaining domain expertize and governing effectively.

Despite this, it is easy to accidentally latch into what I am referring to as *hiding in plain sight*, and I want to use myself as an example of *what not to do*.

At the last Ubuntu Developer Summit we had a few discussions about how we can better serve the needs of application developers who want to get their app in the Ubuntu Software Center. Today our Ubuntu upload and packager review processes are really designed for those who want to be full blown Ubuntu developers, as opposed to just packaging and uploading a single app that they care about. Over the last few years we have been wanting to better support application developers, and we have provided various technical facilities for this (such as PPAs and Daily Builds), but we have not yet evaluated the best way in which an app developer can get their app in the Ubuntu Software Center.

Thus, we had a discussion at UDS and broke the problem into two areas: the *technical implementation* which I openly vetoed myself having any view on as I believe I lack the technical expertize, and the *governance process* part, which I volunteered to craft a process for. Before the UDS session I produced a rough draft on the Ubuntu Wiki and presented it to the room in the session.

After the discussions at UDS I started work on refining the process. I created a public blueprint to track the work, and I continued to work on the process publicly on the Ubuntu Wiki. When it was looking fairly complete, I invited Matt Zimmerman (who has many years of experience in Ubuntu), Iain Lane (who had been vocally opposed to parts of the technical implementation), and Rick Spencer (who is heavily involved in empowering App Devs) to review the process. I then merged their feedback in. With this complete, I then contacted the Ubuntu Technical Board who then reviewed the process and gave it a +1 after I had made some changes based on their feedback.

After all this I posted the process to the `ubuntu-devel` mailing list and announced that we were looking for volunteers for the new App Review Board that the process outlined. Over the following few weeks was a minor shit storm. Some key members of the community had objections to the technical implementation and some objected the process was just presented to them and was presented too late. As I have said previously, I am deliberately not getting involved in the technical implementation considerations as I lack the technial prowess, but I openly apologized for the process element…I could have done better.

And here, my friends, is the lesson. One could argue that I crafted the process in a very open way, and I did; I drafted it publicly on the Ubuntu Wiki, a tracked the work on a public blueprint, I discussed the first iteration of the process in the UDS sessions, I gathered input from some key people, and I saught approval for the process from official Ubuntu Technical Board. While all of this was fine, there was one missing component: I should have had a conversation with the community on `ubuntu-devel` before taking it to the Ubuntu Technical Board. Once again, I apologize to the community for this mistake; there was no ill will or malice driving this accident, it was the fact that I, my friends, am an idiot at times.

I am a firm believer that mistakes should expect apologies and I wanted this post to not only act as that, but to also help it be a lesson to others. It is easy to assume that the amalgomation of transparent facilities (the wiki, blueprint, UDS sessions, governance) is enough in having a transparent execution on a new process or policy, but these don’t mean a bean if there is little visibility on those resources.

Now, just to be clear, I don’t believe this oversight invalidates the App Review process, and I do believe the goal is still a very valuable one for us to solve (we absolutely *have* to empower and energize app developers), but I do believe that improvements can be made, and I wanted this post to be a testiment to the fact I will endeavor to not make the same mistake again. Mind you, remember, I am an idiot, so I might get this right but then walk right into a lamppost or something. 🙂

Severed Fifth’s ‘Nightmares By Design’ Release Date Set

Severed Fifth’s ‘Nightmares By Design’ Release Date Set

As some of you will know, I have a Free Culture metal band called [Severed Fifth](https://www.severedfifth.com/), and recently I have been working hard recording the new album, titled *Nightmares By Design*. Well, I am pleased to announce that the new album will be released on **Mon 11th October 2010** (the day after the Ubuntu 10.10 Maverick Meerkat release!). The album will be available on that day at [www.severedfifth.com](https://www.severedfifth.com) and available for free in full, and licensed under a [Creative Commons Attribution Share-Alike](https://creativecommons.org/licenses/by-sa/2.0/) license. The new album is far more accessible and diverse, it features 11 tracks and weighs in at around 54 minutes. I am really proud of it. 🙂

In addition to the new album, we are getting ready for our very first *Severed Fifth* show on **Fri 1st Oct 2010** at **Pine Street Sports Bar and Grill, 875 Rincon Avenue (@ Pine Street), Livermore, CA 94551** – things have been going really well and we have been rehearsing hard on a 2 – 3 times a week rehearsal schedule to get the live set absolutely solid.

There has also been a bunch of other *Severed Fifth* updates:

* [Announcing the ‘Nightmares By Design’ album cover](https://www.severedfifth.com/2010/09/20/announcing-the-nightmares-by-design-album-cover/)
* [Video: inside the Severed Fifth rehearsal studio](https://www.severedfifth.com/2010/09/17/video-inside-the-severed-fifth-rehearsal-studio/)
* [Video interview with Ron Crockett (bass)](https://www.severedfifth.com/2010/09/10/video-interview-with-ron-crockett/)
* [Video interview with Ben Gibbs (drums)](https://www.severedfifth.com/2010/09/08/video-interview-with-ben-gibbs/)
* [Video interview with Jim Adams (guitar)](https://www.severedfifth.com/2010/09/06/video-interview-with-jim-adams/)
* [The incredible Severed Fifth PA story](https://www.severedfifth.com/2010/09/22/our-new-pa/)

With *Severed Fifth* a full Free Culture band, we have set up the [Severed Fifth Fair Pay](https://www.severedfifth.com/pay/) system in which fans can help support the band, and that page now has an introductory video that explains how it works.

Finally, be sure to [join our community](https://www.severedfifth.com/forum/) and be a part of the [Severed Fifth Street Team](https://www.severedfifth.com/streetteam/)!

If this all piques your interest and you want to keep up to date with all the awesome *Severed Fifth* goings ons, be sure to join the following:








Taking a Step Back With Fresh Eyes

Taking a Step Back With Fresh Eyes

Scale is an interesting thing. It affects all kinds of things. Companies grow and don’t seem quite the same as they used to. Bands make it big and then they disappear up their own arses. Restaurants get popular and the food often starts to go downhill. One way or another, it seems that the old wives/husbands tale of scale is that *when things get bigger, quality can often suffer*.

This is a misnomer; scale doesn’t mean quality must decline, but it does often signal increasing complexity that was wasn’t there before. This is just a part of life: you add more ingredients into the mix and things get more complex.

Like many, I have seen this in the company I work for (Canonical). I joined Canonical when it was pretty small. We had an office in London that could only fit about twelve people in it, I knew everyone, and they all knew me. Things are different now. We are a *big* company now with things like HR and Finance departments, we need a company directory, and we have staff events that have the echoing resonance of “*by eck, there are a lot of people here, I remember when…*”.

The same happens with communities. Well, some communities. Many communities never face the issues of scale because they stay to a comfortable manageable size, and that suits everyone just fine. Unfortunately, this is not the case with Ubuntu. We are big, and I think our size is causing the seams to split open a little.

Recently my sub-conscious has been pestering me about this. I have been noticing that while our community continues to grow, which is awesome, it feels like getting involved is getting more complicated. We now have hundreds of teams, many different diverse types of contribution, and a collection of processes and assessment procedures to ensure we accept quality work into the distribution. If you have no idea of MOTU/core-dev/PPAs/Daily Builds/Package Sets/Archive Reorg is, you are probably going to find you have a lot of reading on your hands.

I want to change this. I want to make it better and *easier* for people to participate.

No one is at fault for us having this complexity; it is part of a passionate community growing every day, but I think we need to take a step back and take a good hard look at how it feels to get involved if you are new around here.

### Understanding What To Fix

To help with this I have been talking with some our key community contributors and have put together a *Community Review* plan to assess the new user experience.

The plan is simple: I first created a report template that serves the following purposes:

* To identify how *discoverable* our community is – how do people find out about a type of contribution and get involved?
* To assess *learnability* – what resources and experience do we provide for new contributors to learn the skills to participate?
* To explore how new contributors do things – with a knowledge of the community and the skills, how do contributors know what to work on?
* In addition to this, I believe the most insightful commentary on these things is from people who have just joined our different communities; we need to capture that input while it is fresh.

So, I formulated this report structure (an example of which is [here](https://wiki.ubuntu.com/CommunityReview/Sep2010/Translations) for the *Translations* method of contribution), and I have asked the following people to lead this assessment process in these different types of contribution:

* Total Beginner (this is people who are entirely new to Ubuntu in the first place) – Jorge Castro
* Translations – David Planella
* Packaging – Daniel Holbach
* Documentation – Matthew East
* Advocacy – Laura Czajkowski
* Support – TBC
* Art – Martin Owens
* Quality – Ara Pulido
* Server – Ahmed Kamal

Now, I know there are other teams who are not included here, but we need to start somewhere, and I think this list nails most of the major teams.

The next step is that each of these folks will follow through the requirements of each report (the reports are all linked on [this page](https://wiki.ubuntu.com/CommunityReview/Sep2010)) and add content, and then we will draw conclusions for solutions.

If you have input that you would like to share, please [go here](https://wiki.ubuntu.com/CommunityReview/Sep2010), click on the report of interest to you, and enter your comments in the *Commentary* section; please do not add content to other parts of the report.

I think this is going to be an excellent first step in helping us understand how to better react to the scale; what an awesome problem to have. 🙂

Hiding In Plain Sight: On Being More Transparent

Announcing the Ubuntu Application Review Process

Are you an application developer who would like to see your application appear in the *Ubuntu Software Center* and available by millions of Ubuntu users? Today we are announcing a new process we are trialing which is easier and more accessible for application authors to get their apps in Ubuntu.

Recently we formed a community-driven *Application Review Board* that is committed to providing high quality reviews of applications submitted by application authors to ensure they are safe and work well. Importantly, only new applications that are not present in an existing official Ubuntu repository (such as main/universe) are eligible in this process (e.g a new version of an application in an existing official repository is not eligible). Also no other software can depend on the application being submitted (e.g. development libraries are not eligible), only executable applications (and content that is part of them) are eligible, and not stand-alone content, documentation or media, and applications must be Open Source and available under an OSI approved license.

The process is simple:

* Prepare your app ready for review.
* Submit it for review.
* Await feedback and if the feedback is positive, your application will be added to the *Ubuntu Software Center*.

Would you like to learn more about how to get your app in the *Ubuntu Software Center?

**[Go and read this page to find out more](https://wiki.ubuntu.com/AppReviews)**.

Fixing Community Processes

Fixing Community Processes

Recently a few people have shared stories with me about how they have run up against processes that felt too complex or overly formal, processes that they feel have got in the way of the *just do it* philosophy that runs deep in the Free Software culture.

My view has always been pretty simple here: the whole point of processes is to organize creativity in ways that (a) reduce confusion (b) optimize collaboration and output, and particularly in Free Software, (c) maintain transparency.

The challenge with projects such as Ubuntu is that our community is huge, and encompasses many different teams, each with their own processes. With this kind of scale it is almost impossible to do a *process sanity check* with any kind of regularity. As such, we really rely on a *Find It And Fix It* approach to things. In other words, if you feel a process is to complicated or formalized and actually makes collaboration less attractive, then we need to take a step back, review the process, and improve it.

The underlying moral of this story is – if you come up against a process that is sub-optimal, we should *never*, and I mean *never, ever, ever, ever* just say “well, that is the process and that is how it works”. 🙂

Four Years And The Chasm

Four Years And The Chasm

This month marks my four year anniversary at [Canonical](https://www.canonical.com/). What a four years at has been.

I traditionally write up a little retrospective each year, but or some reason ‘four years’ feels a tad more special than usual, and I am not really sure why. Maybe it’s because great things come in fours. Well, Megadeth and four cheese pizzas do, but you get my point…

For this anniversary I want to build on the blog entries that many of my friends and colleagues in the Ubuntu community have been writing about how their work is helping Free Software. Before that I want to prefix this with where we stand today compared to four years ago.

Six years ago I believe that Ubuntu *changed desktop Linux*. Of course, this had nothing to do with me. I wasn’t involved back then; it was the fantastic work of the *original gangstas* such as *Mark Shuttleworth*, *Matt Zimmerman*, *Robert Collins*, *Scott James Remnant*, *Jeff Waugh*, *Benjamin Mako Hill* and others who got this train on the rails. They all have my unending respect: they took the fantastic and inspiring rock that is Debian and they built on it to create something different. It was fresh faced, innovative, and had a wicked-cool tan. It inspired me to use and advocate Ubuntu, and ultimately see if I could fit in in a world populated by such *original gangstas*. Fortunately, the *original gangstas* was rather nice and welcoming gangstas…

Back in the early days, Ubuntu targeted a very different demographic of user. Ubuntu was shooting to capture the hearts and minds of those passionate about Linux but who wanted a devilishly simple experience. Two years in, Canonical let me join the ride as Ubuntu Community Manager. My goal was aligned with that of Ubuntu: to help build a community that embodied the values of Ubuntu; open, accessible, rewarding, and ultimately…just a tonne of fun. 🙂

Getting back to the blogging meme of how our contributions help Free Software, I see my role as largely to help enable and encourage others to do great things. I see myself as a facilitator; someone who tries to help others to have the tools, resources and motivation to further Free Software. Most people know of my affiliation with Ubuntu, but I have also done this with other projects such as [Severed Fifth](https://www.severedfifth.com), [Jokosher](https://www.jokosher.org), [LugRadio](https://www.lugradio.org), [Shot Of Jaq](https://www.shotofjaq.org) and others. By definition, I see what I bring to Free Software is in helping others to do great things for Free Software; they are the real people who deserve the credit and hugs. Every day I feel blessed by the wonderful people that I get to work with, both in Canonical and in our wider Free Software community. Even Aq. 🙂

Getting back to *four years at Canonical*, the shape of Ubuntu today is quite different to four years ago. As I mentioned earlier, four years ago Ubuntu very much served enthusiastic Linux fans who wanted a simple experience, but today…I believe we are stood staring at a much wider demographic of people who we can bring Free Software to.

I am proud to see how successful Ubuntu has been. As one of many proud fathers and mothers of the project, I am proud to see how much progress we have all made together. At every Open Source conference I see a large number of Ubuntu laptops, I see Ubuntu machines on trains, in airports, and coffee shops, you can now buy laptops with Ubuntu pre-installed, and Ubuntu and Linux are no longer things that you typically need to explain to people.

In the software industry we often talk about [crossing the chasm](https://en.wikipedia.org/wiki/Crossing_the_Chasm), and I believe Ubuntu has the ability to cross that chasm.

I have never believed that more so than I do today.

In the last six years I feel Ubuntu has transformed from a sleek experience in a community predominantly populated with heavily technical people, to a sleek experience that is also interesting to a wider community that still includes these technical peeps, but now includes those who think of their computers less as computers and more like appliances. Members of my family use Ubuntu. I know young kids who use Ubuntu. I know many schools who use Ubuntu. More importantly, they are all using Free Software; Ubuntu just brought it to them in a way that makes it accessible and in a form they can understand and work with.

While I believe we are on the edge of that chasm, let’s not get too complacent. We have lots to do to get over it. The chasm is big. While we have made tremendous progress, we now need to unpick and understand every detail, nook, and cranny of what our users expect and how they define quality, and I believe that now more than ever we have the opportunity to get over that chasm, but the only way we can do it is together. Looking around at our incredible community, I *know we can do it*.

Just think of the potential. Just think of the impact on people’s lives we could have. Just think of all the benefits we feel as Free Software users today, and imagine all those benefits being enjoyed by the wider world.

Getting over that chasm is not going to be smooth sailing though. It is going to be a bumpy ride, and we are going to need to pull together and lean on each other to keep up our motivation and focus in getting there. We are going to need to make some hard decisions. We are going to have to question and challenge the culture and assumptions we place in ourselves on this side of the chasm if we are to understand the opportunities on the other side. We are also not going to make everyone happy all the time. We may even lose some people as we get over the chasm; that’s fine though, if Ubuntu loses those folks for whatever reason, *Free Software* doesn’t.

I am proud of Ubuntu and never before in my career have I ever felt so positive about a project I am involved in really changing people’s lives for the better. While Ubuntu is the vehicle, the payload is Free Software, and we have the opportunity to spread it far and wide. Now we face the real challenge, but everyone has a piece they put in the bridge that will get over the chasm. We need developers, testers, translators, an army of advocates and enthusiasts, artists, designers, and more. As I said earlier, I am a facilitator, and I am passionate about helping our community to help build that bridge. Let’s roll. 🙂

*So this was my experience and how I feel I help Free Software and my belief in what we can achieve – I would love to see you folks blog about how you feel you help Free Software and what potential we can bring!*

Rest Well, My Friend

Rest Well, My Friend

It was with great sadness that I read earlier that my friend and colleague [Ian Clatworthy](https://ianclatworthy.wordpress.com/about/) passed away after his fight with cancer. Although I never knew Ian that well, whenever I did work and spend time with him I always found him to be a fun, light-hearted, and always pleasant person to be around.

Words escape me.

You will be missed, my friend. Rest, well.

Rest Well, My Friend

Incredible Stories Of Free Software and Open Source

A little while back I [blogged about wanting to reconnect with our ethos](https://archivedblog.jonobacon.com/2010/08/24/revisiting-ethos/). In a continuation of that theme I am keen to talk about *stories*.

I have talked about *stories* quite a bit in my writings on community management (particularly so in my book [The Art of Community](https://www.artofcommunityonline.org/)). Stories are important entities in communities – they are vessels in which we share ideas, lessons we have learned, our experience and more. Many stories come laced with these underlining nuggets of wisdom that we then take aware and help us to refine and improve how we interface with the world and the people around us.

Stories though encompass another significant benefit: they allow us to inspire and encourage others via real-world practical examples of our ethos being put into practice.

A story I share at every [Ubuntu Developer Summit](https://uds.ubuntu.com/) is that when I started working as the *Ubuntu Community Manager* I got a lovely email from a kid in Africa who would walk two hours to his local town where he would spend his own money to buy Internet time in an Internet cafe to contribute to Ubuntu and then walk two hours back home. This story was powerful to me. It told me that my job is to help that guy get the most out of his hour, to justify his investment of energy and expense to just get involved in the first place. His story was inspiring, encouraging, and an impressive example of commitment. I always share this story at UDS as an inspiration for us to get the most out of each one-hour session.

These stories benefit us all, and in the continued theme of reconnecting with our ethos, I wanted to ask you folks what are the most inspiring and encouraging stories of Free Software and community that you have heard? Which story have made those little hairs on the back of your neck stand on end?

Rally For Sanity

On Zareason

*These views are my own, and not necessarily those of Canonical.*

Some time back the always awesome Earl and Cathy from [Zareason](https://zareason.com/shop/home.php) loaned me one of their [Strata laptops](https://zareason.com/shop/Strata-Pro-13.html) to play with. I met them at an event some time before, and while I had heard of Zareason, I really knew nothing about them. Since then I have learned about their work and played with the Strata. I just wanted to share some thoughts.

Zareason are a company that I think *really gets Open Source*. They are a small organization and incredibly supportive of Open Source in the local area and wider USA. They pre-install Ubuntu on their machines, focus on open hardware, and one really nice touch is that they include a small screwdriver with each machine because they believe that everyone has the right to be able to open up their machines and peek inside. In this age of screwless, inaccessible boxes and restrictive end-user license agreements, this is a refreshing change. Like most, I would never actually use said little screwdriver…but it is a strong statement of Zareason and their culture. Kudos!

So, as for the machine, it is a zippy little monster and works great. The pre-installed Ubuntu worked great out of the box, with pretty much everything running as expected. One thing that really struck me, is regarding build quality. I consider build quality an essential ingredient in a laptop. Laptops move around a lot, they get thrown into bags, and they get picked up, dragged around and balanced in precarious ways. The Zareason Strata I tried felt incredibly durable…as in…Thinkpad durable. I absolutely adore Thinkpads for this very reason, so again, Kudos Zareason.

Finally, a big decider for me in a laptop is the keyboard. There are many great laptops with horrible plasticky keyboards. The Zareason Strata has a really comfortable, useful, and durable keyboard. It feels strong but not difficult to use. Again, kudos Zareason.

So, Zareason produce great, solid, hardware pre-installed with Ubuntu, they are actively supportive of the Open Source community, and they affirm openness in both the software and hardware. Sounds like a pretty good deal to me. 🙂