Yeah for something that simple, was all that really necessary?

By the way, how do you like iBatis?

And the true irony is that each of these frameworks claims to make us more efficient. In the development community we are frequently guilty of adding increasing numbers of layers of abstraction to protect us from future change, to increase maintainability (!!), to improve robustness...

And what's worse we do this at the expense of our very existence - stop reading now if you have a sensitive stomach - developers only exist to solve business problems. That's right, your clients won't judge you by the number of cool patterns you've used or by how many open source frameworks you've managed to conquer. As developers, we have to constantly remind ourselves of the end goal and not be blinded by the technology candy that tempts us (myself included).

Interesting post :) Alot of people must recognize that voice u mention, at least I do. I know the solution you came up with in the end allows for better maintainable software. On the other hand, your solution requires a lot of knowledge about a lot of different technologies / tools. I think maybe 5-10% of the .Net developers in the world is able to fully understand your solution. In that perspective how maintainable is your solution by those 90% developers who have no clue why you used such a  (in their eyes unnecessarily) complex solution?

I guess developers should just be somehow forced to learn this stuff.

I'm really afraid for the future of the ALT.NET movement, or Open Source in general because of the fragmentation and a horrible case of 'Not Invented Here' syndrome. MS is bad, but OSS developers are 100x worse.

The people who do these projects are highly motivated, highly intelligent, highly interested people who also usually happen to be highly opinionated and intently focused which leads to a lot of reinvention.

We almost need a conference like MiX every year or other year to get all these people in a room and get them to settle on a singular configuration mechanism, a singular this, that or the other thing.

The hardest part about using any of these frameworks (Spring, NHibernate, StructureMap -- any of 'em) is that they're all so wildly different.

Some can justify their difference based on true innovation, but there needs to be some introspection/cool-off time where someone stands back and evaluates the situation and merges some of these innovations together to prevent the fragmentation we have today.

clarification: I didn't mean to say that Spring should merge with NHibernate, for example. I meant that the X project and Y project (and all ALT.NET projects) should compare notes and look to see what the other has done for, say, configuration or dynamic proxy type generation, or etc, etc, etc and try to unify these things and produce a common 'solution set'.

"Hey, are you an OSS developer starting a new project? Please strongly consider using the ALT.NET common configuration system!"

And we, as a community, should give a little pressure to the projects to move in this direction.

It benefits the developers, also, because they're not spinning wheels reinventing everything, every time and having to maintain it, etc, etc.

Jeremy:

You made good points.

I wasn't referring, necessarily, to entire projects. I think that it's cool that we have iBatis and Hibernate, Sprint.NET and StructureMap, etc. These things need to exist.

I was referring to the more mundane aspects of each project. I'm willing to guess that the Configuration requirements of all four of those projects are almost identical. Sure, they have different items that need configured, but the MECHANISM by which they are configured (XML, fluent API, etc) could, essentially, be the same.

On your point #3, there's absolutely still room for innovation. If someone comes up with a new whiz-bang configuration mechanism, projects can start migrating to it or even adopt it without having to issue a new build, etc.

It seems that we, as a community, should introspect, at least a little, and come to a consensus on some of the more basic aspects of all these projects. I know I keep harping on Configuration (because it's the thing that the users most often interact with), but there are other things -- like the basic data access (I don't mean NHibernate/iBatis, I mean how to work with ADO, etc).

Does there really need to be 27 different ways to read an XML configuration file? Command-line parameters (sheesh! How many times have we all written cmd-line parameter parsers!!?)? to do ADO.NET/JDBC interaction?  

I'm willing to bet that when you started StructureMap and Storyteller, you spent more-time-than-you-should-have worrying about how to configure it, how to take cmd-line parameters, etc, etc, etc.  That's a shame. That's time that you could've spent making StructureMap/StoryTeller better. It just seems wasteful to me that our best community contributors are worrying about these things. People like you should be worrying about solving the bigger problems.

Maybe that's where someone like me should come in. I'm not a front-line major problem solver like you guys. Maybe people like me (and most of the people that read your blog, I'm willing to guess) should be working on these types of Support projects to enable people like you to be working on the Important Stuff(tm)?