Nuxeo's Ian Smith has a great post about what it takes to be successful in open source software. The general premise is that most of the "analysis", "algorithms" and "design" skills that one learns in computer science programs are less relevant now that you can assemble applications out of various components. To be a good open source developer, Ian writes, one has to excel at interpreting information about software, understanding what components are likely to work nicely together, communicating, and knowing the landscape of different open source sources. Ian has a great picture showing the dependencies of 100's of components and makes the point that selecting and managing these disparate technologies is a real challenge for a modern software vendor.
The argument reminds me of a theme that I have been hearing since I entered the industry: how much technical understanding of the underlying technology is required to be an effective user of that technology. When I started, purists were skeptical of computer science degrees. They wanted hard core electrical engineers that understood computer design and function at the most primitive levels. Later, computer science degrees were considered a requirement. Of course, with my undergraduate education in English Literature and Economics and my graduate work in Environmental Management, I kept pretty quiet on the subject. My current feeling is that, to be effective, you always need to more than what was included in the formal education of your curriculum. Ian probably takes for granted all of the "'analysis,' 'algorithms,' and 'design'" skills that he learned in school as he struggled up the learning curve of his job as an open source developer. Someone without Ian's computer science training (like me) would have to pay his dues getting a computer science degree equivalency on the job. As a technologist that assembles components, you do need to dip into the code and understand how things work. Sometimes the glue that holds things together requires some well conceived engineering too.
The big idea in this post is not about the training of the individual but about how companies compete. When the parts are freely available, the competitive advantage hinges on what components and frameworks to use and how to manage the un-synchronized life-cycles of all that software. Configuration and release management becomes immensely complicated with all those moving parts and the companies that can manage that complexity will have a clear advantage. As companies shift their emphasis from developing to assembling, this challenge will become a more visible issue in the industry.
 My journey from those disciplines to my current career is a long story.