Why Enterprise needs unified build platform?

Sooner or later every single company that builds their own software comes to implementing some kind of generalized build & deploy system. While meeting the need, such a system does not add any competitive advantage to the core business. It is like if each company will start creating their own programming languages: it could be made highly optimized for a particular busines, but maintaining one sucks in more money that it generates. And don't forget the people around it: how much expertize is preserved when developers rotate or simply resign? What kind of support does such a system gets?

 This paragraph may evolve into a huge discussion, but in my opinion - creating and maintaining commodity software only makes sense if it is the primary business of an institution, in all other cases (we are discussing commercial enterprises) obtaining commodity software is preferable and saves a lot of money. Especially clear this becomes when the primary business changes: grows, modifies requirements.

This may sound trivial, but a community can achieve more that any single entity. And if 10 entities manage to invest 1 unit of work into a community project, the return is 10-fold right away. Provided that the direction of development is agreed upon by all 10 (smile)

I think it' the right time to get together and discuss all that. The upcoming ApacheCon in Austin, TX Oct 9-13 2006 seems to be reasonably good opportunity to do that.

What is different for Maven in the Enterprise 

In my understanding Maven for Enterprise has a set of unique characteristics. Most of these characteristics are common sense options for almost all projects, but in the enterprise environment they sease being options and become requirements.

As a build platform, Maven is expected to deliver:

Versioning support
A very interesting challenge is version maintance: if I have a thousand developers working on 500 projects - keeping versions in sync is a hustle. Some of it may be addressed by the release plugin, but that one is very limited in terms of project structure support. I think we are coming to a more fundmental requirement here: dependency graph manipulation tool, which supports:

Licensing support 

In the enterprise it is very important to know and quickly access the license of any project. Licence may have a version, it may be just another, specially designated dependency that resolves into either a predefined set of known licenses or a new URI for the license?

A clean separation "internal project" vs. "external dependency" might be desirable. We can do it by, say, groupId. Is there a need in more granular project attributes?

Enterprise Development cycle
Maybe we should define a reference "enterprise software development cycle" and brainstorm how well Maven supports various aspects of it? Normally we always stopped at unit tests, completly ignoring QA/regression testing, saying: OK - it may happen behind the seen and then - by miracle - project is released; version may or may not change. Well - this is not going to fly if you try to sell it to a big company's software development management; first question will be: how does it support my real cycle?

Here is an attempt to define coarse cycle phases we can refine and generalize:

I fully realize that this is an over simplified description, but we need to start with something and grow the meat.