Jake Sorofman is a vice president at rPath, and can be contacted at firstname.lastname@example.org.
Erik Troan recently discussed the future of open source as part of a series of Ostatic presentations at the Open Source Business Conference (OSBC). In his commentary, Erik argues that the future of open source belongs to the developer community -- but with an emphasis on frameworks and pre-built components, rather than tools.
Erik suggests this will drive productivity and shift developers' orientation from features to application composition, and programming from the creation of features to the creation of the "glue code" that binds together pre-built components. I think he's quite right.
In fact, we're seeing this future play out every day as software developers face an embarrassment of riches in community-contributed languages, frameworks and components. The availability of these resources has spawned what feels like a minor renaissance for software innovation; creativity flows from Jazz-like improvisation and experimentation, which unlocks new potential for business value.
It's a good time to be a developer, which is particularly gratifying after a decade of anxiety living in the shadow of "Flat World" proclamations and the attendant fear that offshore outsourcing may devalue these once-vaunted skills.
The good news is that this hasn't happened in large measure. But what has almost certainly happened is a shift in orientation from low-level programming of ordinary features to higher-level composition of extraordinary applications. Open source is enabling this transition, which is benefiting business lines and developers alike.
But lurking around the corner is the unintended consequence of developer choice. While developers are almost certainly benefiting, IT operations is faced with a whole new world of application complexity, which is only adding cost, delay and risk to already stretched deployment and maintenance processes.
There was a time when IT could enforce a set of narrow standards that developers had to follow. This made deployment and maintenance a whole lot easier and didn't much bother developers who had fairly focused skills at the time (Java developers were Java developers). But today, developers use a broad range of frameworks, components and languages to get the job done. And because software applications have become so strategic to business lines, the directive has drifted from a rigid edict to a much more forgiving license to experiment.
This experimentation is putting pressure on the IT guy who is now forced to consume a crushing wave of variability and somehow make it work within a predefined stack. Oh, at the same time, he's seeing budgets evaporate and being told to "do more with less." Needless to say, it's not the best time to be the IT guy. Applications are becoming harder than ever to deploy and manage, in part because of the massive growth in open source frameworks, components and languages. What organizations need is a way to allow developers freedom of choice and license to innovate without making every application deployment and change cycle a race through the gauntlet. What organizations need is a way to automate packaging, deployment and maintenance cycles by producing complete, self-contained, self-describing and fully instrumented systems that are ready to run -- in any traditional, virtual or cloud-based environment.
This new model for application delivery is fast becoming the essential antidote to growth in application complexity. The reality is that the explosion of choice in today's development community is not something IT can control -- constraining developers by way of restrictive edict misses the point entirely.
The point, of course, is to allow developers the freedom of choice and to rethink application delivery models. By applying policy-based automation to application deployment and maintenance, organizations can realize what were traditionally (and practically without exception) mutually exclusive options: Unconstrained application innovation and cost-contained IT processes.