Open Source

Open source and open standards can equal profit

By having truly open standards and code that have been developed in full partnership with industry and domain experts, programmers can get the best of the Agile movement and still turn a profit.

Open standards and open source are good concepts, particularly when they lay the groundwork for individual companies and programmers to base their work on. These "open" concepts get a bad reputation when people use them as a personal bully pulpit against a business rival. I believe that truly open standards and code can lead to the best of the Agile world and be good for the company's bottom line.

Agile development

Programmers have to be pretty fluent in the problem domain in order to write the necessary code. Instead, we throw a million layers on top of this and call it process, and pretend that we are making progress. We are fooling ourselves; we are compensating for the fact that our developers are either incapable of communicating with customers or are unable or unwilling to understand the problem domain.

One thing that I like about the Agile movement is the idea of getting the developer talking to the end users (i.e., the true customer) instead of a project sponsor. The Project Management Professional (PMP) crowd hates the Agile folks because Agile renders those PMP certified project managers and the squadrons of business analysts useless. It cuts them right out of the loop, throws out much of their process, and seems to dump Gantt charts. Many of the people who profit from the standard project management systems (like project sponsors) get the boot too. Sadly, Agile and the like require very special programmers, very special customers, and an extraordinary contract to make it work.

These layers of process are not really progress, but in most cases, they are unavoidable. Most projects under typical business conditions in the usual environments will run better with them than without them. It is a lot like language and architectural decisions -- a few rock stars might be able to blast out some insanely awesome system in three months using Lisp, but it will typically take a dozen average programmers 18 months to trudge through it in Java, VB.NET, or C#.

I am not proposing that we come up with a magic system that allows domain experts to do the coding themselves -- these systems have been tried, and they have all failed. By the time programmers understand and model enough of the domain to write this kind of system, it would be much easier and quicker to just write what those experts need to be written -- unless you combine open standards and open source software.

Combine Agile with the open concept

Open source and open standards leverage and multiplex the time and energy of a collection of individuals in a way that would otherwise not make sense. Without the back-and-forth of multiple contributors, open standards and open source mean "giving away things for free" or "allowing others to profit at your own expense." When many people contribute to that pot, it is like stone soup -- the sum becomes a lot more than the whole and everyone benefits.

With open standards and open source that is contributed to by various organizations and individuals, there is the chance for the programmers to get hooked up directly to the domain experts in a useful way. This can only happen if it is more than just developers participating in the process. Also, these true industry consortiums do not seem to be terribly "open" much of the time. They might publish a standard that everyone can follow if they want, but it requires a pricey membership fee to have input in the process; it also costs a lot of dough to get "certified." This is not open -- it's actually quite exclusionary.

By having truly open standards and code that have been developed in full partnership with industry and domain experts, we can get the best of the Agile world (i.e., code developed with the immediate, zero-gap input from the experts) and allow it to be shared with developers who are not in the rare special circumstances that are conducive to Agile techniques. This is a tall order, but it is the best way that I can see for things to keep moving forward. Plus, companies usually can't afford to tackle a lot of domain areas, yet the cost sharing associated with commonly designed, open standards and code make it possible to turn a profit.



Justin James is the Lead Architect for Conigent.


I don't know the allegory of Stone Soup. I know what a "Straw Man" is. And I know what "A Horse Designed By A Comittee" is.


Requires that a collective effort is made by the community to produce a product. The concept is that if I begin with a pot of water and a stone and everyone in the community brings a vegetable or meat, the resulting soup would feed all who contributed and then some.


The resulting stew would have onions and celery in it -- and I don't like either. Don't mind me. I'm just being silly.


In my last job, my supervisor would almost be a wall between the rest of the organisation and myself at the time. I felt like I lost a lot of my communication skills in the process, just went rusty. In my current place, there's a project that's been going for a couple of years. The users have been putting up road blocks because they see using any program as 'doing IT stuff' and that's beneith them. So the poor programmer could not get any clear specs. The place had to hire a project manager to run the thing! (But then, that's Belfast for you.)

Editor's Picks