It's a given on this blog that open source is changing the world of computing. But what about the IT skills required to flourish in that world? Here's a thought-provoking blog post by Ian Smith, from the open source company Nuxeo, on what has changed since he first learned to program:
This is the beginning of my argument that the java + open source + linux world is quite different than the one I grew up in. I was certainly aware that the projects I was doing in school were small--toys even. I was also aware that in the "big, bad, real world" there were these huge, often legacy, business systems that folks had to work on. It was certainly the case that I heard faculty members say, "Well, in the real world things will be more complex, but for the purposes of this course..."
I am coming to the conclusion that, now, the roles are almost reversed. If you are working on old, legacy systems you probably aren't working with open-source tech, and maybe not even java (or its modern brethren). In my opinion, if you are in this state, you are hosed. You are also hosed because you are constantly unable to catch up to what is going on in the open source world and, worse, are forced to write code that you know already exists and you could just get off the shelf. In other words, your system(s) are probably actually smaller than what people are doing in the "open" world.
He helpfully concludes with
three things (none of which were even discussed in 1988!) that I would advise students to be good at if they want to work on big open-source systems when they graduate:
1) Know what information streams to get and understand how to interpret different kinds of input about software (e.g. beta from google vs beta from IBM vs beta from some kid in Finland--- freshmeat vs. jboss.org). If you don't know what code is out there, you can't very well use it and your organization can't profit from it. Related to this, ability to do quick-n-dirty searching for things that might be out there, especially in the case where it stands to reason that somebody "must have done this before."
2) Knowledge of enough *different* kinds of programming models and systems to know if A and B have can be combined without too much pain. Is one event driven and the other not? What about multi-threading? Does B use maven for dependency management and A use Ivy? Does system A have a bunch of baggage that makes it too heavy to drag along? (There are a host of related things about how to combine two things to get a useful third thing, but I like this as a proxy.)
3) Ability to communicate with other people via the internet to discover (dig up) critical bits of information that you need (quickly). This can be the ability to write a good test case, a maven pom with questions in the comments, or a good forum post in the right forum to get the attention of the lead developer.
I'm no programmer, but they sound right to me. In a sense, what we are talking about here is the development of a new kinds of higher-level abilities: not just how to code, but the ability to find, modify, combine and share reusable bits of code, to draw from and feed back into the great free software commons.