There’s just way too to do! Wind River is hiring - if you’re interested in kernel development, userspace work, tools, real-time Linux (RTLinux/Real-Time Core or PREEMPT_RT), BSP development, all around one hell of a nice platform, email matt.sherer@gmail.com. Please!
There’s a lot of work available in the field of computer science. A lot. Even after the shakeouts from the big bust, outsourcing, broader interest in the field, etc., there’s just a huge amount of work. Not all of it’s really that interesting from a technical angle, although it all pays the bills pretty easily.
Perspectives vary of course, but finding an interesting subdomain in CS is straightforward. If you’re doing something new, that’s usually interesting. (Meaning something really new, not just new to you, although that’s a good substitute.) Old technology applied to a new field can be interesting too. Work which may be a bit behind the curve but with a more meaningful application (say, infrastructure for the Peace Corps) gets bonus points.
I’m not saying other fields here aren’t interesting and/or fun. With the right mindset, the most constrained maintenance job can be a hell of a mindbender, and really hard/interesting to keep things going.
There are some ‘classical’ areas of applied CS that are generally interesting, too, and that’s what I’m mainly thinking of. Think of your undergrad classes - Algorithms, Discrete Math, Operating Systems, Compilers, that kind of thing. There’s a lot of interesting work there, although not many people get to work on it anymore. Sure, you can go to school and focus on it, but not everyone can maintain that publication rate up forever. Instead, students leave academia and head out to do the applied work.
The real world is the other side of the fence. Now there’s pressure to pay the bills, and rightfully so. Paying the bills means that the work that gets done has to be valuable enough to justify the checks. That’s the beginning of the end for most of those fundamentally interesting fields. Who’s going to pay your company your salary plus overhead to develop a compiler these days? How about new algorithms? Maybe if you’re at Google or a new startup (and thus satisfying the qualifications listed above), you’ll get to do some algorithm research, but probably not for the bulk of those ‘Enterprise Java’ type apps. How about OS development? Right. It’s hard to tell if Microsoft does that anymore. If it’s not Windows, it’s Linux or OS X, and really, with their size, it’s hard to contribute meaningfully.
The trouble is, OS technology is largely (not completely) a solved problem. Between the two major players today, there’s just so much momentum that it’s unlikely that anything meaningful will ever seriously overtake them and gain a majority. There’s just not enough value (read: cash) in the ecosystem to justify another investment of that magnitude. Don’t get me wrong - there will always be a number of other OSs - security focus, footprint, high availability, stability and certifiability will always require much more than what just the main players can provide. (Disclaimer - I work for Wind River, and really, VxWorks has some serious applications where there’s no real contender.)
Many of the current niche systems will over time bleed into Linux and CE as those OSs shrink and hardware grows. I don’t expect Symbian to be around in 10 years time except in support mode. I’ve gotten off on a tangent here - to get back to my point, if you want to do OS development, it’s going to have to be in academia, and even then, most of the work will probably have to be written off. It’s going to be really damned hard to bring a new OS to the field. The best that can be hoped for is that an idea can be grafted into an existing system, most likely Linux.
Now we’re back to the problem - if you want to do something new in, say, operating systems, it’s likely going to have to be in academia. Very few companies are going to let you play around all day trying to write a new OS from scratch. You’d be lucky if you could get enough paid time to write a few little hooks that could come up out of a bootloader and control a system, and in the end, that’s what it would be - a controls system, not an OS. Once your boss looks over your shoulder and sees that you’re trying to ‘genericize’ your current control app into a full operating system ‘for reuse on the next project’, he/she’s should be yanking that out of your hands and handing back an OS.
Rob Pike has a similar view, although more pessimistic, here. I doubt the last 7 years of development in the field has changed his mind much.
I will offer up a bit of hope, though - since 2001, I’ve been working on RTLinux (also known as Real-Time Linux, RTLinux/Free, RTLinuxPro, RTCore/BSD, and Real-Time Core), and really, this completely invalidates what I’ve written above. I wasn’t in academia (even though the idea started there), although I did do new and interesting operating system development that was applicable and above all commercially viable.
How? Well, a number of magic factors, notably, being in the right place at the right time. It helped that the idea could be done in an area with an absurdly low cost of living. (Those familiar with Socorro, NM, know what I mean.) We also didn’t develop a new OS from scratch - POSIX provided the framework. (I firmly believe that the POSIX spec ended OS interface development; aside from a few blemishes, it’s a very fluid and comprehensive system view.) We also made use of Linux and BSD (Net and Free, not Open) - we just did the real-time OS, just what we could bite off and chew. There was no way we could have written the real-time system plus a driver for every little SATA interface that came on the market. There just isn’t enough value there, especially when it’s free in Linux.
That’s what makes the RTCore idea work so well - it adds value and lets us concentrate on the applicable aspects of real-time programming and in doing so provide value, while leveraging the right balance of Linux expertise to round out the system. At FSMLabs the focus was on the real-time side and the Linux/BSD was a bonus, but now at Wind, there’s focus on both sides, and we have the benefit of a large group helping move Linux forward both inside and outside the company. There’s actual real OS work being done in a way that creates value without any of us having to figure out how to keep taking graduate seminar for another 30 years.
And why is OS development interesting in the first place? Lots of reasons - interesting call contexts and scenarios, exposure to hardware, etc. But it can all be summed up with one single call - schedule(). Where else can you write code in which code calls a function, does some work, and returns, but returns to some other context as someone else?
It’s such a simple concept, but it strikes me as really interesting. Other OS interfaces have neat implications too, like the chain of events that can be triggered off by a simple write() call. But schedule() sums it up better - not only do you trigger all kinds of interesting activity, you actually call a function and come back, but you’ve become someone else in the process.
Maybe I’m just strange.