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