This is getting to be ancient history, as this was a year and a half ago, but the first four of us were among the five core contributors on a popular java server framework in 2000, 2001, and into 2002, including the lead developer, Michael Nash. From that framework's core contributors group:
- Michael Nash
- Adam Rossi
- Shash Chatterjee
- Pete Carapetyan
We were also joined by other developers, almost the same day we started.
If you used the framework when it came out in version 4 in 2001, you got a glimpse of how fun it could be, and how powerful. You really could ( and still can) get the whole thing up in ten minutes, with a very complete feature set to boot. The important features are ones we would all need, and have been recreated many times to varying degrees by many different companies internally, and by other frameworks. This seemingly universal functionality set is listed below, and that framework has them all.
- All J2EE, all open source.
- Database Centric - to any standard RDBMS
- MVC - Mode View Controller - segregation of functionality.
- Every M and C object is secured, by a programmable security role.
- Every V is pluggable
- Standardized methodologies and objects for reuse throughout.
How could it get any better than that?
Getting the job done is a good thing. But our previous shared framework is very tightly coupled, in three different respects. So if you like it as it is, you are golden, but if you want to keep it moving, it becomes not fun very quickly
- Tightly coupled to itself as a code base
- Tightly coupled to the APIs it uses
- Tightly coupled to its ownership.
The framework we were sharing was becoming an all or nothing type of decision. Our code base had become such that a visit to SourceForge for new components might only lead to frustration. This also made it a lot harder for other guys to join in our fun, which is itself a big loss. This is particularly true for the folks we enjoy working with the most, those with a lot of experience and well developed code portfolio. By definition, the more experienced the developer, the more difficult to get involved with a tightly coupled code structure. Open source as its own poison. Argh ! There had to be a better way.
After extensive research in the initial months, we ended up starting with Avalon as our spine. This allows for future proofing and pluggability. Don't like something? Just pop in a new component to the same interface!
We also attempted to set some initial limits as far as developer metrics. Freedom seems to work best when there is some well defined structure to work within.
And perhaps most importantly, Keel is not bound to any corporate sponsor. We get our strength from our contributors. Companies that want to help are welcome to do so, and three different companies already do! But you don't get to own the framework in exchange for your contribution. This is not about high ideals or principles, it just doesn't work when any one company can choke the process of continuous improvement that makes a framework successful.
Dates:
Initial group formed Feb 5, 2002
Keel named March 4
KeelFramework.org taken out April
Michael posts intial design doc in May 2002
Site and first code both up in June
Code in use, and security designs in formation by July
Standardized build process by August
Keel wiki gets serious, security makes major moves in September
October and November saw code submittals and group efforts dramatically increase, as the code base became much more excercised and mature.
Security grew to instance based, and our own server: sonny came on line to host our wiki in December.
January 2003, our first pre-release.
