What are the biggest barriers to walking the MOTU/developer path?

For those who are not MOTU (people who maintain the Universe and Multiverse software repositories) and do not have plans of the "I will apply to MOTU by $date" variety:

What keeps you and others like you from trying to become MOTU? What makes you think you couldn't become one?

I'm referring to both social and technological barriers.

EDIT: I'm only saying MOTU because it's a pretty generic group, but "why aren't you packaging / patching and intending to eventually try for upload rights?" is an even more general version.

From ubuntu maco

• I think the biggest technical barrier is knowing how to create Debian packages. While it is relatively simple to create a working package, it is much harder to create packages up to the standard of Debian and Ubuntu. Also, the guides on how to create packages normally deal with a situation in which you have the source code that requires compiling. This can be confusing for applications written in interpreted languages.

  The biggest social barrier is probably knowing how to get packages uploaded into the universe/multiverse repositories. It is a lot simpler to just create your own ppa and upload packages there.

  From dv3500ea

• I think there a several reason for this. I also think the the reasons are often individual.

  One of the issues at this time, is the change in the whole MOTU system. I believe, the changes can be confusing, and have been implemented more on technological lines and unfortunately did not bring the community fully on board (maybe just because it is confusing).

  I also think, in some cases the motivation to be a MOTU is not as clear as it could be. IMHO, being a MOTU is a responsibility, not a privilege. It is not about the title, but about the ability to help the Ubuntu community by the access rights that come with it. Due to this, it could be that the whole approval process could be modified (or extended). MOTUs usually nominate themselves, and then the board looks if they are ready to be MOTUs. Maybe it should be possible, that peers that believe that someone is ready to be a MOTU be able to nominate that person. This would IMHO represent more the fact, that the nomination is done to help the process, not to obtain a title. I understand that making this the sole way has its problems too, therefore, I rather see it as an alternative then the only way.

  I also know there have been some problems in the past with people focusing more on KDE. These problems have hopefully been addressed, but maybe it would good if that would also be more widely known.

  Obviously, these are just a couple of issues that I have notice. People are different and will see different things, or be affected differently by the same thing. So, theses issues might not stop everyone, nor are they the sole reasons for this problem.

  maco : Sponsors *should* be telling the people whose packages they sponsor when they think they are ready, "hey, maybe you should apply now," but I don't know how often that happens. I've suggested applying to one person I was mentoring, but he changed his focus to other areas of development.

  txwikinger : It is still a difference when a sponsor tells someone to apply, or this person is nominated by a sponsor.

  lfaraone : Uh? Sponsors don't nominate people, Sponsors advocate self-nominations by the sponsoree.

  maco : lfaraone: txwikinger is suggesting that sponsors should be able to nominate people. It has happened once. Some folks went and created a wiki page for Sarah Hobbs and emailed the TB and gave testimonials and so by that point when there was a *clear* outpouring of support, then she showed up to the IRC meeting to take the last step.

  txwikinger : @Ifaraone: I am suggestion that some good people will not self-nominate themselves and we therefore lose them. In the end, a good person becoming a MOTU is a win for Ubuntu, maybe we should think about this.
  From txwikinger

• Nowadays people like drive-by contributions.

  20 years ago you would typically focus a lot of your energy on a pet project, if you had one. Today you visit dozens of Internet pages a day, and there are lots of social networks or other communities, where you can contribute to wikis, forums and other stuff. While this has led to more people contributing, it also led to people expecting low barrier entries (a la "just click the website to edit it). Otherwise they may just turn to other communities.

  Therefore you should look for barriers in the MOTU process. I remember the GroundControl project to lower the barrier for patch contributions in launchpad hosted projects. Maybe you need similar new tools, so new MOTU candidates don't have to fiddle with a lot of command line tools. While those current tools may be powerful, it probably takes a lot of energy to learn how to use them correctly.

  maco : I don't know if I like the idea of people who can't use the shell maintaining packages, since shell scripting is an important part of packaging (that is, there are shell scripts that you need to write / modify to make many packages work).

  Bananeweizen : @maco: Do you want to get new contributors or not? If so, you should accept that processes may need to change (and not just the people involved in the processes). Elitist thinking will exclude a large part of the potential community. And if you want to get a distributed effort to get started, the command line is generally a very bad tool to support that.

  maco : That's like saying "you need to know some C to write a kernel patch" is elitist. You just plain need to know how the command line works to write the scripts that go into a package. Even if you had a GUI for making a package, it'd end up with a bunch of "type the the postinst shell script here" textboxes.

  Bananeweizen : My comment was not about technical necessities. I'll try to rephrase (I'm not a native English speaker): First you ask for additional contributors. Afterwards I read in your comment: If you can't write shell scripts, you are to dumb to participate in packaging. That upsets me. I still believe your assumptions are wrong. Until Ground Control everybody had to know version control systems to be able to patch some project in LP. Instead of making version control easier, GC contrated on the single use case of patching and removed the need to know anything about version control systems.

  maco : I didn't say "dumb" anywhere. I said it's a necessary skill. For any somewhat-complex package, you *will* have to write a shell script. Ignorance (having not *yet* learned a certain skill) and intelligence are in no way the same.
  From Bananeweizen

• Provide better documentation.

  I have taken part in the developer weeks IRC sessions related to packaging and MOTU stuff (twice already) and found that during those sessions you typically have a vague understanding of the process. But if you look at the Ubuntu wiki pages two weeks later, you can't get all the pieces together anymore. Those pages often are kind of a bullet point lists from people who already understand the process in detail. But that is not enough to make the content understandable for newbies.

  So maybe you should try to get the documentation wiki pages explain the process, tools and people involved in more detail. Or even with complete examples. During the IRC sessions there are always repeatable examples, maybe those make the difference to the wiki pages.

  maco : I agree the wiki pages are not very helpful. I found Daniel Holbach's videos on YouTube most helpful when I was starting out. Are logs of the IRC sessions posted to the wiki?
  From Bananeweizen

• The biggest barrier I've found is the Ubuntu developer page: http://www.ubuntu.com/community/get-involved/developers

  So many times, I've gotten enthusiastically determined to contribute at least 1 patch to Ubuntu... so I go to the natural place on the website... and end up lost in a sea of documentation. Hours later, I still have no idea what I should write a patch for. When I look through Ubuntu bugs, I often find patches... many that just sit there unused.

  As far as packages go, I've tried to figure out how to make them, it's really confusing. I also tried to get involved in Launch Pad, but the interface is so much more complex than Source Forge, I couldn't get my own code on LP. It's very difficult for a new user.

  Owais Lone : Yes, launchpad design has a problem. Things are not obvious on LP. It's easy but you have to look for it a lot. New users quickly get lost. It needs a redesign to make it more obvious and simple like GitHub.
  From Greg

• Being a MOTU is a responsibility.

  Well, obviously the #1 reason is not technically knowledgeable enough, and the #2 reason is having a squillion things you'd rather do. But amongst your target audience, I think the main reason is that it's a responsibility.

  If I compile a package for myself, no one else cares about whether I've followed the technical and legal policies. No one will come to me expecting that I package a newer version. No one will ask me to fix bugs.

  If I upload my package to a ppa, a few people may care. But the expectations aren't as high. I can just vanish and let people complain on their blog how sad it is that the package isn't available for natty narwhal.

  If I become a MOTU, suddenly I have a big responsibility. Users will come to me with bug reports and complain if I don't solve them yesterday. Users will expect that I upload the new version of the package as soon as it's available upstream. I'll have to explain to nontechnical users how to figure out what they did wrong. Unlike posting on a forum, I'm not supposed to ignore the questions I don't feel like answering. And other developers might go after me because I messed up something — this can be intimidating.

  And what do I gain?

  • A fuzzy feeling that I've helped people. That can matter. But if that's my main motivation, how can packaging software compare with helping at a soup kitchen or tutoring your out-of-work-immigrant neighbor's kids?

  • A bullet point on my resume? Meh, participating in a FOSS as a programmer will be much more appreciated. (It gives you experience with things like project management and long-term maitenance that are hard to teach in college courses.) In fact, being a DD/MOTU looks suspicious to the many employers who frown on politically-involved employees (you're openly giving political support to FOSS).

  • A feeling of satisfaction? Much less than writing my own program from scratch would. Programming is a lot more creative than packaging. There's a big sense of achievement in it. There's bragging rights. But in packaging? It's a chore. It's not glamorous.

  (That's a third-person “I” above. I think the reasons I give apply to most people but to varying extents. Personally it's mainly having a squillion things I'd rather do, and packaging lacking a sense of creative achievement.)

  (Out of curiosity, does Ubuntu lack manpower?)

  maco : Yes, it does. Have you seen our bugtracker?

  Gilles : @maco: On the [MOTU page](https://wiki.ubuntu.com/MOTU), I see easily what a MOTU is and how I could become one. I don't see anything about “Uncle Ubuntu needs YOU!”. I don't think the bugtracker tells much to a casual user; for example lots of unclosed bugs could mean lots of report-and-run users who don't post enough information to reproduce the bug.

  Javier Rivera : I must totally agree with Gilles. If I had more time to devote to open source I have a couple of projects that I'd love to program.

  maco : There are a lot of bug like that, but they get closed due to inactivity eventually. There are ~2000 bugs with patches attached on Launchpad. Operation Cleansweep has been about going through and reviewing the patches and sending them upstream if good and rejecting if bad. If they're good and shouldn't wait a whole release cycle to get through upstream releases, they need to be packaged up. Though many are years old. We haven't kept up with the rate they are submitted.
  From Gilles

• What stop me to become a MOTU?

  Eventhough Ubuntu is a very nice Community (I've not been flamed for n00bie questions, yet) I think that there is few / incomplete documentation about the packaging process (even Debian's New Maintainer Guide is full of "this topic is out of the scope of this document" lines). If you take that fact and think about people who's first language is not english (like me) the process is even more difficult and caothic.

  With a simple, right to the point, documentation every thing would be easier all of us, but the people who has the technical skils to write that documentation are too busy to do it.

  From alucardni

• I posted a few ideas here: http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/

  One thing I really want to bring out is, I wonder how many developers don't use build systems that easily plug into the packaging tools. I'm doing python development. My world centers around setuptools and distribute, and yes, I can take something I build with those and export it over, but to what end? I already have something that's distributable. I wonder if the rise of scripting languages with their own build tools/distribution methods cause a lack of experience and desire in getting things put together with debian packaging tools and thus MOTU levels.

  From Rick

• For me it is probably time related. Currently I do not have a lot of time to invest. And I started of with bug triaging, but soon found out that things were a bit more complicated. And you really need to sink your teeth in it.

  Then there is bug fixing, which I know I would enjoy. What is keeping me from helping out there, is that you need to run a development branch or something. I once started to work on a papercut of mine in the System Monitor (https://bugzilla.gnome.org/show_bug.cgi?id=611738) So I started off using Ground Control, to fetch the required source and get in there an fix the bug. However, it turned out not to be so easy, because of dependencies. I know that I should only work on the development version, and test if it is fixed there. However, just to try that I needed to download the source of many other gnome packages. Which is not that easy with groundcontrol. And you probably should do that on a work machine. So I stopped there. (Again it would take me too much time, just to get started for this)

  Concernign packaging, I am just not aware of anything that needs packaging. I have once done a tutorial on packaging, and found it not too difficult for small applications. However never went out looking for a list of stuff that needs packaging, because I know there probably is one... :)

  So basically for me it is just time, I want to help out, but I just have a couple of hours (2 or something) every odd week or so. And in that small amount of time I seem to be unable to get started with this.

  maco : You don't need the source of the dependencies, just the regular debs. Why not setup a VM of the development release to work in? Then you don't have to muck with your setup (though, I've been running devel releases almost continuously since Feb 2007...more than a year before I started doing anything related to packaging / fixing Ubuntu bugs). Fixing a bug a week on 2 hours is definitely possible once you have your environment setup. As to a list of things to package: there's a needs-packaging tag on Launchpad. Packaging up existing patches is *very* useful too!
  From balachmar

• When I create a package, it's usually to scratch an itch of mine, not because someone else wants the package. Checkinstall is good enough to make a package for me, and then my itch is scratched, and I have no personal incentive to go the extra distance to package it manually, and figure out all the dependencies and stuff.

  So I guess that even if packaging for distribution is easy, it's still a lot more work beyond packaging for yourself.

  From Ryan Thompson