It's my opinion that most of the software patents that I've seen fail the obviousness test for someone who is qualified to be an expert witness. Most of the software patents that bother me are things like one-click or hyperlinks. There may have been a point in time where some part of their functionality was patentable, but generally they are obvious extensions of prior art. You see this frequently in hardware as well.

The development methodology as mentioned by the OP doesn't change the presence or absence of the vision and insight that something that is patentable should require. Its important not to confuse the what with the how when considering this. It is a pity that for the most part software patents were awarded by people who didn't know the industry well enough to know which of the ideas they were seeing were obvious extensions of prior art. More importantly, the practice of patenting demonstrated but undefended prior art has hurt us all by requiring patents for things that should have been in the public domain in the first place. I sometimes wonder what would have happened if it had been possible to patent movable type or a method of translating human understantable instructions into commands to control the operation of machinery.

As a further red herring I should mention that the use of patents in general doesn't work well against most entities that you would most want to be defended from. A large number of players are using the slowness of the legal response to make their money and then vanish. It works against large corporations and other entities that are stuck at a fixed address which is why they tend to try to gather as much IP as possible related to their business in self defense.

This is an old argument going back at least a century. One line statements of position certainly don't adequately express an appreciation of the complexity of the issues.

I've been part of the IT team in small buisnesses a couple of times now. I prefer doing development, but during some of the lean times one does what one can. The first problem is the nature of the job. IT is just never going to be pure 9 to 5 work. There's too many things that have to happen when there aren't a large number (as in any) of the users using the systems. You can do maintenance during the day, but if you do you probably deserve some abuse, depending on how badly you wreck everyone's day. I've seen good and bad with this... bad is keeping half of the company from doing their jobs. Most small businesses can't afford that.

A lot of the folks that get hired to do IT for small to medium sized buisnesses aren't quite up to the job either. I've seen all sorts of technical mistakes made. The bit about backups is a key. People reuse tape (ok I'm old) or other media past the safety limit (which is a hell of a lot smaller than most people think it is) and then they also implement storage solutions that are almost impossible to manage or back up. They don't test backups, and they don't implement best practices because they don't have time. And because they don't do these things they never will have time to do anything other than react to the current crisis. Working for a small company is a lot harder than a big shop, one guy has to know a lot of fairly specialized things. Bringing a guy from a big shop down usually isn't possible, as no one can afford them. Even worse, the things that you do for large shops are often just not the right way to manage a small business. It's stupid to plan for a network that can fit into a 200000 person organization when it's not going to have more than 100 users. Virtualization isn't a good idea when you end up running everything on one machine, and you don't have any spare hardware to take up the load when that one goes belly up. (been there saw that... didn't implement it - argued about it, wish I'd been wrong!)

In all fairness there's a lot of pressure from the other side as well. Small business owners want the same kind of functionality that large companies have, and don't want to pay for it. I've seen eager IT guys running demos to prove they can do things, and then have the people who control their pay tell them to implement it with no budget. There's a skill to presenting the bill that most training doesn't cover. Even if it did, you can lose a job because someone brought in an illegal copy of something and made it look like you don't have the skills. I've also seen that small businesses can't afford the training to keep their people current. So they hire replacements when they change technology. The replacements usually can't handle the legacy stuff and the situation continues going from bad to worse.

And then there's managing the users. A lot of upper level managers don't understand how damaging it is when one department starts implementing crap that doesn't fit in the enterprize. But the users are often reacting to either perceived, or in many cases actual, neglect from the IT staff. If there's a real need out there and it isn't being met, you can expect anyone who's worth being hired to try to find a solution. The fact that it's a bad solution in the long term doesn't make the reaction wrong. I've implemented some of those rogue systems myself when I couldn't get an IT group to respond when I offered them funding to get the people and hardware they needed to do the job. That one probably cost someone I liked his job, but I still needed to solve the problem I'd been given. But there's also the lusers who can't seem to resist clicking on the destroy the system now attachement. Hell we had one CFO who wouldn't pay to have the AV suite license renewed... or the SSL certs. But it was the IT guy's fault when the company shut down for three days. In my opinion it was too, I was his backup and got the cash released by telling the owner what was going to happen if they did it again. But the other guy needed his job more than I needed mine - and was fired because he didn't do the hard thing.

Like I said, the problem's fairly complex. I don't think simple statements about it actually help much. It'd be interesting to see what a book that detailed how to make it all happen correctly in the real world. Something like Yourdon's _Death_March_ but for SMB IT folks. It's certainly more than can be put in a post here.

There are some pretty compelling reasons to migrate, but looking at your specific application most of my favorite reasons don't apply. Since you're going to be changing your toolchain somewhat, the 2.6 migration isn't going to be that much more invasive. My reasons for wanting to change have mainly to do with filesystem improvements and USB improvements, which don't seem to have much traction for you. I'm assuming that you did your own hardware drivers for the PCI express data collection, so that shouldn't be a particularly big deal, except for having to redo for new hardware, which you have to do anyway.

So, like I said, I'd migrate but if you need to continue work with the old device for some reason I could see an argument for a continued freeze. The biggest downside to this is the larger jump you end up doing in another few years when you need to migrate for real functional reasons to some later kernel. It's always seemed easiest to me to embrace the opportunity to migrate if it makes reasonable sense.