Channels ▼
RSS

Open Source

OpEd: The Future of Open Source


Jake Sorofman is a vice president at rPath, and can be contacted at jsorofman@rpath.com.


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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video