Getting More Developers Interested In Participating In Ubuntu

I am just beginning to get into the planning stages for the next cycle for my team, and as part of this cycle we would like to really focus on attracting more developers to participate in Ubuntu. We would like to see more people interested in getting involved in packaging, fixing bugs, and joining our community. Daniel Holbach on my team will be leading much of this work.

Right now the 11.04 planning slate is clean, and we are looking for what you all feel are the areas in which Daniel’s time and effort would be best spent in the interests of having more people participate.

Where do you think we should focus our efforts?

  • Jacob Peddicord

    Make it easier to submit and review new software for developer releases. Currently we have REVU and submitting to Debian, both of which it seems you have to know someone to get anywhere with, unfortunate as that may sound.

    I know you’re trying to resolve this with the introduction of the App Review Board, but I don’t believe that is the right way to go about it. (Nor do many others, as is evident on the mailing lists.)

    I’m not sure what the right solution is, but I do know it’s a bit of a pain to try to bring in new software right now.

  • Jacob Peddicord

    s/developer/development/, but you get the gist. I think that when it is easy to submit and maintain software to Ubuntu from an upstream standpoint, people will be more enthusiastic to help out in other areas.

  • ethana2

    In addition to ensuring that ubuntu browsers identify properly, official development documentation for Ubuntu should highlight only one of each type of API.

    For instance, GTK handles drawing windows. Leave out X11. PulseAudio handles audio. Leave out ALSA. Developers shouldn’t have to evaluate different interfaces for a single individual function. Ever. Pick the ones Canonical supports and make them part of The Ubuntu API, then document the heck out of it.

  • Tommy Brunn

    I fully agree.

    Packaging overall also needs to become easier. You don’t want to have to spend a full working day just trying to set up a PPA.

  • Grant

    Bit of a personal agenda here, but still a potential avenue: Education!

    If there was an easy and clean way for schools (11-16yrs) and colleges (16yrs+) (and universities, but to a lesser extent) to become involved, we could potentially reach a tonne of new blood for the community – developers and more.

    I am very keen on the DFEY ( project that has sprung up back here in the homelands and think it could lead to to great things if done right (hence my reading your book).


  • czajkowski

    To answer your question in how to get more people involved in dev/bugs/patches. I’d love to see every 2 months one day picked to be a mini ugj day online. Have UGJ the big 3day event happen each cycle.

    The idea being the one every two months or even once a month would be to get people triaging bugs or submitting patches. Even having aweekly tutorial from nigel and others to train people so they can learn how to review patches would help.

    Many people want to help, but either don’t know how to help or are afraid, sometimes we need to teach them in order to get them to contribute back.

    Getting locos involved in this kind of regular event would make them feel more a part of the ubuntu community and can see their work making a difference so it is encouraging them to help.

  • nice1

    remove copyright assignment.

  • Joseph Watson

    If there isn’t one setup a wiki or other such how-to page on how one goes about developing for Ubuntu. Something explaining the whole process to those who don’t know already.

  • Matthew Walster

    Ubuntu has probably the lowest barrier to entry of any mainstream Linux distro, especially when it comes to development.

    What would be nice is if there was a prominent walk-through of “how to get your software into Ubuntu”.

    For instance, someone starts with an SCM checkout of a piece of software (something Gtk based, maybe Pidgin) and runs through how to get it into a PPA – screenshots, guidance, notes from people who’ve done it etc. Then, how to go from PPA to packaging for MOTU.

    I realise my next idea is a bit “out there” and probably unworkable, but it’d be nice to see a tutorial for someone who currently has a Windows app, how they can easily port it to Linux (“easily”) with the minium of fuss. Not necessarily the “right” way, just a quick way, then subsequent tutorials would show you where work needs to be done to make it pretty.

    I say this because there’s a lot of people who develop for Windows because “it’s what they’ve always done” and wouldn’t have the foggiest idea of where to start in Linux, but don’t want to have to start from scratch.

  • Bob Mottram

    A few ideas which might make developer participation easier:

    a) Improve the Launchpad user interface. I find it clunky and not very intuitive. A simplified and cleaner looking Launchpad UI would be a great help. For example a button or tab to browse the code in one click, similar to Google Code.

    b) Quickly to support languages other than Python. I’m not dissing python, but developers sometimes use other languages too.

    c) A more advanced idea. Add a button or menu item to the Gnome menu or title bar (on the right?) called “view code”. Developers can then add links in their code, or maybe into the package control file, to take the user to the exact point in the code repository for what’s currently being displayed on the screen. I think this was a concept originally envisaged for OLPC. I realize that this could involve quite a bit of work to implement, but it would encourage folks to be inquisitive about the code behind their favorite applications.

    d) Within the software centre add a “Get involved” button, which links to a page containing information about how to participate in the community for a specific application. Again this might involve having an extra field in the package control file. The idea is just to make it as quick and direct as possible to find out about how to participate in a project, without needing to do web searches.

    e) Within bug reports add a “bounty” feature. This allows users who are suffering from a particular bug to put up bounties of small sums of money or prizes which go to whomever submits a patch which fixes the bug. Perhaps bounties could be payed to teams rather than individuals to avoid too much squabbling, with allocation then being a team decision.

  • Jacob Peddicord

    I’m not sure why I’m responding to this, but I’d like to point out this is what may make some reluctant to contribute to Ubuntu, even if it’s not required by many projects under the Ubuntu umbrella. When talking to people about Ubuntu and development, copyrights always seem to make their way into the conversation.

    I realize this might not be possible, but just venting. Personally, I don’t find issue with the policy, but others apparently do.

  • Jacob Peddicord

    a) I agree; getting a project set up especially requires a lot of clicking.

    b) Could be useful, but not many other languages are as “quick” to implement as Python. 😛

    c) Sounds cool, but you’re right: it would be a PITA to implement everywhere. When clicking “View Code” at a certain location, you’d need to know what source file to unpack and open, whether to show the UI file instead, or do something completely different. It sounds like a good idea in theory, but may not be entirely practical.

    d) I like this as well.

    e) Ubuntu has had bounties before (quite some time ago, really) and I’m not sure how well that went or what became of them. Remember, this is open-source development, and most software projects can’t afford to pay bounties. This makes some projects good Google Summer of Code candidates, though. :)

  • Skitsanos

    I would love to see something like Mono Tools for Visual Studio that can create Appliance with Ubuntu, this would be definitely very attractive. Plus look how SuseStudio is comfortable, why don’t we have something similar with Ubuntu?

  • TrueTom

    Make smart decisions and you might attract smart people. Also it’s funny that no developer has commented yet.

  • el_ingeniero

    Have to really echo this sentiment. I think as a part time windows developer who has been really interested in developing for linux. I find that I have no idea where to start and ubuntu was an easy way for me ot get started atleast using linux. But sure would be great if someone in the know pointed me in the right direction with some clear directions. Barrier for entry in Windows world is low in that sense.

  • Killerkiwi

    Quickly solved the packaging issue for me.. but how do you then go from that to getting into ubuntu its self? The only time I’ve seen this happen a Debian or ubuntu packager has appeared how wants to personally use the software so it makes it in

    A submit to “Ubuntu Web Store” button in lunch[ad would be cool.

    Also I’m not sure if I saw this some where else but high level desktop apps should not have to wait for a 6 month release to be available in ubuntu. PPA’s are filling this gap now but some thing more official that integrates into software manager would be nice. Imagine an iphone/andoid store where you only got new apps with an OS release….

  • Greg


    The most important thing you can do is to improve this page:

    List some specific to do items that, give a short description of the need, and a link that fully explains it and who to submit the patch to.

    Another idea for the page is to list skills, and when a person clicks “Interface Design” send them a to do list of projects related to Ubuntu that need design help.

    Other ways you could increase contribution instead of lowering the barrier is to up the rewards. To echo what other’s have said:

    1) Take donation bounties on… award them to people who work on tasks. Start with interface designers.

    2) Let people know their contribution will be used in Ubuntu if they write code to do XYZ. No one wants to spend a week writing 100 lines of very hard code to have it sit as a unused patch for months or years.

    3) Have Mark (or others) praise the work of a free contributor on his blog. One person receiving social reward for their work will inspire many.

    Lastly, you could accept volunteers as “employees” of Canonical. This would give them a say inside Ubuntu teams even though they aren’t paid for their time.

  • Owais Lone

    I think you should repeat what you did last cycle. Hold a couple of developer weeks, improve quickly and try to promote it. Quickly is a great tool but I feel it has not been promoted as much as it deserves.

  • Kurt

    I do not know if this has been done already, but holding talks on conferences such as FOSDEM could inspire people. The benefit of conferences such as FOSDEM is they attract a lot of non-gurus: people who are interested in the idea and philosophy behind opensource, but who do not know (yet) where to start. If you could implement some of the ideas listed above (such as the one suggested by Greg), you can hold a nice tutorial session about how to develop for Ubuntu…

  • Phil Bull

    Better developer docs and tools, of course! As it happens, there’s a GNOME hackfest on this very subject in December:

  • Getting more developers interested in Ubuntu « Seeing the fnords

    […] Posted August 24, 2010 Filed under: Ubuntu, Ubuntu Server | Answering Jono’s question on how to get more developers interested in participating to Ubuntu. I think the key issue is to […]

  • Thierry Carrez

    My take on what we should do to get more developers interested in participating to Ubuntu:

  • huats

    I do think that we should encourage the mentoring. I have ran the MOTU mentoring reception for months, and it is realy something that we can improve… The only missing thing is manpower : mentors (who are experienced developpers) are almost already without free time, and the reception is lacking manpower to do a proper followup of the mentees…

    We are trying to put it on track with the help of Daniel, so let’s see where it goes…

  • Marcel

    I do completely agree with Thierry on this point. I contributed (mostly minor) patches to several FOSS projects, but almost exclusively simply sent the patch to the upstream bug and waited for it to trickle down to Ubuntu in the next release… The packaging/patch systems etc. stuff is the biggest barrier for someone who already knows to program quite well.

    That said, bug triaging with Launchpad is very easy.

  • zzzanzzzara

    Where do you think we should focus our efforts?

    Don’t alienate them. It’s a good starting point.

  • Mackenzie

    For people who aren’t currently packaging, patching, etc. I asked on StackExchange for input on what prevents you from doing those things.

  • Mackenzie

    Debhelper 7 didn’t make it easier? In the cases where the software has a sane build system already (the vast majority), debian/rules becomes a 3-line file that’s exactly the same everywhere. debian/changelog and debian/copyright are dead-simple. debian/control becomes the most difficult thing, where all the difficulty is summed up as “how can I adequately describe this?” and “did upstream provide a full list of dependencies?”

  • Mackenzie

    They don’t have to wait 6 months. You get it in the development release and request a backport at the same time. It gets uploaded to the development release, and as soon as it builds successfully can be copied to backports.

    Some people seem to think this is insufficient, so there’s some new App Review Board thing happening to make a section of the Software Center that supposedly will be clearly delineated as Totally Not Made By Ubuntu People For Real Yo (to keep us from being blamed) with packages provided by upstreams in a stable release.

  • Mackenzie

    Your last one doesn’t make sense to me. Anyone, developer or not, can participate in Ubuntu Developer Summits (where decisions are made). You can show up in Orlando and participate. You can participate over IRC. Up to you. A handful of community people get sponsored by Canonical to attend, so being a Canonical employees is not required to have your voice heard.

    I participated remotely in Dec 2008, attended in May 2009, and became a MOTU in Nov 2009, a week before attending another UDS.

  • Mackenzie

    The first time I submitted a patch in Ubuntu, “can you make a debdiff?” was one of the first things I was asked. Thankfully the person asking was a core-dev so did it for me.

  • Tachyon Feathertail

    Speaking as a PHP noob who’s released his own WordPress plugin (based on existing code from another one), WordPress has a number of advantages over Ubuntu that encourage participation:

    1. You can see the source for everything, and you don’t have to learn how to “check out” code separately from downloading plugins. It’s just there, waiting for you to poke at it.
    2. When you do start poking at it, the source looks like HTML. The added PHP syntax is often self-explanatory. I was able to tweak plugins and themes without having taken a single class or tutorial.
    3. If you don’t know what a PHP/WordPress function does, the Codex explains things in plain English, including examples.
    4. If you don’t even know that the Codex exists, just Google whatever it is and there’ll be an article where another WordPress amateur is explaining it.
    5. You don’t need to compile anything, or even to know how to compile anything. Just upload it by FTP.
    6. Even the procedure for submitting a plugin or theme to the repositories isn’t too complicated, and is — again — spelled out in plain English. I got hung up on using svn for a little while, but finally figured it out and submitted Lightspeed Links.

    PHP and WordPress both draw tons of flak for having such amateur code, but the alternative to not having amateur code isn’t having professional code; it’s having less code, and fewer developers of all skill levels. Because the amateurs learn by doing.

    Compared to WordPress’s learning curve, Ubuntu’s a brick wall where everything’s always explained somewhere else, no one tells you where to start, and everyone takes it for granted that you already know how to do (X). That’s why the web’s filled with tutorials on hacking WordPress, written so complete newbs can understand them. While Ubuntu tutorials are fragmented, crammed full of technical jargon, and opaque to those who haven’t learned the prerequisites.

  • Tachyon Feathertail

    Another open-source project that is newb-friendly and encourages participation is Dreamwidth. Many — if not most — of their devs are learning Perl for the first time, and are actively mentored and given small bugs to fix. I haven’t tried it myself, but I’ve written a ton of suggestions for Dreamwidth, and their community is legendarily friendly.

  • Tachyon Feathertail

    Aren’t most people on Stack Exchange already skilled devs in some way?

    Where would we go to ask people who are complete noobs at this hacking thing, but could probably be good at it if someone showed them how?

  • Tachyon Feathertail

    “Developer” docs and tools, though, only help people who are already devs in some form, fashion or another. Where do you go to learn how to help hack Ubuntu, or write an app or a game for it, if you’re starting from scratch? And where is it explained, in the Ubuntu community or documentation, that this is how?

  • Tachyon Feathertail

    What about everyone who doesn’t get to go to one of these conferences? I’ve never been to WordCamp, but I submitted a WordPress plugin because their docs and community made it super-easy.

  • Mackenzie

    No, Stack Overflow is the programmers-only Stack Exchange.

    Stack Exchange itself is simply a question & answer site. There’s a Stack Exchange for Ubuntu, one for LaTeX, one for English grammar, and proposals for studying Japanese, for academics, for Christianity…for just about anything.

  • Tachyon Feathertail

    I’m looking at that page you linked to, and as a newb it makes almost no sense to me. Where are the instructions for someone who wants to get started but has zero technical understanding?

    Sure, I could take a Python class somewhere, but how does that translate to making an Ubuntu app (and console mode doesn’t count)? Why isn’t the first thing in that article some kind of super-easy Quickly tutorial, starting with the basics of Python and leading on into Glade and packaging? Because I was excited when I heard about those, even if I still have no clue how to use them.

  • Mackenzie

    For most source packages, you can view the code by visiting

    For example: Click which Ubuntu release you want to view, then click “view the branch content”

  • Mackenzie

    The comment parser ate my comment! First link should have said<source package name here>

  • Mackenzie

    Dear WordPress: stop trying to be cute!

    OK, so after the +source and the slash, you’d type the name of the source package.

  • Tachyon Feathertail

    c) So how the heck do you view code for anything, if you aren’t already a skilled dev?

    There’s a major feedback-release cycle for just poking at PHP or HTML, and going through rapid iterations of it, because the files are all uncompiled code and trying the newest version just involves uploading it. And you’re playing with the raw files even if you’re a nontechnical user, and the syntax is easy to understand. Ubuntu has none of these advantages, and darned if I know how to even get started with it.

  • Tachyon Feathertail

    Agreed. XNA, Code4Fun and all that FTW, plus Visual Studio Express. I’m not interesting in writing a Windows app, but if I ever wanted to start Microsoft has me covered.

  • Tachyon Feathertail

    I dunno, a lot of nontechnical people share code and resources by default; just look at tutorials for modding your LiveJournal layout, WordPress blog or forum sig.

    Open-source would be easy to explain to these people. The GPL (or CC-By-SA) is just a license that makes it so everyone has to share, and can’t take your creations and run with them and not give anything back.

  • Tachyon Feathertail

    Hear hear! Python + Quickly’s becoming the default way to write Ubuntu apps, too; now we just need prominently-displayed tutorials, that walk a newb through everything. Next step would be helping them patch each other’s code, and creating a community of some kind.

  • Tachyon Feathertail

    That may be the theory, but I clicked on the “Stack Exchange” button in the upper-left and almost every question listed was technically-oriented. There were a couple of cooking-related questions, but Yahoo! Answers or Metafilter it isn’t.

  • Mackenzie

    Python’s uncompiled and the preferred language for Ubuntu desktop development.

  • Tachyon Feathertail

    In retrospect, I think Ubuntu has all these advantages already; just for using it, as opposed to developing it. The fact that you could get started using Ubuntu, and it looked familiar and you could get help for any aspect of it, is what’s launched it to its status. (And simultaneously earned it scorn, derision, and later envy, from members of more technical and insular communities.)

    I’d love to see Python+Quickly become household names along with Ubuntu, and make it almost as easy to code an Ubuntu app as it is to write WordPress plugins.

  • Mackenzie

    And of course all of Ubuntu-StackExchange’s questions are technically-oriented too (remember, every site that uses SE’s codebase is still a separate site), but they’re certainly not all development questions. They’re questions about disabling the keyring, setting up a dual boot, changing settings, using apt, installing software, web browsers, network manager… all the same things people ask about in #ubuntu on IRC or on the ubuntuforums.

  • Michael Hall

    Adding a “Get Source…” entry into the Help menu of most apps, like we already have “Get Help Online…” and “Translate this Application…”.

    The entry could either take you to the launchpad page for the package branch, or actually perform the bzr branch into ~/Projects/ (which would let them work on it with Ground Control).

  • Rick Harding

    Just a link to my feedback/discussion on the matter

  • Greg

    Internal Canonical teams have the benefit of project managers, programming managers, coworkers, and schedules. External volunteers are entirely self motivated.

    Obviously Canonical can only afford to hire so many employees, but taking on interns or volunteers on a short term basis to “get their feet wet” should help to create more long term contributers.

  • Jonathan Rothwell

    Please record another vote in favour of standardising a collection of “preferred” APIs and interfaces (an all-encompassing Ubuntu API, if you prefer.)

    The two “main” OSes have them in the form of .NET on Windows (sueprseding Win32) and Cocoa on Mac OS X. Once a consistent and all-encompassing API is in place, it’ll be easier to then bring in some of the other comforts that developers for these OSes have – official IDEs, developer documentation, proper developer communities, etc.

    Of course, you can’t force developers to adhere to this API, but it should at least help to open the floodgates to more interested developers. At present, a would-be Ubuntu developer is presented with a bewildering array of choices for UI widgets, notifications, communications, audio, etc. etc. They might as well stick in a message saying “You have failed the first test: have you considered Visual Basic?” 😛

  • someone

    Please focus on moving existing Ubuntu developers into Debian.

  • viorel

    learn to be more transparent and remove a copyright assignment and to engage developers, who will be involved and will also bring other developers

  • Erik

    I think that there are plenty of people interested. They want to help. They want to make give back and make their favourite OS better. The problem is that they usually feel like they are standing at the foot of a very tall mountain. If they read a programming tutorial, they might have a hard time remembering what they are learning because they don’t have an easy way to use it. If they get the code for a program, they usually get lost because so much is going on that they don’t even know where to start and just can’t get the big picture of how it works. Then, if they do write something and go to packaging, they have to learn all about packaging AND makefiles. Eventually, someone will want them to send some of their work upstream, usually to Debian, who will want them to become the maintainer permanently. So, I guess, to summarize, there’s so much to teach yourself, and then once you get past that, then there’s things like maintaining whatever you’ve packaged for Ubuntu in Debian. Also, it’s hard for beginners to find small things that they can work on.

  • Christoffer

    As a Computer Science student(with experience with php, java and python) and a user of Ubuntu since 8.04 I would really like to get involved but last time I tried I just got stuck in launchpad with understanding everything from PGP to signing the ubuntu code of conduct.

    I believe the MOTU project is the way to go. Though there are some problems with it as I see it. While reading the “getting started” pages I ones again get overwhelmed with information and things I “should” do.

    To get the mentoring project working I would expect as a participant an hour or two “getting started” session over IRC/Skype and THEN be pointed to all the documents. Social interaction is everything here to get everyone to feel that they are a part of something bigger.

    Really like that you are starting a discussion about how to get more involved.

  • flipefr

    I just started yesterday reading the guide of packaking and making an OpePGP key and is really awful and almost all is in English, why don’t make easier the process for build a package improving pbuilder and a little more translation. I am learning and if everything is so complicated and need so much time I don’t have a doubt because there is no more developers

  • Neil Wilson

    Fairly straightforward. Realise that the core Ubuntu development process and team are becoming a bit insular and cliquey. The barriers are getting higher.

    That lack of openness freezes people out who can’t devote every waking hour to Ubuntu.

    Arguably Canonical staff should mostly be operating in enabling mode doing the stuff that volunteers tend not to want to do – organising lists, managing, doing documentation and getting feedback on the production system. Essentially managing. The ‘interesting’ stuff should really be left to volunteers whereever possible.

    Paid people should be doing managing, co-ordinating and encouraging. Daniel does a terrific job, but you need a lot more than just him.

    Have you thought about talking to charities about how they co-ordinate armies of volunteers? There might be some insights and experiences there that will help.

  • Tachyon Feathertail

    I’m sure Debian would be happy to accept all the work the Ubuntu devs have been doing here, and that there’d be few or no hassles integrating it. ^.^

  • Christoffer Holmstedt

    I’m not sure why but my post earlier today got deleted so I will try again.

    As a student in Computer science and interest in Ubuntu I’ve tried to get going before but I always end up overwhelmed with all the “Getting Started” pages.

    I believe a more social approach is needed. Instead of just giving links to getting started pages you should arrange weekly/monthly or quarterly “getting started” sessions over IRC/Skype or similiar. A session like this could include the basics with launchpad and a workflow walkthrough and THEN after the session it’s up for everyone to get going with reading the getting started pages and other needed resources.

    One of the most important things in the beginning is to feel that you’re a part of something bigger and your contribution is appreciated.

  • Chris Chinchilla

    As someone with some coding background who is keen to be involved, I’m not really sure where to start…

    I really need some sort of real world (as opposed to online) event to get me started, and there’s rarely any here in Australia…

  • Tachyon Feathertail

    Heh, belated thanks!

    I think I’ll drop by the Ubuntu app building tutorial later this month … if I can cram enough Dive Into Python first. >.>b