There’s a few  workflows for dealing with this. My preferred one is to track the appearance of my patches in Stephen Rothwell’s linux-next tree, which tracks individual development trees destined for merge into Linus’ tree. I create a git branch based on the current state of this tree then apply the patches I’m submitting on top of that. This lets me spot any potential merge conflicts that they’ll create but the main function is to allow me to come back to the branch later and track which of the patches has shown up in one of the trees that Stephen tracks. To do this I rebase the branch onto the current state of linux-next:

git rebase --onto next/master old-master

where ‘old-master’ is the last linux-next commit in the branch. This will flag up any merge issues that have come up due to changes in other trees and will also handle patches that are already present in one of the trees in -next by dropping my local version. The end result is a branch based on the new linux-next with all the patches that were not yet applied in it. I can see what still needs to be looked at by examining the log

git shortlog next/master..

and take any appropriate action, such as following up with the relevant maintainer or trying to find out what’s going on with the subsytem if it looks like the subsystem maintainers are inactive.

One possible problem with this approach is that a patch may be applied and then subsequently dropped – this is rare but it can happen. I deal with that by also keeping a normal unrebased development branch whch has the changes in Linus’ tree merged  into it periodically and incremental patches for any review updates that occur during the submission process. By looking at the diff between that and other trees I can see any changes that have got lost along the way.

One of the biggest surprises that people starting to use Linux seem to run into is that you can’t rely on any particular support level from the community – everything is done on a voluntary basis and the responses will depend on a range of factors, including things like how busy the people involved are. People moving to Linux for reasons other than freedom, particularly those using it commercially, often don’t seem to notice this distinction.

You can normally help getting a response by providing as much information as possible about your problem and the steps you have taken to resolve it – this makes it very much easier for people to reply since, for example, it’s more likely that something will jump out at them.

These web pages contain some suggestions on the sorts of thing to do in your e-mail to help get the best response:

How to ask questions the smart way
How to report bugs effectively (this is targeted at end users more than developers).

With the kernel community it can also help to send direct copies of your mail to people who have worked on the relevant code since people may either miss postings on mailing lists (there is often a lot of traffic) or in some cases not be subscribed to the lists at all. This doesn’t apply to all free software projects – you should check the normal standards for a given project before doing this.

If you need guaranteed responses or more detailed responses than you are able to obtain from the community the usual approach is to work with people with whom you have a commercial relationship – for example, your chip or software vendors, or consultants you have employed.

Of course, I’ve never been to a Linux conference that required a particularly substantial payment to attend – indeed, one of the most substantial parts of the Debconf budget is sponsored travel for attendees. Requiring such fees for a Linux conference would be a warning sign regarding the sort of audience that the conference was likely to attract. In contrast, Ruby conferences (like Scotland on Rails, which is even closer to me than Debconf was) typically charge only commercial rates. Were I paying commercial rates for a conference I imagine that I too would be demanding well rehearsed talks and a general professionalism from the conference. Equally well, I’d be surprised to see anything quite so excellent as the night venue at Debconf 7 at a more professional conference.

It’s not that Linux is a hobbyist thing – just look at the companies running server farms on the enterprise distributions and paying good money for support, or at the people relying on Linux for embedded applications – or that there is a big wall between the more commercial people and the rest of the community. Often it’s commercial use cases that stress things and drive interesting new work and you’ll often see people doing commercial work asking for help in the same places as end users. It’s not that Rails is particularly hostile to non-commercial people – the openess of the community is comprable to that of other free software projects and the help given to developers by the community feels very much like that you’ll see in the Linux community. The only thing is that the emphasis is very different. As far as I can tell this is mostly due to the applications that the two cover – such a large proportion of substantial applications for Rails are in commercial environments, almost exclusively with closed applications, that it will naturally attract a higher proportion of people who think in exclusively commercial, buisness terms.

It’ll be interesting to see how the Rails community handles this as it grows. The Linux community has, by virtue of being very open technically and focusing strongly on the technical side of things, managed to handle this very well over a very long time period. It’s a big part of what it such a fun place to work. Rails is much newer but I’ve heard a few people remarking on the fact that the success of Rails means that simply being aware of and using Rails is no longer quite such a good indicator of clue as it was when there was no commercial track record to attract people. It’ll be interesting to see how the community adapts to the presence of people motivated more by their CV than by the technology itself.