Interesting post. Allow me to do some thinking out loud of my own. ;-) IMHO, in its earlier days, Commons worked well in that quite a few projects did "donate" parts of their code bases to Commons, thus seeding it and enhancing the commonality between those projects and promoting sharing beyond the ASF as well. In fact, I believe that it is actually Commons' success that has led to some of the problems that we see today, and some of the problems you blogged about.
You see, we actually did two things with Commons, one of which we explicitly set out to do, and the other that I don't think we really thought about too much, at least at that time. The former is what you describe in your blog post - "a place for Jakarta [and later, other] projects to come together". Great idea, great initial execution, and I think many projects, Jakarta and otherwise, have benefited from that. The second thing we did was to expose these common pieces of code as ASF release artifacts, and to promote them as reusable components outside of the ASF. This was a fairly natural thing to do. After all, if the code is reusable across ASF projects, then it's probably reusable across non-ASF projects as well. However, I think it's the extent to which we have gone down this path that has led to many of the problems. For example, one of the reasons people don't want to bring things to Commons any more is because they have to buy in to the entire Commons enchilada. Consistent build systems, consistent web sites, consistent release criteria, and so on. This consistency is crucial when Commons is being promoted to the "outside world", because it allows consumers to understand what they will see / get from any given component. I believe it's a big part of what has made Commons a "brand" in and of itself, and for Commons as an externally-facing project, it's definitely a Good Thing (tm). However, this is a pain in the neck for the Commons developers, and it's a significant hurdle for someone bringing code to Commons from some other ASF project. Thinking back to when Struts broke out several chunks of code (BeanUtils, Digester, etc.) and moved them to the nascent Commons, that was straightforward because each component pretty much did its own thing back then. Would we have done the same thing if we'd had to go through today's shenanigans? I don't know, but it wouldn't have been the slam dunk that it was. What's the answer? I don't know. It would be kinda antisocial to "take Commons private" and make it "internal use only", although that might be the easiest way to relax the rules and make it easier for projects to "donate" parts of their code base. With such a model, we might even eliminate releases altogether and leave the onus on the consuming projects to determine the quality of whatever tag / revision they consume. There would be pressure, in some form, to release some of the pieces, and the question then becomes one of who would be willing to go through the extra steps to create a release out of an internal shared library, especially if that was not necessary for internal consumption. No answers here, I'm afraid. Just some additional thoughts to add to the mix. -- Martin Cooper On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <[EMAIL PROTECTED]> wrote: > Apologies for writing this as a blog rather than an email - it felt > more natural and will pull in other opinions: > > > http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons > > Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
