Seasons greetings to all, I'm very pleased to see a discussion starting on this. I was hoping for an ongoing open dialogue and co-operation between the Trac and Apache Bloodhound efforts and would encourage as many people as possible to get involved in this dialogue. I'm concerned that anyone here regards Apache Bloodhound as a threat to Trac. Whether this ultimately develops as a 'friendly fork', derivative or something else, managed properly both approaches can succeed and give to each other without jeopardising the viability of either.
There may be questions that it is too early to answer, however I can address a few of the previous points now. WANdisco spent the last year investigating how we could most effectively participate and make a large investment in the development of an open source defect tracker to equal equivalent commercially available tools. In many software categories there are open source tools that take on and often hands down beat commercial options, but that's not true for any open source defect tracker today. Our view was that Trac represents the best vehicle to achieve that and working within the existing infrastructure was discussed at some length. 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. 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. 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. It's still early days and there is a lot of work to do. Within Apache the discussion will be open and available to anyone who wants to get involved. I don't think anyone should feel under pressure to do that, but you're more than welcome. I'd also be happy to facilitate ongoing discussions, maybe even calls and video conferences between us all to ensure that we aren't conflicting and ultimately that we're providing the best possible software for users. Best Wishes, Ian -- Ian Wild Director of Engineering WANdisco, Inc. http://www.wandisco.com uberSVN: Apache Subversion Made Easy http://www.uberSVN.com Everything you need to deploy Subversion in the Enterprise http://www.wandisco.com/subversion Subversion community http://www.svnforum.org On Sun, Dec 25, 2011 at 4:30 PM, Rob Guttman <[email protected]> wrote: > > +1 to this latest thread. This is my third company using Trac and I've contributed a number of plugins over the years: http://trac-hacks.org/wiki/robguttman > Ethan's point about configurability is exactly why I prefer Trac over others. I don't know enough about Bloodhound to comment on specifics. In general, I like the idea of people wanting to contribute more to the Trac community. But if the effort is likely to spread limited resources even thinner, that concerns me. I would rather see more support for Trac as we know it such as bringing trac-hacks.org up-to-date (possibly at a new home if necessary) and making it as supportive for collaboration as github (e.g., through new plugins). That's what I think the community really needs from this humble plugin developer's perspective. > - Rob > PS: Happy holidays! > On Dec 25, 2011, at 10:55 AM, Ethan Jucovy wrote: > > Thank you, Simon and Steffan -- +1 to everything you have both said. I am a deeply committed Trac user (since 2006), occasional plugin author and casual observer of the core codebase and development process and I share your concerns about the Bloodhound effort. In my experience Trac's design and architecture make plugin development very easy, and I am not sure what value there is in a pre-emptive fork that does not first attempt to work within the existing core architecture and community processes. > Of course I understand that a corporate effort will generally need to commit upfront to getting its own goals accomplished as a higher priority than working with upstream constraints. But to reframe that reasonable internal prioritization as an open source fork under the Apache name seems detrimental to everybody, as Simon and Steffan have said. > Again repeating what others have said .. the Trac community could certainly use more and better integrator-level documentation, configurations and "known good sets" of curated plugins, explicitly managed outside the Trac core development process. But there is no reason per se why this should not happen at a symbiotic layer sitting on top of the Trac core -- not a pre-emptive fork. > To answer Simon's question, I plan to monitor Bloodhound development, but I do not expect to switch to using it or developing against it. The Trac code and community have consistently impressed me as a good, reliable, streamlined base that I can configure to do pretty much whatever I need. The very action of announcing an intent to fork, rather than working in and atop Trac's well-designed and long-established component architecture system and plugin community, makes me think that the Bloodhound project is likely to bake in a more opinionated, less robust and less configurable core. > > On Sun, Dec 25, 2011 at 10:32 AM, Steffen Hoffmann <[email protected]> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 25.12.2011 04:14, schrieb osimons: >> > Hi Trac & (future) Bloodhound communities. >> > >> > I have previously shared my thoughts in bits & pieces in various >> > communication with interested parties, but for the sake of openness >> > and clarity for all I figured a public summary would be in order. >> > >> > ... >> > >> > People? Thoughts? >> >> Thanks for asking. >> >> My roughly 3 years of slow progress towards becoming a member of the >> Trac community won't let me speak as authoritative as you, Simon. And I >> didn't follow Apache general incubator mailing list at all. Anyway, I've >> read all announcements about the upcoming Bloodhound fork here very >> carefully and I confess that I'm sharing a lot of the uneasy feelings >> with you. >> >> I learned that Trac has a really small developer base these days. So >> small, that it hurts me at several occasions, because noble ideas simple >> can't be approached for the lack of time and maybe other resources too. >> OTOH, two new developers have been invited and joined the core team this >> year. And while obviously not involved with many fancy new features, as >> often as I looked into recent commit history I've seen all of them doing >> rather ambitious work behind the scenes. Better API documentation, >> continued db backend re-factoring, progress towards more i18n support >> for wiki content and many small fixes and enhancements come to my mind >> instantly. >> >> Certainty, there are a bunch of alternative wikis, repository browsers >> and bug trackers out there. In my eyes Trac is still unique for it's >> consequent "reduce-to-the-max" core design and rather rigid policy of >> using plugins for may tasks, that are considered part of core elsewhere, >> and renown for it's plugin support too. >> >> When facing the growing Trac functionality and the current amount of >> plugins at trac-hacks.org and elsewhere, the call for better overview, >> easier plugin selection (get best plugin for given task) and convenient >> feature-enriched packages for better 1st-time user experience is only >> consequent. As a Debian user I'd solve this by better support for >> distributors. Btw, I already established contact to the Debian Python >> apps packaging team myself, this has been very welcome, but I had no >> time to contribute there by now. >> >> I fear that my English isn't good enough to point out critical issues >> with the Bloodhound proposal. I'm with Osimons for the most of his >> gentle rambling against the massive effort for just the fork, and that >> the true shape of the new project seem still very blurred and unclear. >> >> There is a saying: 'You know me by my actions, not by my words'. Among >> other things it had been announced by Wandisco representatives, that >> current (trac-hacks) developers and plugin maintainers would be >> contacted to speak about possible ways of collaboration. While I felt >> like this would qualify me at least for AccountManagerPlugin and >> TagsPlugin, I've heard nothing by now. >> >> Not that I'd need that special attention. I don't complain at all. In >> fact I would be a bit lost for words in the current situation. What >> should I expect? What will be expected from the other side? I could >> never compete to professionals doing it full-time as their daily >> business. As a non-professional in the software development business I >> can only dedicate a small part of my private life to work on Trac and >> plugins, mostly late evenings, after children went to bed. >> >> Inside the Trac community this has never been a problem so far. Even >> with initially very few coding experience I've found patient listeners >> and professional advice on my requests here at the mailing list as well >> as at #trac IRC channel. When I had a serious Trac problem and was in >> doubt, if I could approach that or better give up, Simons hints and >> encouraging words confirmed me to stay and try. Just one occasion that >> I'll never forget. >> >> I'm thankful indeed and eager to give something back. My current plugin >> maintainer status and loose affiliation with Trac core will continue, at >> least until it is clear that Bloodhound will become the new Trac. But >> this won't happen easily. Most announcements suggest effort that could >> and maybe better should be done inside Trac and trac-hacks for more >> livid development, and better packaging support by/with existing >> operation system distributors on the other side. >> >> If you don't see my point here, just one more thought: Today >> professional, key-turn application roll-outs are often virtual machines >> in cluster setups. How could we encourage wider Trac adoption more >> economic and sustainable within tight resource constraints, if not by >> working closely with OS vendors? I don't see, that anyone here goes into >> building images for VMware, VirtualBox, Xen & Co. >> >> I heartily welcome new developers joining here. Familiarize with the >> Trac ecosystem, become a part of it. You'll be respected and encouraged >> to take responsibility according to quantity and quality of >> contributions as I witnessed several times by now. Having sponsors to >> donate paid developer time could even yield a leap-frog progress at some >> issues. >> >> OTOH a diversion won't be good for any of the involved parties. Trac >> (plugin) developer base could be finally drained below the critical mass >> to do both, maintain existing solutions and produce remarkable, valuable >> new stuff. Just for getting the fame of Trac and respect of the >> community for this project into the Apache domain? I hope this isn't the >> hidden meaning of the Bloodhound proposal, and most probably it won't >> work out in the end anyway. >> >> Would love to hear more people to speak-up here too. >> >> Steffen Hoffmann >> (hasienda) >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk73Qf8ACgkQ31DJeiZFuHeIrwCgpGNNzIz32ctnG3hze5kHvjlL >> j2cAoOTeV1A2w+0P72M0D7vGg+qUqRcg >> =HhL5 >> -----END PGP SIGNATURE----- >> >> -- >> You received this message because you are subscribed to the Google Groups "Trac Development" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to [email protected]. >> For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en. >> > > > -- > You received this message because you are subscribed to the Google Groups "Trac Development" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]. > For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en. > > -- > You received this message because you are subscribed to the Google Groups "Trac Development" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]. > For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en. -- -- Ian Wild Director of Engineering WANdisco, Inc. Cell : +44 (0)7961193722 Office DDI: +44 (0)114 3030472 US: +1 925 3801734 http://www.wandisco.com uberSVN: Apache Subversion Made Easy http://www.uberSVN.com <http://www.ubersvn.com/> Everything you need to deploy Subversion in the Enterprise http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite> Subversion community http://www.svnforum.org -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
