Ubuntu Developer Summit Sponsorship Now Open
The [Ubuntu Developer Summit](https://uds.ubuntu.com/) (UDS) is the most important event in the Ubuntu calendar. It is where we get together to discuss, design, and plan the next version of Ubuntu; in this case the Ubuntu 13.04 release.
The next UDS takes place at **Bella Centre, Copenhagen, Denmark** from the **29th Oct – 1st Nov**. You can find out more about why UDS is interesting from the perspective of a [member of the community](https://uds.ubuntu.com/participate/community), an [upstream contributor](https://uds.ubuntu.com/participate/upstreams), and a [vendor](https://uds.ubuntu.com/participate/vendors). We also welcome everyone to [participate remotely](https://uds.ubuntu.com/participate/remote) if you can’t attend the event in person. More more details on how to get there, see [this page](https://uds.ubuntu.com/travel/).
At the heart of a great UDS is a diverse group of attendees who can bring their experience and expertise to the discussions. You don’t have to be technical, or be a programmer or packager to attend – UDS is open to everyone (including non-Ubuntu folks) and free to attend. We encourage everyone with an interest in Ubuntu to attend.
## Sponsorship
For every UDS Canonical sponsors the hotel and accommodation of a set of community members to ensure they are free to contribute and bring value to the discussions. We have a limited budget so we can’t sponsor everyone, but we are always keen to have a capable and diverse group to sponsor:
* We strive to support community members who are actively involved in Ubuntu and who are providing *significant and sustained* contributions to the Ubuntu project.
* We always welcome Upstream contributors who are bring value to Ubuntu indirectly via active participation in their upstream project, but who are keen to see quality support for that upstream in Ubuntu.
* Contributors are willing to actively participate not only throughout the full Ubuntu Developer Summit week, but also following with active contributions throughout the release cycle.
* We are always keen to welcome members of the community who have never been to UDS before and are keen to participate and experience the event.
* You don’t have to provide technical contributions to apply – if you have participated in the areas of advocacy, documentation, testing, art, design etc, you are encouraged to apply.
* UDS is an event that encourages diversity – we welcome everyone to apply for sponsorship, irrespective of gender, race, impairment, technical expertise, or other factors.
If you are participating in the Ubuntu community, we would love you to apply for sponsorship. This is how it works:
1. You can apply for sponsorship [by filling in this form](https://summit.ubuntu.com/uds-r/sponsorship/). The deadline for submissions is **Mon 20th August 2012** so be sure to get yours in!
2. When the deadline is reached we will assess the applications and finalize who we will be able to sponsor.
3. You will then receive an email outlining whether we can sponsor you or not.
Simple! I look forward to seeing your applications!
Staring Into The Abyss: Some Thoughts
Last week [Benjamin Otte shared some thoughts about GNOME](https://blogs.gnome.org/otte/2012/07/27/staring-into-the-abyss/) that were pretty stark. It gathered some steam and hit Slashdot and this all happened the week [GUADEC](https://guadec.org/) was taking place in A Coruña. I wasn’t at GUADEC 🙁 but I can imagine there was some fervent discussion about the blog entry.
The gist of Benjamin’s blog was that people are leaving GNOME, that the project is understaffed, and arguably the reason for this is that GNOME has lost its direction and Red Hat have overtaken the project as the primary contributor-base. Of course I am summarizing, but [check out the original post](https://blogs.gnome.org/otte/2012/07/27/staring-into-the-abyss/) if you feel I am not representing Benjamin’s views fairly.
I wanted to share a few thoughts. To be clear: these thoughts are my own, and I am not speaking on behalf of Canonical, but I am speaking from my experiences as someone who has primarily been affiliated with Ubuntu and as a Canonical employee. My feedback is going to be frank but I really do care about GNOME as a project, and this feedback is intended from a position of love for the project and to be open and transparent about my own experiences as just one set of eyeballs in this story.
Fortunately, I think *all* of these problems are solvable, but for them to be solved GNOME is going to need to do a little soul searching to discover and focus on the right problems and explore and deliver the right solutions.
## A Little History
To provide a little context, my interest in GNOME pre-dates my involvement in Ubuntu. I have worked on a few applications that use the GNOME platform (Jokosher, Acire, Lernid, and most recently Ubuntu Accomplishments) and I have had a long interest in where the project is moving forward and as a core part of Ubuntu. I used to go to GUADEC every year, and I consider many folks in the GNOME project to be good friends.
While I care about where the project moves forward I too have also become concerned about the direction it is going in, not in terms of the design and user experience of GNOME (there are other, better versed people to assess this work), but instead in terms of how the project works with others such as companies, developers, and other partners.
In my mind GNOME has become bittersweet. I remember back at GUADEC in Stuttgart in 2005, discussions started happening about what form GNOME 3 would be in. As the years progressed the project struggled to decide on a final vision for what GNOME 3 would look like. This is not surprising: GNOME 2 was such a smashing success that GNOME 3 was going to be *difficult second album* time. Ideas were shared and bike-shedding occurred, but ultimately it seemed that the project was lacking leadership to take take all of these ideas and flip the switch to a vision and design and move it forward.
Around this time Ubuntu had become arguably the most popular way in which people were consuming GNOME and we (Canonical) were hiring more and more people to perform this integration work (which is no light task, as any distro developer will tell you).
Back then Canonical was taking quite a bit of heat for “never writing code and just shipping other people’s work” (which I always found a misguided viewpoint as integrating and delivering a solid Free Software Operating System is significant work and a great contribution to the wider Free Software commons).
We were starting to find though that there were areas of GNOME 2 that we felt could be improved and expanded (largely based on feedback from our users). We started growing a design competence and hiring developers to build new code to add improvements to the experience. Many technologies were created such as the messaging menu, notify-osd, dbusmenu and the global menu, control center improvements, and ultimately Unity as an additional shell for GNOME.
I remember this time vividly. I was in weekly discussions with Mark Shuttleworth, Rick Spencer (Ubuntu desktop team leader), Ivanka Majic (head of design), and David Barth (head of engineering these components). Our goal was simple: be able to showcase these technologies in Ubuntu and bring value to Ubuntu users, but to also ensure they were contributed to the wider GNOME project as technology that could help the general project in moving forward.
I personally saw this all boil down into pretty simple parts: Canonical and GNOME were *partners* and it was a mutually beneficial relationship – the GNOME desktop with barely any users defeats it’s purpose and Canonical was helping to deliver it to millions of users in Ubuntu, but Canonical could not build an awesome Ubuntu without the wonderful components in the GNOME desktop to fill in the many different pieces in an OS.
My simple philosophy was also marinaded in the gift culture of Open Source and Free Software: Canonical was paying designers and developers to produce new code that could be of value (and thus offered as a gift to the GNOME commons) and as with all gifts, while it may not be exactly what you want (and may need some adjustments and improvements), I presumed there would be a polite, respectful, and open discourse to take these contributions and bring them into the shared commons that was GNOME, particularly as they were created with GNOME in mind.
This was not my experience of what happened.
## Partners
I was really disappointed with what resulted. After years of Canonical and Ubuntu being criticized for *not contributing code*, when we then engaged in writing code we were met with a frosty, suspicious, and at times, frankly entitled attitude from some parts of the GNOME camp.
Now, don’t get me wrong, Canonical was not perfect here either. I fully admit that some of this relationship could have been handled better (and I am partially to blame here). We made some mistakes early on in which code was released too late and there was sometimes not enough open discussion. Retrospectively, we could definitely have done better in being more pro-active in some parts of the relationship too. At the time we were still learning how to do this, and as such we made some mistakes too.
Canonical wanted to strike the right balance of bringing innovation to Ubuntu releases with new features, but to also openly engage and contribute that innovation to upstreams such as GNOME. My goal here is not to open up a *blame game* of who did what and when (I will leave that to the commentators 😉 ), but what disappointed me most about the whole situation was that from my personal perspective it seemed that some influential members of the GNOME project were treating Canonical’s contributions more critically and suspiciously than others.
Now I haver never subscribed to conspiracy theories, and I don’t believe that there was a shadowy GNOME Illuminati that was meeting together in a hollowed out volcano to plan how to keep Canonical and their contributions out of GNOME, but I was surprised and disappointed at the attitude that came out of parts of the GNOME project to us, when we were ultimately delivering GNOME to millions of users as well as writing new code that could enhance GNOME. It just seemed incredibly *entitled*.
There were three things that really blew my mind about all of this:
1. From my experience of working on volunteer Open Source projects, new volunteers and their code contributions are tremendously valuable. As an example, if someone comes to my current project ([Ubuntu Accomplishments](https://wiki.ubuntu.com/Accomplishments)) and is willing to propose new, disruptive ideas, and willing to contribute chunks of code, I will treat those people with open arms. Being challenged is a good thing: it keeps us fresh, and a challenging, innovative idea followed up with running code is awesome. Now, of course, this is not to say that writing code automatically gets the contribution into the core project, but I would treat the entire social engagement with someone offering such a gift with positive open discussion to see how we could find a great solution that makes everyone happy. This seems an area where things could be improved with GNOME.
2. If I was also running a project that was understaffed and struggling to define its direction (which I would argue was the case with GNOME at the time) I would treat such new contributions as wonderful ways of solving problems and building a new direction for the project, particularly if our major distributor was going to be delivering that technology anyway. Code is the currency of Open Source, and rejecting chunks of this currency because they don’t fit an as-yet incomplete jigsaw puzzle of a vision just doesn’t make sense.
3. Without sounding egotistical from the perspective of an Ubuntu guy, I would argue that the vast majority of GNOME consumers were getting GNOME in Ubuntu. Of course, there was and continues to be the wonderful work going into Debian, Fedora, OpenSuSE and others, but it seemed that Ubuntu was the most commonly-used GNOME distribution (I suspect it still is). Again, I saw this as a partnership but from my perspective it seemed like parts of the GNOME project saw Ubuntu as fundamentally subservient to GNOME; as if we had an obligation to deliver whatever the GNOME project saw fit, irrespective of our own ideas and feedback from our users. In my position as an Ubuntu guy, I have always tried to treat our upstreams with maximum respect as they are a big part of who we are; Ubuntu is nothing without awesome apps, and a wonderful integrated experience. I guess I just expected a more positive and collaborative experience with GNOME than I experienced…the kind of collaborative experience that I had known and loved in the earlier days of GNOME.
Of course, it takes two to tango and we at Canonical could have no doubt done better to improve our relationship with GNOME, but I remember back then feeling like no matter what we tried to do, we came up against resistance from the GNOME project, and this was de-motivating and no-doubt added stress to our relationship.
## GNOME 3
To shift gears a little, one of the points in Benjamin’s post was that GNOME 3 is a Red Hat project. To me this is a bit of a double-edged sword.
On one hand, the crux of his point is entirely valid: most people contributing to GNOME seem to be a clique of Red Hat folks. What concerns me a little are the concerns in parts of the community that Red Hat is “running the show” and that much of the decision-making has been private to Red Hat staff.
Here’s the thing: I don’t doubt that this is probably happening, but this is *not necessarily a bad thing*. These concerns again highlight what I think continues to be an unrealistic expectation in parts of the GNOME project with those who are willing to invest in the platform (in this case, Red Hat). If Red Hat have decided to invest in a team of developers to work on and bring value to GNOME, building Free Software that can be shared with everyone, these contributions should be received with open arms. Leadership is leadership, irrespective of the employer.
Of course, there needs to be a culture of openness and transparency, and I suspect a certain amount of *internal water-cooler chat* is happening in Red Hat, but you will find that with any commercial team that is actively engaged in a Free Software project; we just need to always try to keep things as open as possible. GNOME is definitely going to need to ensure that the openness and values of open collaboration are not compromised, and an open and frank discussion with the Red Hat team about resolving these concerns is no doubt the best step forward.
I personally think it is wonderful that Red Hat are investing so much in GNOME and they have arguably led in much of the direction and leadership in delivering GNOME Shell and the various other parts of the platform. What seems ironic to me is that the same criticisms that were thrown at Canonical with Unity (as a perceived competitor to GNOME Shell, which it was never intended to be) are now being leveled at GNOME Shell (“you don’t care about our needs”, “you are pushing your own agenda” etc).
Maybe a solution to this problem is to be open and frank about the relationship with Red Hat. As an example, we always try to be open about our relationship between Ubuntu and Canonical; there is no doubt that Canonical drives a lot of the development and innovation in Ubuntu, although this leadership and innovation is firmly rooted in expectations around openness and collaboration. We don’t try to hide the influence Canonical has on Ubuntu, and I wonder whether the wider GNOME community feels comfortable in accepting the influence Red Hat has on the project. This is always a delicate balance.
I would agree with Benjamin that GNOME is essentially a Red Hat project these days, but as I say this is double-edged: the wonderful benefits of the investment from Red Hat will be tinged with the challenges of how vendor-neutral the project wants to remain.
## The Future
So what is the future of GNOME and how can these problems be solved? Can they even be solved in the first place?
I think so.
I love GNOME as a project, and I love the folks involved in it. While we don’t always agree, the core ethos and goal of GNOME is admirable: to bring an awesome Free Software desktop to everyone. While I personally prefer Unity as a shell, I think the work that has gone into GNOME Shell has been a wonderful rebirth of the motivation and focus of GNOME. The architects of this vision should be credited in getting GNOME out of the slump I mentioned earlier that seemed to stem from 2005. Of course, I will always be disappointed that GNOME seemed quite so resistant to much of the contributions we wished to make, and I think we could have helped to have moved things along a little faster, but I am delighted that GNOME 3 has got to the point it has got to.
As I mentioned earlier, my feedback here really has nothing to do with the design and technical direction of GNOME, and others can provide more insightful commentary than me. I do though think this *people-problem* issue of GNOME being a rather difficult project to work and interface with at times is a problem that has not yet been confronted and resolved. While this problem continues to exist, I worry that it will eat away at GNOME more and more.
GNOME is blessed with some wonderful leaders, and I hope that the content in this post can act as some food for thought: I am not expecting everyone to agree with me, but if this opens up a discussion about these topics I will be happy.
What is *not* a solution is for us to give up on GNOME. I know some folks are moving on from the project and moving onto other things, and we have more competition than ever for desktops, but I still see GNOME as an important foundational component of the Free Software and Open Source desktop today.
Now, I am sure this blog entry is going to result in some folks screaming from the rafters that I am misrepresenting GNOME and it is all Canonical’s fault, and you are entitled to your view. Traditionally I have not wanted to raise these concerns publicly as I didn’t want to cause any further harm in the relationship between Ubuntu and GNOME, but Benjamin’s blog post seemed to offer a good opportunity to throw out some feedback that might be helpful in constructing a solution.
While I don’t have much time to contribute to GNOME formally these days, I am more than happy to talk more, provide any further feedback, and help where else I can. I would love to see the GNOME project that we know and love be back in a healthier state. Thanks for reading.
Unity On Fedora
*I meant post about this previously, but have been catching up with email post-CLS/OSCON*.
I was delighted to read the news of [Unity entering Fedora](https://www.omgubuntu.co.uk/2012/07/unity-desktop-available-for-fedora). Although many associate Unity with Ubuntu, we would like to encourage the wider adoption of Unity in other Linux distributions and projects. Unity is a desktop that is designed to provide a unified experience not only on your desktop for GNOME, KDE and other apps, but also across different devices and screens.
With Unity getting more eyeballs from Fedora and other distributions, we would like to welcome you folks into the upstream community. If you would like to participate in programming, design, testing, support or other ways of contributing, you are more than welcome! You can [find out more here](https://unity.ubuntu.com/) and feel free to post questions of how to participate to the [Unity development mailing list](https://launchpad.net/~unity-dev) or the [Unity design mailing list](https://launchpad.net/~unity-design). You can also join our IRC channel at `#ubuntu-unity` on freenode.
If you are an application author and would like to have your app hook into the rich user interface components in Unity such as indicators, quicklists, notification bubbles, global menu integration, messaging and sound indicators, and more, you can find out how to do this easily [by reading here](https://developer.ubuntu.com/resources/platform/documentation/platform-diagram/) or using the awesome [Hello Unity](https://launchpad.net/hello-unity).
Ubuntu Accomplishments: Call For Volunteers
As some of you will be aware, we have working on a project called [Ubuntu Accomplishments](https://wiki.ubuntu.com/Accomplishments) in recent months. We are making good progress with the project and are working to our 0.3 release. The goals of this release will be:
* Assure quality and stability in the platform.
* Provide the ability to publish your accomplishments online.
* Expand our range of accomplishments.
* Expand and improve the documentation for our accomplishments.
* Provide a greater breadth of translations coverage.
As we head towards these goals we are looking for volunteers to join the project and help make the magic happen. We are a very open and welcoming community, friendly and personal, and as such a fun place to get involved if you are looking for an Open Source project to join. We are very welcome to new-comers, so if this would be your first project, come and join us!
The goal of Ubuntu Accomplishments is to provide an awesome way in which new and existing community members can explore and learn how to participate as well as making it easier for our users to discover how to use different parts of their computers.
We are on an exciting journey, and I would love to encourage you to join us.
## Who can Help?
If your interest is piqued, we can definitely find something you can do to help the project. Some examples:
* **Programmers** – we are very much in need of folks who can help contribute code to the project. Ubuntu Accomplishments is written in Python and you can find out more about how to contribute [here](https://wiki.ubuntu.com/Accomplishments/GetInvolved/Hacking), which includes our hacking guide, and all the details for getting up and running.
* **Documentation Writers** – we need folks to help create documentation for our growing family of accomplishments. If you have a knowledge of the community and of Ubuntu, this is a great way to help! Find out how to help [here](https://wiki.ubuntu.com/Accomplishments/GetInvolved/Documentation).
* **Translators** – we are always looking for people to help translate not only the core system, but also all the documentation in the accomplishments. All you need to know is how to use Launchpad a little and know a second language. Find out how to help [here](https://wiki.ubuntu.com/Accomplishments/GetInvolved/Translations).
* **Testers** – as we continue to grow and evolve our code-base, we are looking for daily testers who can help us to ensure we are resolving and fixing defects in the project. To help here you just need to be using the bleeding edge code and performing regular tests and reporting bugs and issues with it. Find out how to help [here](https://wiki.ubuntu.com/Accomplishments/GetInvolved/Testing).
* **Support** – as our user community continues to grow, we are looking for folks to come and help answer questions, resolve issues, and grow our body of knowledge about the project. To help here you just need to know about how Ubuntu Accomplishments works and be able to answer questions and resolve our user’s issues. To find out how to help, click [here](https://wiki.ubuntu.com/Accomplishments/GetInvolved/Support)
You can also help by creating new accomplishments for the system (more details of how to do that [here](https://wiki.ubuntu.com/Accomplishments/Creating)) and I will be following up with a post about this soon.
## How do I get Started?
First choose which area you are interested in and click the links above to find more details of how to get involved.
We would also like to invite you to our fortnightly team meetings. The next one takes place tomorrow, **Thursday 26th July 2012** in `#ubuntu-meeting` on freenode at **6pm UTC / 11am Pacific / 2pm Eastern**. I hope you can join us!
You can also join us in our IRC channel in `#ubuntu-accomplishments` on freenode and join our [mailing list](https://launchpad.net/~ubuntu-accomplishments-contributors).
**If you have any questions, such as how to get started, how to learn what you need to contribute, what to work on, or anything else, feel free to come and join us in the IRC channel our mailing list, or feel free to ask questions in the comments here**.
Building Strong Community Structural Integrity
In my previous writings I have talked a lot about how to build strong foundations in our communities. Namely, that we should strive to build *belonging*, and that a sense of belonging is what transitions *drive-by contributors* that are expensive and time-consuming to spin up, into regular community contributors who provide *significant and sustained* contributions.
I have also talked about the importance of growing strong teams. Great teams help us to reduce the scope of the community from the perspective of a new community member; joining a team with a smaller number of contributors helps the new member get up and running quicker than joining one giant community where they feel like a drop of water in the ocean, a needle in a haystack, an actual singer in a karaoke bar, or some other tired metaphor. Oh, come on…don’t give me that look, I am all about the tired metaphors…
In other words, if you build strong teams, infuse those teams with a sense of personal connection to new members, and welcome your new contributors with open arms, you will likely build belonging and thus grow a strong and scalable community that can grow beyond the current membership base and produce new generations of competent contributors in the future.
Much of my thinking has been evolving in my head over the years and I documented a lot of it back in 2009 in the first edition of my book, [The Art of Community](https://artofcommunityonline.org/). After I published the first edition back then, I discovered a range of other new ideas and approaches that I wished I had stumbled upon earlier so I could put them in the book. Thankfully I was able to add them to the recently released second edition of the book.
Unfortunately, and as is typical with life, just as the second edition hit the bookshelves, I discovered yet another key lesson which I wish I could have put into the new edition.
“Too much skin can be a hilarious burden”
Every group of people, be it a community, a band, a relationship, a workplace, a sports team, or whatever else, has a series of *structural foundations*. These foundations are almost always *people* (although they can often be processes and workflow that is ultimately influenced by one or more people), and their passion, personality, and capabilities determine their level of influence.
As an example, in a software company you have various influencers who determine in which direction the company moves forward. These influencers include founders, senior execs, engineering managers, product managers, and others. Each person has a differing level of influence on the overall structure. The perspectives, personalities, and attitudes of these people can significantly influence the morale and problem-solving capabilities of the wider group.
The way in which these foundational people interface with the rest of the group can be complex and unearth other subtle foundational members. You may have a strong founder with great ideas and direction but with a sharp and unforgiving tongue (e.g. Steve Jobs) but who is surrounded by management who help to interface him/her with the rest of the group. In this setting a potentially demoralizing foundational weakness of this person (namely said sharp tongue) is protected from doing harm to the rest of the group. In these cases the founder of the company continues to be a strong foundation with their vision and focus, but the management team who surround him/her are as equally strong and influential too in being able to transition that vision into practical work items and maintain morale.
Irrespective of the structure of the group, many of us can typically identify these foundational people. They are not just people in positions of authority; a wise and effective contributor on the bottom rung of the ladder can sometimes have more influence (if not power) in the group than a senior position of authority.
Whatever company, community, or group you are in, take a few minutes now to have a think about who are the foundational people who help to motivate, inspire, and deliver progress in your group or community. Think of those who present great leadership, vision, and direction, as well as those who you feel are foundational weaknesses and are taking your community in the wrong direction, solving the wrong problems, proving to be obstacle, or otherwise compromising the opportunity of the community and it’s work. Be careful to not just pick people you don’t like or disagree with as your foundational weaknesses: some of our most wonderful foundational entities can be our biggest critics.
Probably not a foundational core in your community.
So where am I going with all this?
Well, recently in a project I am involved in outside of work and Ubuntu I realized that I was starting to lack the motivation and excitement about something that I was once a man obsessed with.
Like many, as I have gotten older, I have started to understand my own psychology more and more. I have discovered which areas and environments inspire me, when I am burning out, what ingredients I need to be productive, what level of reassurance and validation I need, and other elements. I suspect this is as common a part of growing up as is my hair growing inwards and coming out my toes.
With this particular project I couldnt put my finger on why I couldn’t rustle up the motivation. I am generally a pretty motivated and optimistic kind of guy. I would find myself there with the folks involved and having a great time and enjoying our work, but when I left the room I would find it difficult to trigger that rush of adrenaline that was present when I was still in the room.
Then, fairly recently, a member of the project decided to move on. All was well and amicable, and even though I was tempted to part ways myself, something was still keeping me connected to the project. I then realized (via this journey of understanding my own psychology over the years) that I needed to try and figure out *why* I was lacking the motivation; something was creeping around under the skin and I just needed to put my finger on it.
It was then that I came across this concept of *structural integrity*.
## Structural Integrity
I realized while driving out to meet some of the other members one day that subconsciously I had lost faith in some of these foundational pieces of the project (including my own contributions). As I drove I broke down the different parts of the project in my mind, where I had concerns, and who these concerns were with, and many of those concerns were pointed towards problems with people with issues that had been identified in the past but in which ultimately no progress had been made.
As I unraveled this in my mind on that drive I discovered a new aspect of my personality: when I have confidence in the structural foundations of a group…anything is possible and all problems are solvable, but when I feel the structural integrity is compromised, the weight of the problems are heavier and solving them is more like wading through treacle. Some may see this lack of structural integrity as a risk, but I instead see it as an opportunity to build strength back into that foundation to re-enforce the wider group.
In other words, where confidence exists in the structural integrity of a group, it unlocks a fantastic world in which anything is possible, where all problems are solvable, and where the unity of the group builds a strength that is beyond the capabilities of any individual; this is the true opportunity of *community*.
This realization, while seemingly obvious, and sitting in front of my eyeballs for this entire time, was a revelation for me. It equipped me with a new way of looking at communities and groups and identifying where the foundational opportunities are (to harness and help those folks to be successful), as well as the foundational risks (to face those risks directly to protect the opportunity inside the group from being eroded).
When I arrived at the room and met with the project members, I confronted the issue head on. I shared what I considered to be the weaknesses in our structural integrity, and interestingly, there was fully unified agreement over the weaknesses. What was once subconscious to all of us had now transitioned into a shared problem that we were all invested in solving.
…petting a small horse with a mullet.
After all of this started forming in my head, I started thinking about how these lessons could apply more widely to community.
## Mission and Ethos
Challenges of foundational integrity become more challenging when your community scales up. When you are a small community where everyone knows everyone, you can confront foundational problems straight on, just as I was able to do so with my project; there were only a few of us, we talked it out, and put together a good action plan for resolving the problems. For a larger distributed community this can be more complex.
Larger community (such as Ubuntu) also attract many different people from different backgrounds, different disciplines, and with different priorities. As my thinking progressed, I started thinking about how as a community leader I could (a) identify structural weaknesses and (b) identify how to resolve them, and (c) provide re-assurances to the wider group that the structural integrity has been strengthened, which open up further potential for the community.
I raised this as a topic at the recent [Community Leadership Summit 2012](https://www.communityleadershipsummit.com/) in Portland. We had an awesome discussion session, and out of the many stories and experiences, many gems of wisdom were uncovered.
When a community scales extensively and a diverse range of people are working on different problems, it can be easy to identify other teams (with their different focus and priorities) as potential structural deficiencies in your community. In the session we came to the conclusion that structural weaknesses primarily occurred when an individual was not operating within the *spirit, ethos, and best interests of the community*.
There are countless tensions in communities along these lines. This is often seen in software communities with a commercial backer, such as the engineering team painting the business team as a bunch of filofax yeilding, foppy-haired sales-people with suspicious intent and values, and the business team seeing the engineering team as a bunch of stuck in their ways dorks who have no idea of the real world and what people want.
This is a mistake. In these kinds of communities both teams bring tremendous value, but their priorities, goals, and driving forces are not the same, and as such need *translating between different cultures in the community*. Such views of foundational weakness is often driven by a misunderstanding of the value and function of these different teams and what they bring. As such, strong foundations in different disconnected teams can be called into question because of cultural misunderstandings between these different disciplines.
The poster child for different cultures coming together.
A gem from the discussion session was that what unites these different teams and keeps the foundations strong is a common understanding, appreciation, and furthering of the core mission of the community, while always working within the values of the project.
As an example, in Ubuntu, we are working hard to build a pervasive, elegant, and feature-full Free Software platform. We have a core set of values that guide us in doing this work: to be collaborative, respectful, and make Ubuntu available to all, in each user’s native language, irrespective of disability. When I feel my colleagues have a firm understanding of this mission and ethos and subscribe to it, I feel we are on the ball. When someone does not, it raises a flag about their understanding of where we are going and the spirit in which their work is executed. In communities our *values* are a core part of how we collaborate together.
I came out of the discussion session with two primary outcomes:
1. Always keep your eyes open for areas of foundational opportunity (great, inspiring, motivational contributors or cultural elements that help people to be collaborative) and foundational weakness (problematic people who are resistant to progress and evolving your community in the right direction or complexities in how your community gets things done) and *confront those foundational issues* as a shared problem that can be solved (obviously be sure to not turn this into a witch hunt against people who you consider to be an issue, but make it an open and frank exchange of problems and solutions).
2. Re-enforce and unite your wider community behind the community’s core mission, ethos, and values. This will be the fabric that binds disparate skills and groups that are all moving in the same direction under the same umbrella. This will mean reminding folks of the bigger picture and how their jigsaw puzzle piece fits in and providing inspiration, particularly in times of crisis or tiredness.
This is definitely a topic that is still evolving in my mind, but I wanted to scribble some things down and I am keen to hear your thoughts on this topic too. Thanks for reading!
Community Leadership Summit 2012
*Click to see bigger*.
With a busy week away, I am just catching back up with everything. I just wanted to take a few minutes to talk about the [Community Leadership Summit 2012](https://www.communityleadershipsummit.com/) that happened the weekend before [OSCON](https://www.oscon.com/). You can also read a [wonderful write-up from Andy Oram](https://radar.oreilly.com/2012/07/social-networks-are-not-communities-and-other-discussions-from-the-community-leadership-summit.html).
This was the *fourth* Community Leadership Summit, and I was delighted with how everything went. We had a wonderful turnout with around 280 people joining us, and a fantastic breadth of sessions from our attendees. Topics of conflict, governance, gamification, diversity, collaboration, structural integrity, scale and more all generated great discussions and I think every one of us who joined the event took away some lessons learned.
I was delighted to see the sheer diversity of attendees at the event. Not just in terms of gender and race, but we also had people coming from all over the world (including Japan, Australia, France, Belgium, Taiwan, and of course..the Bay Area 😉 ) and from a variety of different backgrounds in technology, government, education, charities, commerce, banking, and more. It was a truly eclectic crowd, and when I asked who was at CLS for the first time in the opening plenary, nearly half the audience put their hands up.
I was also stunned to find out that a significant number of people flew out just for CLS and not OSCON. It is wonderful to see the event gaining traction as the primary annual meeting for community leaders, managers, stewards, and more. I would always encourage attendees to CLS and OSCON to join both events; they present a fantastic range of content.
I want to offer my thanks to my everyone who helped with the event (*Van Riper, Dave Nielson, Jon Johns, Marsee Henon, Benjamin Kerensa, Jim Beret, Jeff Osier-Mixon, Lauren Kilcullen*, and others), as well as the following companies who supported the event with their contributions:
Each of the above companies supported the event within the core ethos of the CLS which I mapped out four years ago: a vendor-neural, independent event, that is open to all, in which we can share best practice, ideas, and help make our communities better.
Thanks to everyone who joined us, and I look forward to seeing you next year at the Community Leadership Summit 2013, which will be our five year birthday!
Interviewed by Scott Hanselman
Last week at OSCON I was interviewed by [Scott Hanselman](https://www.hanselman.com/blog/aboutme.aspx). It was an interesting discussion – in it we discussed community leadership, Ubuntu, meritocracy, governance, conflict, the community/company relationship, working with Mark Shuttleworth, and more.
You can [listen to it here](https://www.hanselminutes.com/328/the-art-of-community-with-jono-bacon).
Web App Integration In Ubuntu
[Mark](www.markshuttleworth.com) just presented some interesting new technology at OSCON, both using Juju to redeploy between different clouds with just a few commands, and integration of Web Apps into the Ubuntu desktop.
I wanted to follow up with some details of the latter. Firstly, you can see this in action in the following video:
*Can’t see it? See it [here](https://youtu.be/x7vF-AB7SF4)*.
A few notes:
* This technology will be available for 12.10 soon as well as available for our 12.04 LTS users in a PPA. Naturally this will all be Open Source.
* The team working on the Web Apps code have already built support for a range of the most common apps (e.g. GMail, Last.fm, Google Docs).
* This is a technology that our community can contribute to to add further support for different types of web apps. As an example, there are many more localized social networks in different parts of the world, and our LoCo teams can contribute support for those apps. More details of how to participate will be coming soon.
* Integration of web apps can utilize pretty much any part of the Unity desktop (e.g. HUD, Indicators, Menus, Quicklists, Launcher, Alt-Tab) to feel truly integrated.
* Adding support doesn’t require convincing the web app provider to support Ubuntu, we can build support without modifying the core web service at all (although a web service provider can add support for Ubuntu if they like). More details of this will be coming soon.
I have been using this technology recently and if you use web apps, it is *awesome*. Feel free to ask questions in the comments.
Steam on Ubuntu
Naturally, I am delighted with the [news of Steam coming to Ubuntu](https://blogs.valvesoftware.com/linux/steamd-penguins/). While everyone is happy about getting their favorite games on Ubuntu, I think there is another subtle yet important gem in this announcement.
Creating a AAA title such as *Left 4 Dead* is an expensive and time consuming process. This expense is not only in the conceptualization, design, and development of the title, but also the associated support, community, marketing, and distribution services. This has got more and more complex in recent years with the abundance of platforms; it is not as simple as just creating a title for a particular platform…a studio now needs to bring cross-platform development in-house (with all the tool-chain and QA work required) to support these different platforms. While cross-platform development saves development time, it still requires extensive investment.
The gaming industry is one driven by volume. The sheer level of investment required to deliver these games means that they need to be assured that customers will buy the games. Assuring volume in the early days required having strong sales channels (such as gaming stores), but in recent years the push to digital delivery channels such as Steam has reduced the need for these brick-and-mortar sales channels. The challenge though is that while there are fewer bricks and dorky games clerks, there are more platforms and a greater demand for AAA titles.
So in a nutshell, games studios and publishers still need to sell a buckletload of games to justify their investment. I am sure that this is no different for Valve with Steam.
The announcement of Ubuntu as part of this platform is a testament to the growth of Ubuntu as an emerging gaming platform. Valve are not the first, [EA have already delivered games in the Ubuntu Software Center](https://archivedblog.jonobacon.com/2012/05/08/ea-games-and-ubuntu/), [Carmageddon is coming](https://www.kickstarter.com/projects/stainlessgames/carmageddon-reincarnation), and we have an increasing number of Indie games (such as the [Humble Indie Bundle](https://archivedblog.jonobacon.com/2012/05/31/humble-indie-bundle-in-ubuntu/)) running natively on Ubuntu.
I know that Ubuntu’s continued focus on a beautiful user experience, growth in emerging markets (such as India and China), focus on wider device adoption (e.g. TV), and our evolving hardware and app developer relationships are all furthering the interest from publishers such as Valve and EA.
Valve bringing Stream to Ubuntu is another stake in the ground in the confidence of Ubuntu as a strong consumer platform. For many years our users have dreamed about playing their favorite games on Ubuntu and it is coming. How can you help? Vote with your feet…buy the games, enjoy them, share your excitement online, and this will help us to continue to grow Ubuntu as a strong gaming platform.
Thunderbird and Ubuntu
Regarding [Fabián’s concerns about Ubuntu and Thunderbird](https://www.fabianrodriguez.com/blog/2012/07/11/if-you-still-want-thunderbird-in-ubuntu), I can assure you that Canonical’s stance has not changed: we will continue to ship the brightest and best Free Software by default in Ubuntu. In terms of email clients, today’s choice is considered to be Thunderbird…at another time it may be another app.
Importantly, Thunderbird will be supported with security updates for the next five years as promised with the current 12.04LTS.
For those of you who prefer other email clients, there are many wonderful options in the *Ubuntu Software Center*.
Part of assessing our default application selection is assessing vitality and upstream activity. This will undoubtedly be considered in the case of Thunderbird in future Ubuntu releases, but let’s not forget something: just because a commercial entity decides to scale back their investment in an application, it doesn’t mean the project is going to die or bit-rot. What it will do is put some additional pressure on that community to attract new developers and participants and to continue growing and evolving the application. There is a great opportunity ahead for the Thunderbird community to grow, expand, and attract fresh new blood.
If you are critical of the news about Mozilla stepping back from investing in Thunderbird, why not join the Thunderbird community and help? From what I can tell, there are many ways of helping the Thunderbird community; see [here](https://wiki.mozilla.org/Thunderbird) for how to join the project.
In terms of the relevance of email on the desktop, speaking personally, I don’t consider Thunderbird to have solved all email challenges. There are many opportunities for improving, extending and refining Thunderbird, and I think the app could see some great work in terms of design, desktop integration, and email within the context of a social Internet. I really hope the Thunderbird community focuses on the wealth of opportunity that still lies at Thunderbird’s feet, and continues to grow and extend their community. While I am busy with my own things here, I am more than happy to provide any input or guidance on Thunderbird community growth and ideas if needed.