I've been captivated by this list traffic the last few days. It's fascinating data, and useful for my day job where I advise companies about how open source works. This issue is pushing open source ideas into areas where no one has a lot of experience and where there aren't any well defined rules.
Now's my time to jump in. As someone who's followed Ant since the early days, here's what I see on the past, present, and future of this issue (yes, I did read "A Christmas Carol" over the weekend). James originally created the Ant tool within Sun as a way to build Tomcat. He needed a cross platform build mechanism for the server he was creating, and he recognized that Make sucks. All of us knew this, but unlike most of us who created hacky Makefiles, he invented something innovative: Ant. He named it Ant because it was a little thing that built big things. :-) Ant was his baby more than Tomcat really, and while he fought to open Tomcat he also had an eye to open Ant along with it. Ant in the open was justifiably recognized as a cool build tool, and we all scrambled to use it and some of us to improve upon it. I personally have dropped Make for good! :-) Around this time James got drawn away on other things (finishing the Servlet API spec, cleaning up the XML JAXP spec) and couldn't help much with Ant. So the community here built up around the tool and *rightly* feel like it's partly theirs now. (You can see the conflict coming, can't you...) James takes a new job within Sun that allows him to dedicate some real time to Ant. He wants to jump back into his old position as "vision thought leader". However, the community that has grown around Ant doesn't recognize him as such, because in the time since they joined he hasn't been very active. So they want him to prove his worth again with the advice "start contributing, help with patches, start advising more on ant-user and try to be more constructive with your criticism." He feels like George Washington returned from afar welcomed to the nation he helped found with not a "wecome back" but rather a "prove your patriotism again". And of course, that hurts. (Yep, there's the conflict...) The good news is that progress is being again on debating the technical merits of each proposal. That's what we're all best at. :-) But there's one open issue. What do we do with the name "Ant"? The "Rules for Revolutionaries" (created by James ironically) doesn't address this issue. The thought was that there would be consensus on a path to take and that the name would follow that path. Here's a situation where we have what may be fundamental disagreements about design, and there may have to be *named releases* before we get any consensus, if we ever do. What I think has concerned James is that he wants some guarantee that if he believes his approach is technically superior to the competition, he's OK with the competition but doesn't want to lose the name "Ant" to what he would consider a "fork" from his original vision. In Apache, afterall, a name is very important. The Apache name can only be used by derivative works with the express permission of the ASF. If someone else thinks they can do better, the code is theirs *but not the name*. This situation with internal forks is hard because who gets to have the fork with the original name? I think in the situation where such a decision needs to be made it should be decided by the overseeing PMC. Name choosing is one of the standard duties of a PMC (although usually only selecting initial names!). Furthermore, I would hope that (as with child custody) they try to leave the name with the original creator wherever possible. If not, it's a strong disincentive to host a project with Apache: You could create a project and have its "brand" taken by a fork you disagree with. Apache is about collaboration, and we share our code internally as well as externally. But we preserve the name as our brand. If someone outside Apache forked Ant, they'd have to choose another name. The question now is do we offer the same protection within Apache? -jh-
