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.
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.