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. :-)

  • http://jonathancarter.co.za Jonathan Carter

    Even people who are at UDS aren’t always able to make all the sessions there (especially with so many sessions often running at the same time) :)

    It’s quite essential to post anything that has a big impact on Ubuntu to the ubuntu-devel (or if it’s even more importand, the ubuntu-devel-announce) mailing list.

    To be honest I’m not a big fan of you saying that you veto yourself from the technical parts. It’s understandable that you don’t want to make decisions if you’re not comfortable with them, but from the discussion with you on IRC a few days back I got the impression that you are actively not interested in the concerns from the community about the current implementation and simply dismiss it as some technical detail that someone will eventually deal with.

    I always took it for granted that putting a page on the wiki isn’t the same as informing the stakeholders involved of what is planned, but I’m sure your lesson might be a lesson for many other people. Maybe something to include in your next book :)

  • http://www.murrayc.com/ Murray Cumming

    Your communication problem is verbosity. You’ll get better results if you learn to cut.

  • jono

    It was not that I was not interested in the concerns of the community, but the concerns expressed were largely technical implementation ones, which I am not going to get into a discussion about because frankly, I don’t have the required experience to offer valuable commentary on.

  • http://atomicpoet.org atomicpoet

    From a PR standpoint, this is very good of you, but…

    Benjamin Humphrey has been very trollish of recent (I suspect to gain eyeballs to his blog). It was unfair of him to react the way he did toward the Ubuntu Software Center. I don’t doubt that he cares about Ubuntu, but the way he’s been dealing with things has been counterproductive.

    You, Jono, need to deal with this problem (and it is a real problem).

  • http://jonathancarter.co.za Jonathan Carter

    Hi Jono, thanks for the reply. I might not necessarily agree with your position there, but I do respect it.

    Have you perhaps considered at some point getting, for lack of better term, a “technical community manager”? Or perhaps delegate it to someone like Daniel?

    These things can clearly be quite tricky. Thanks for all your hard work!

  • jono

    I don’t think it is needed – the implementation details are not a community issue, they should certainly be privy to community discussion, but the work involved is software engineering not community growth.

    What I think does require community management experience is the governance and process elements as it basically involves people coordination, and that is why I focused on that.

  • jono

    What problem are you referring to?

  • http://blogs.gnome.org/aklapper andre klapper

    Isn’t “I should have had a conversation with the community on ubuntu-devel before taking it to the Ubuntu Technical Board” pretty much the same as “I should have had actively explained and discussed my module and its progress to/with GNOME’s community on desktop-devel mailing list before just popping up to propose it for inclusion in GNOME and then wondering why GNOME people are not convinced”?

  • http://yokozar.livejournal.com Scott Ritchie

    It’s not that dissimilar Andre, and I do believe this is a lesson for the rest of Ubuntu to follow.

    I believe I even had a discussion about it with Mark at one point – he said something to the effect of “mailing -devel is the last thing you do”, saying it’s more important to have personal conversations with important stakeholders.

    As Jono’s story so vividly illustrates, this is probably wrong. Mailing -devel is the first AND last thing you do.

  • James

    If more high profile people were willing to admit their mistakes an apologize, I believe the world would be a better place. It seems to go against our culture to admit that we are wrong.

    I am glad that there are efforts to make adding new applications to Ubuntu / software center easier. Someday I’d like to add something I’ve written. Plus, I am sure it will encourage more great applications for a great Operating System.

  • http://CapturedTech.com Steve

    I agree that implementation details are not a community issue.