On Sun, Dec 25, 2011 at 3:45 PM, Ian Wild <ian.w...@wandisco.com> wrote:
> The Trac ethos is a fine one, which can be equated to an advanced assembly > kit that people must put together in just the way they want before they can > effectively use it. There are companies that offer pre-configured versions > of Trac and professional services around it, but there is nothing that an > average tools manager or evaluator can quickly test, use and deploy as part > of an accessible open source package. That's not all there is to the Apache > Bloodhound proposal, but it's important to highlight that there is a > difference in approach and goal there. I personally don't believe either > approach is wrong, just different. > +1. I think this is an excellent goal, and I think Trac is an excellent base upon which to build it. > The benefits that an open source foundation can bring to any project are > well documented. As well as gaining an existing development and tools > eco-system, the strong governance and very important legal protections that > the Apache Software Foundation provide are not matched by the current Trac > setup. As a business investing heavily in an open source project we are > duty bound to ensure certain things about our investment. The impression we > got from the existing 'core' of the Trac group was that they wouldn't be in > a position to put those things in place and it was they who suggested that > the best way forwards was a friendly fork. > 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. So now WANdisco is gathering a strong team who will work on this as part of > a wider Apache based community. It isn't anyone's intention to detract from > ongoing Trac development in anyway and I don't believe Apache Bloodhound > will. As part of Apache there will be a community who would hope to take > the best things from Trac, and I'm sure work to address the other points > like Trac-hacks and the plugin eco-system among others. In no circumstances > will we want to do that in a way which would undermines Trac though and I'd > hope that all of these areas can be discussed and agreed upon as they are > being approached. > 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. 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. 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. To prevent that, I hope that we can quickly develop a clear picture of what roadblocks stand in the way of the ideal solution, and that there can be a clear and ongoing conversation about how we all might reach that end goal as the project develops. As a Trac user, plugin author, and sometimes-evangelist, seeing an effort to develop that particular roadmap up front -- on both the technical and nontechnical (e.g. legal and governance) sides -- would alleviate a lot of my fears about this effort and make me much more inclined to get involved. -- 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.
