Home > Ubuntu, Ubuntu Server > Getting more developers interested in Ubuntu

Getting more developers interested in Ubuntu

Answering Jono’s question on how to get more developers interested in participating to Ubuntu. I think the key issue is to lower the barrier of entry.

Let’s look at the process of bug fixing in the “current stable” release for example. Consider someone that knows how to fix the issue in the upstream code. That person still needs to:

  1. Figure out if the fix should go upstream, in Debian or in Ubuntu (and potentially get flamed in the process)
  2. Figure out that the SRU process applies in that specific scenario
  3. Understand patchsystems enough to translate his fix into Debian packaging
  4. Figure out our changelog and version numbers conventions
  5. Submit a branch merge proposal or a debdiff and a SRU report
  6. Wait to get sponsoring
  7. Watch the fix climb the ladder of -proposed and -updates

That’s expecting a lot from someone that already knows how to fix the bug. Ideally, a drive-by contributor should just have to:

  1. Propose the fix (as a patch to upstream code), which is automatically translated into the right package update proposal, and built
  2. Wait to get review
  3. Watch the fix climb the ladder of -proposed and -updates

We are not nearly there yet, but I think that’s what we should aim for. Abstract the complexity of Debian packaging and of our processes away from the developer. And evolve the tools so that the review is a fast and painless process. The reviewer should not have to build the package himself, the review process should prepare that for him. Only the proposals that build would be proposed for review. The reviewer would review the patch, and use the pre-built binary packages for quick testing.

You’ll tell me this is all the ultimate goal of the DistributedDevelopment initiative. Well, we need to move faster in that direction, affect more resources to it. Otherwise you can do all the DeveloperWeek sessions you want, you’ll always get less developers than you could.

I remember seeing a presentation from Simon Wilkinson at UKUUG Spring Conference 2010, about how moving to an integrated git+Gerrit workflow allowed OpenAFS to double its number of developers. I think if we successfully abstract the complexity of our historic processes out of the prospective contributor, and make the reviewer job easier, we can achieve the same.

Categories: Ubuntu, Ubuntu Server
  1. August 24, 2010 at 16:24

    > Abstract the complexity of Debian packaging
    > and of our processes away from the developer
    There is no complexity that should be abstracted away. It’s a simple and easy process. If someone does not understand it or does not want to learn it, stay way.

    > Propose the fix (as a patch to upstream code)
    Packages already ship patches which means that such a new patch can often not be applied.

    > The reviewer should not have to build the package himself
    Yes, teaching them bad practices right from the start is really going to improve Ubuntu’s quality. Building a package and testing it is one of the most important parts.

    • Thierry Carrez
      August 24, 2010 at 18:22

      > Building a package and testing it is one of the most important parts.

      I’m not advocating reviewers should not test that the package builds. I’m advocating that they should not even be asked to review a package that doesn’t build. By having some automatic build of every proposed bugfix, you would (1) weed out bad candidates and (2) win some time for the reviewer, since otherwise he has to build the package himself.

      This is not about teaching bad practices, but about automating good practices.

  2. August 24, 2010 at 18:07

    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:
    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.
    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.
    If you don’t know what a PHP/WordPress function does, the Codex explains things in plain English, including examples.
    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.
    You don’t need to compile anything, or even to know how to compile anything. Just upload it by FTP.
    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.

    • August 25, 2010 at 19:36

      Same experience here. A few decades ago, I was a programmer. I’ve been writing code informally for years. I find it a fun hobby and use it like any other language (English, French, etc).

      I was amazed at how easy it was to mess around with the WordPress code. In fact, I didn’t even look at a tutorial. I just opened up the source and it was all fairly self-explanatory. I repeat : If I spent one hour looking at tutorials, that would be “a lot”. I still haven’t looked at a php handbook.

      So, I was looking forward to writing some little mini-apps (using Python) for personal use on Ubuntu. Ouch.

      The bottom line :

      1) What I want : start an IDE tailored to preferred Ubuntu programming components, create app, create one simple runnable file at the click of a button, put file USB key, copy onto any Ubuntu, double-click file to run.

      um, I like IDEs. And I like them to be mainstream with full updating support. Writing code for millions of people is fun. But I think a lot of Ubuntu programmers (even super-professional guys) want to start by writing little programs that help them to get their own work done faster, cheaper, better.

      I tried all the Ubuntu programming stuff I could find (ERIC, Glade, etc). What a bunch of puzzles. Very powerful systems but they are not focused. As the kids put it : ‘Too much information, Dad’.

      So : an IDE with drag and drop GUI programming that uses the preferred Ubuntu components is essential. If that’s GTK with Python : great.

      Quickly is a complete non-starter for me (I tried it). I want to : start the IDE, create a project, drag and drop my components into my interface (without worrying about them magically changing shape and size in tricky and confusing ways), write (or copy+paste) some code and run my app without having to wonder if my PATH et al are OK on my various computers.

      Turn Quickly into an IDE and include it in the automatic updating process. Have a one-click menu option called ‘create runnable Ubuntu package’ that would create one file (that, for instance, contains all the resource files, etc) that any Ubuntu computer could recognise and run. No full ‘install’, please (unless I specify that). Just ‘run’ (like a Windows exe file).

      We all know the iterative drill for small, personal apps : create something, use it, take a few notes, tweak and improve the little app, reinstall. Rinse, repeat.

      2) Submitting bugs.

      Automate this as an explicit user choice.

      You could have a little app called ‘Check log files for weird stuff’. This would a) look at all the log files and pull out all the error messages that a pro would look for b) show the file as a simple text file (so I can see what information is in the file) and have a button called ‘Send to Ubuntu the next time I Update my Computer’.

      So, people who are interested in helping out could run the app if they feel like it; check the content to see if they are comfortable with the information that they are sending; and (if they approve sending – each and every time they run the app) it would be sent to Ubuntu folks as part of the automatic updating process.

      This is not something that the average person would use but a person who is thinking about helping out with debugging would be able to get comfortable with the error messages that pros find useful to look at.

      For instance, I’d use it!

      3) Videos. I’m tired of looking at acres of text every day. Short tutorial videos are extremely effective. In your blog post you list 7 steps. To me, it sounds like 7 good videos would help out a lot. They don’t have to be Hollywood video productions. I like to see what you see on your screen when you are explaining something.

      4) Conclusion : Points 1 and 2 let professional programmers try out Ubuntu programming and orient themselves with the kind of information that Ubuntu produces for debugging. People who are considering helping out could help out *immediately* by sending in their filtered logfile data via automatic update.

      Point 3 is important for *everything*. In fact, the ideal case is that every single menu item in Ubuntu would have a way to one-click ‘Watch Video Tutorial’ so that people don’t have to fish around on the internet for information.

      Just some ideas. Until the official Ubuntu IDE is available (using Python 3+ so that Unicode characters are fully supported and natural to work with…) I will just continue writing apps with Javascript/XUL/HTML/CSS.

      And thanks to all the people who are actually creating Ubuntu code! The term I like is : ‘Removing barriers to entry’. The punitive thinking like : ‘If you’re not smart enough to figure it out then you’re not smart enough to help out’ is elitist nonsense.

      Humans do more than hang out with their computers! Make it easy for people to express their gratitude and they will! I would suggest that there are a lot of very smart programmers who would like to help out but (imagine that…) they are *so smart* that they are very much in demand and don’t have a lot of time to invest in figuring out the Ubuntu work flow model.

      Thanks to all!

      Namke von Federlein

      • thijz
        August 26, 2010 at 10:37

        spot on !

        i just hope -and think- things will get easier in general in the linux (ubuntu) world.

        It’s already happening on the desktop with things like SWcentre, crashreport etc, but that’s all aimed at the regular user > and -dont get me wrong- that’s a good think !
        Now the same needs to happen for the development.


      • September 8, 2012 at 16:05

        wow !! Am trying to be an Ubuntu app developer !! I do not know how to develop, All I know is c++ ( basic stuff:classes for while you know the basics) However, after reading your post I learned a lot and what my next step is.
        and since we are in 2012, Did you notice any changes or Did someone make a video tutorial on how to be a MOTU ? Did the Ubuntu team made the launchpad interface easier ?


      • Thierry Carrez
        September 10, 2012 at 08:04

        The main difference two years later is the introduction of Ubuntu application development, which provides an alterbative solution to learning Debian packaging and policies. See http://developer.ubuntu.com/ for details…

  3. August 24, 2010 at 18:13

    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.

  4. August 25, 2010 at 12:10

    I’m a bit of a drive-by contributor. When I find a bug, I generally report it, sometimes in ubuntu (in which case it usually gets moved by someone else), sometimes upstream (if I’m sure it lives there). Then I try to build latest version of the code from upstream (since every one of the bugs I’ve found lives upstream). If I can reproduce the problem in the head of the tree, then I fix it and submit the patch to the bug report.

    Once I’ve done that, I either make some tweaks to the patch as requested, or just sit back and wait… and in a few weeks/months the fix ends up on my computer like any other fix. I’ve never built a .deb in my life.

  5. August 25, 2010 at 14:49

    Plain and simple, as long as my code contribution requires me to sign the CoC, ain’t gonna happen.

    • Thierry Carrez
      August 25, 2010 at 16:09

      Interesting, what do you find unacceptable in the CoC ? Or is it just about “I don’t want to sign anything” ?

  6. August 25, 2010 at 20:52

    I’d use Ubuntu daily, am an expert in all Ubuntu’s languages (C, C++, Python, Bash), and have used (non-OSS) source control.
    I report bugs as I find them, but I don’t have next steps to getting the packages’ dev branch, or returning back the changes (to who, how).

    I would like something like:
    $ fixUbuntuBug 12345
    That bug is against , downloading to current directory. When complete, run “offerPatch.sh”. Change trees are available here. Ask questions via IRC here.

    I would be able to accomplish much more, even if it required my CoC complete (it is). Is anything like that?

  1. November 3, 2010 at 01:21

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s