There were some great comments to my previous blog entry, Pay bounties in time, not money, including this one:
I would love to pay in time and not in money. But I don't have any programming skills whatsoever. I'm an office manager by trade. I'm skilled in interactions between people and (basically) herding cats... and I'm good at it, if I can say so myself :)
How can I use this experience to help Inkscape or Ubuntu? I don't really know if I can.
For Inkscape, I've already written up an answer in depth in Inkscape's FAQ entry: Are there non-coding ways to help? There has been a huge number of non-coder Inkscapers who have gotten involved with the project in these ways and helped to make it a roaring success. So for that half of the question let me just point there, and focus on the Ubuntu side of things.
A lot of people don't realize they CAN contribute. A widespread assumption is that software is technically hard and that you need advanced coding skills to do anything to contribute. It simply isn't true. And in fact if people think that way, it holds FOSS back from its true potential. Have a look-see at the above Inkscape link to see the big breadth of non-coding things that an average piece of software needs done to make it succeed: Tutorials, clipart, teaching other users, mocking up dialog changes, translating, testing, marketing, and (especially!) helping with the bug queue. Working on any of these (especially bugs!) can have the add-on effect of freeing up those who DO have coding skills to focus them on coding instead of all the other non-technical tasks that need to be done in order to make the software successful.
Let me focus specifically on management ("cat herding") since that was the question, and try to slant it towards Ubuntu.
I suspect one of the things developers enjoy about working on open source is that they don't have a boss! I'd bet that hardly any FOSS project would say they "need a manager". However, there is more to "management" than "being a boss", and indeed I think these aspects are among the highest areas of need with most open source projects.
For these reasons, let's also distinguish between "project owner" management where you are the primary lead of the project, and "contributor" management where you're a regular team member, and narrow our focus to the latter.
With Open Source management, I like to think it involves three kinds of work beyond regular development: a) Cheerleading, b) Taking out the trash, and c) Operating the switchboard.
"Cheerleading" is essentially just encouraging good behavior and motivating and inspiring people to do more work. If you've ever worked in a demoralized environment you can know how big of a productivity difference it can make when people are happy vs. not. With volunteer projects - as most FOSS projects are - morale is HUGELY important, and unfortunately there are a LOT of demoralized open source communities out there. Getting morale back is very hard, but imagine what a difference it makes for FOSS overall to take a dispirited, nearly defunct community, turn things around, and get developers excited again about pushing their software project forward.
With Ubuntu, this could involve simply cheering folks on at e.g. bug hug days, issuing thank-you's to people who fix bugs you care about, etc. or to identifying ineffective communities around particular areas of Ubuntu you think could be better, and stimulate them to be better organized and better focused towards progress.
"Taking out the trash" is the idea of handling the chores that other people don't wish to do, yet that have begun blocking up the project. This could be helping get the indefinitely-delayed release finally out the door, cleaning up an out-of-control bug tracking system, organizing a marketing effort, researching into the background of a serious blocker bug, fixing the website, or resolving some differences of opinion that have split the project. In other words, find the things that EVERYONE complains about, but no one actually does, and to devote yourself to doing THAT. Often, once you demonstrate leadership charging right into the problem, others will follow your example and assist - sometimes even taking care of the technical hard parts you are apprehensive about doing yourself!
In Ubuntu, certainly the biggest "chore" right now is the mass of bug reports in the bug tracker. Organizing testing activities is another area where contributions could make a huge difference.
"Operating the switchboard" is probably one of the most rewarding (and unrecognized) management contributions you can make in FOSS. Everyone knows that lots of issues end up just being failures of communication. So if you turn this around, you realize that many problems can be solved just by stimulating the right channels of discussion. Thus, without really needing to deeply understand a technical issue, you can solve problems just by finding the right two people, and linking them together. For example, this might be by linking a well motivated but inexperienced coder banging their head on a bug, with an experienced coder who can give advice; or it could be putting an upstream developer in touch with an engineer at a hardware manufacturing company with the data sheets about the HW you care about; or it could be getting developers of two different applications together to discuss issues like a consistent protocol format. You know when you've made the right introduction, because you see the two instantly go off into technical depths way over your head. Be sure to check back in a day or two to see how the discussions went, so you can help see that follow up actions get taken, or results communicated to third parties appropriately.
For Ubuntu, there are probably infinite areas where locating the right upstream person and hooking them to the right MOTU or core-dev person can advance a bug a LONG way.
Definitely agreed regarding helping with bug work. I think there's also a lot of value that can be attained from forwarding bugs upstream - basically once a bug is verified as a legit issue, and has sufficient info, it really should be brought to the attention of the relevant upstream project.