On Sun, Dec 25, 2011 at 9:37 PM, Ethan Jucovy <ethan.juc...@gmail.com>wrote:
Did these discussions with the Trac core developers happen on record? I > don't see any previous discussions about this on trac-dev or any of the > other obvious forums. > Although there was nothing inherently private about the discussions, they were predominantly held by email and a number of conference calls. At that time we were in a discovery mode and there were other commercial entities engaged in the same discussions. It wouldn't be appropriate for me to republish those threads verbatim, but I don't think there was anything controversial or that won't be / hasn't been repeated here. Frankly the very act of importing a copy of the Trac core codebase, > relicensing it and rebranding it, and actively seeking out a community of > contributors to that project -- including from the existing pool of Trac > plugin developers -- seems unavoidably undermining, given the scarce > resources of time and attention. > I understand the argument, but I don't believe thats what will happen. I can imagine that Apache Bloodhound might result in new life for some plugins, or even the contribution of new ones, but I just don't believe the efforts will be conflicting or negative to the Trac base. If the Apache incubator succeeds in growing a strong new community for Apache Bloodhound it will almost certainly serve to strengthen the Trac code and plugins too. It's too early to talk about specifics, but there are plenty of precedents with positive outcomes from similar situations. > It seems like the ideal scenario would be for an organization like the ASF > to provide the infrastructural and legal assurances for the Trac core as > the Trac core, and for a commercial organization like WANdisco to build its > products on top of that. I understand that this isn't very far off from > what's happening here, and I can certainly see how expedience might favor > the solution you've arrived at. But the particular details that diverge > from that ideal (starting from a fork of the core code; apparently > rebranding a combination of that core fork + a configuration of it; and the > licensing issues) seem quite important. > This was our original suggestion. Somewhat understandably, because we hadn't been involved with Trac development previously, the view was 'you are free to do what you wish, but we will wait and see'. Trac as a project has longevity, users, reputation and plenty to keep it doing what it's doing. The good thing about this approach is that the proposal doesn't impact the course the existing Trac leadership is steering but the options remain open in terms of future developments. > I appreciate your intention to work on these questions with the Trac > community going forward. But this could easily devolve into a > chicken-and-egg problem where the expedient solution ends up remaining in > place and we end up with two codebases, two brands, two licenses, two > communities and two "core design philosophies" for good. > Completely agree - it would be helpful to discuss this further. If we end up in a place where there's a conflict between the communities then something went wrong. Would there be interest in an open telephone conference in the new year to discuss these things in more detail? Maybe it's just me, but with so much to talk about, I find email a rather difficult medium to work with. Best Wishes, Ian -- Ian Wild Director of Engineering WANdisco, Inc. -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
