27

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.

9
  • 7
    Please make MOTU a link to wiki.ubuntu.com/MOTU for people who don't know what it is (like me) Aug 22, 2010 at 17:00
  • 1
    I agree that a link would be helpful. However, given that this question is about why people are not part of some particular thing it would be better to actually explain the jargon in the question.
    – moberley
    Aug 22, 2010 at 17:10
  • @moberley: MOTUs are developers who can upload packages into the universe (and multiverse) section of the Ubuntu archives.
    – txwikinger
    Aug 22, 2010 at 19:22
  • Forgetting to renew my ubuntu-dev and ubuntu-coredev membership and not havint the time to go through the process again is the reason why I'm not a MOTU/coredev anymore ;-)
    – raphink
    Aug 24, 2010 at 19:48
  • 1
    Converted to Community Wiki due to style of question. Aug 26, 2010 at 3:35

11 Answers 11

14

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.

12

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.

1
  • 2
    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?
    – maco
    Aug 23, 2010 at 14:09
12

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.

5
  • 3
    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).
    – maco
    Aug 23, 2010 at 14:07
  • @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. Aug 26, 2010 at 7:02
  • 1
    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.
    – maco
    Aug 26, 2010 at 23:41
  • 1
    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. Aug 28, 2010 at 11:44
  • 1
    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.
    – maco
    Oct 11, 2010 at 23:04
9

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.

1
  • 2
    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.
    – Owais Lone
    Aug 25, 2010 at 7:43
8

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?)

4
  • 1
    Yes, it does. Have you seen our bugtracker?
    – maco
    Aug 24, 2010 at 23:48
  • @maco: On the MOTU page, 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. Aug 25, 2010 at 7:37
  • 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. Aug 25, 2010 at 9:19
  • 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.
    – maco
    Aug 25, 2010 at 9:21
4

Language, my main problem is that I'm still not confident enough with English, being so, I can't understand easily what other developers are trying to tell me

3

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.

3

I think there are several reasons for this. I also think 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.

5
  • 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.
    – maco
    Aug 22, 2010 at 19:49
  • It is still a difference when a sponsor tells someone to apply, or this person is nominated by a sponsor.
    – txwikinger
    Aug 22, 2010 at 19:58
  • Uh? Sponsors don't nominate people, Sponsors advocate self-nominations by the sponsoree.
    – lfaraone
    Aug 22, 2010 at 21:26
  • 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.
    – maco
    Aug 22, 2010 at 22:16
  • 2
    @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.
    – txwikinger
    Aug 23, 2010 at 0:40
2

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.

2

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)

Concerning 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.

1
  • 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!
    – maco
    Aug 25, 2010 at 15:43
1

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.

Not the answer you're looking for? Browse other questions tagged .