On Dec 2, 1:41 pm, Ian Wild <[email protected]> wrote: > Apologies for messing up the subject on my previous post. I forgot Google > Groups doesn't add the [list name] automatically. Shall we try again! > > ... > Hi All, > > As some of you may already be aware, earlier this year WANdisco[1] > approached members of the Trac development community with a view to working > out how we could most effectively invest development time into the project. > We plan to use Trac as a basis for a defect tracker supplied with our > uberSVN product[2]. Our goal being to develop a tool which can compete > out-of-the-box with other non-opensource defect trackers that have gained > popularity in recent years. > > The resulting discussions were interesting and culminated in the idea that > we might get the most done in the shortest time by performing a 'friendly > fork' of Trac and running that as a separate FOSS project. It was felt this > would present the least risk for everyone involved while still leaving > options open for future collaboration. Furthermore, having seen the success > that joining the Apache Software Foundation brought to Subversion, we felt > that this model could reap many benefits for the community of Trac > developers and users and wanted to explore that further. > > Since then we've been looking to bring together a team who could drive > these efforts and I'm pleased to say that in the last couple of weeks that > has finally been realised. Not only do we now have a full time lead > developer working out of our Sheffield (UK) office, with support from a > number of colleagues who will contribute significant amounts of time and > energy to this work, we are also recruiting additional freelance developers > to work on this project as independent committers*. > > We have a strong and passionate team who will do all they can to make this > a success. However we can't form an entire opensource project on our own. > Our first goal is to enable a community to come together which has > the strength and depth to take this forwards. While the Apache move is an > important part of that, no less important is support from the general Trac > community and especially the current and past committers who have done so > much to get the software to where it is today. > > I want to be clear that our intention is in no way to undermine the current > Trac project and the progress that is making. We hope there can be > mutual collaboration and a shared journey. This approach gives us both the > freedom to continue with our own strategies while allowing us all to stay > engaged with each other and to achieve what I'm sure all of us desire - To > make Trac the best defect tracker on the planet. > > At this stage I just wanted to let everyone know we're planning to publish > our proposal to the Apache Incubator later today and invite any questions > or other feedback. > > [1 ]http://www.wandisco.com > [2 ]http://www.ubersvn.com > [*]http://www.wandisco.com/careers/open-source-software-developer > > Best WIshes, > > Ian > > -- > Ian Wild > Director of Engineering > WANdisco, Inc. > > http://www.wandisco.com > > uberSVN: Apache Subversion Made > Easyhttp://www.uberSVN.com<http://www.ubersvn.com/> > > Everything you need to deploy Subversion in the > Enterprisehttp://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite> > > Subversion communityhttp://www.svnforum.org
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. First of all, Trac is BSD licensed open source software. Everyone is free to use it and reuse it as they please - do anything except blame us for any problems. Forks have happened before, and forks will no doubt happen again. In that perspective the Bloodhound proposal is a natural process. As many of you know, I have sort of rolled my own distribution of Trac too as the foundation for our hosted service. However, I've made my modifications in custom plugins - adding to, changing, or removing features via code and configuration. I've also contributed various plugins and try to be involved in all the code that I actually use; +95% of which is public. The version of Trac that I actually use is pulled straight from the Edgewall repository, and I make no patches to the Trac code. My decision all those years ago was to work with the Trac project to improve it wherever time and ability allowed. Bloodhound represents much the exact opposite of this, and it makes me uncertain. It is uncertainty that may be unfounded once the project gets going and we can see the actual plans, project activity and interactivity between the project members. Then again it may not. I won't be passing any judgement on the project for quite some time yet, and from the outset my standpoint have been that if Bloodhound can build a 'better Trac' I will not hesitate to use it. I do find it strange that a fork is necessary before any work can commence. I find it strange that none of the suggested Bloodhound team have much association with Trac or plugins - I find some scattered occurrences in mailing lists and tickets, but really not much code and patches that I can find. However, good people can naturally make magic happen regardless of what guidance history provides. I am sure they can pull their weight and hit whatever goals the Bloodhound project sets. Which brings me back to actually describing the uncertainty I feel: A full team of people going full speed ahead to achieve whatever goals they set themselves in their new-founded community. As the proposal also say, there will be a learning curve for them - learning Trac, learning Trac development, and being educated in matters ranging for compatibility, to i18n/l10n, existing plugins and various bits of history that explain the rationale for decisions made (or not made) because they were bad ideas (at least at the time). Growing that knowledge in a community takes a lot of effort. I will actually need to consider how I want to spend my own project time. One part of me say very firmly that even though Bloodhound forks the project, the decision to actually fork any code in non-compatible ways should not be taken lightly. But if I spend my time supporting the Bloodhound project and its developers via #trac IRC channel, open mailing mailing lists, and tickets; what then becomes of my available time for Trac project and plugins? I don't know. The other side of me says to just let Bloodhound carry on as they please, and focus on what matters to me now. The wait-and-see approach can leave the Trac project standing and the Bloodhound project standing, or perhaps one project succeed over time. Or, the distinct possibility that neither project survives as already thin resources are spread out across too many dimensions. Will the users bother to keep on top of both projects? Will I as Trac and plugin developer spend my time discussing what goes on at the Bloodhound project whether I like to or not? When users start reporting Bloodhound-related plugin bugs, that surely is a very distinct possibility. It is a shame that the project forks just because Apache Software Foundation affinity is a hard requirement. I've seen all kinds of discussions about forks in various projects over the years, but forking the project without expressed commitment (or interest) from any current core or plugin developer is something I can not remember seeing before - at least not without a clear sense of direction. The expected behavior would be to throw the handful of developers into the existing project, and then fork if for some reason that does not work out. All code would stay BSD, and according to proposal the project could fork at any time and no one would be worse off. I just don't understand why applying the effort outside the Apache umbrella would have any less value to the corporate sponsors of the Bloodhound project? The man-month applied on a feature branch now would be just as valuable regardless of which public repository it was applied to, would it not? The Trac code (and most plugin code) is very free open source. From my perpective there are no hard feelings about that at all. It is the nature of the work we do and the licenses we work with. But, I could still wish that the process and priorities had been different at the forking end - or at least be made public in manner that is clear for all to see. My self-appointed role in the Trac project is being "champion" for the needs of a stable, compatible, loosely-coupled system - a small core that largely lives to support the plugin community and where everyone if free to offer 'community distributions' that pick whatever parts they need. My role thrive on activity by others so there are things for me to evaluate, coordinate, guide, and adjust. It is a distinct possibility that I will be sucked backwards into the Bloodhound - primarily because 20 years of industry software project experience (yes I'm that old) have really confirmed that I cannot keep my mouth shut if I have an opinion to offer... I would however like to hear more of the opinion of other Trac and plugin developers about how you all envision supporting this fragmented project structure. Are you prepared to switch your own usage to the new project, and perhaps switch the main development of your own plugins to a Bloodhound as a new base - or at least test against it and provide the necessary compat abstraction if needed across different versions in different projects? Or, put differently; what is the level of success needed by Bloodhound before you are prepared to make the effort - or even fully switch? One of the expressed goals is to provide a "TicketSystem2" as 'the best defect tracker on the planet'. Which is fine, but for that to happen pretty much every Ticket-related plugin at Trac-Hacks.org will likely break - it will need to be fixed, integrated, or forked. Have you all considered what supporting 2 communities may involve? The intention of this email was to describe my thoughts and uncertainty. Currently I have a hard time believing that two vibrant divergent communities can survive. In the end I think there can be only one, but from 'now' until 'then' there will be much work to be done. The decision I have to make is if I should walk into the Bloodhound project facing forward, or decide to just ignore it and look after my own things. But looking after my own things would to some extent be a small dagger in the back of both projects making either less likely to succeed. I don't consider myself a great developer by any standards, but I know what I like and I know that what I do makes a difference. I positively hate the idea of providing feedback to a proposal that have so little essence. I think Bloodhound project stated goals and plans are wafer-thin from a software development standpoint. And, judging from the Apache general incubator mailing list so far in December there may be nothing more forthcoming for quite some time either seeing plans would be for the new Bloodhound developer community to decide. Whoever they may be, and whoever from us decide to get involved. Which really brings the problem full circle. I really wish the efforts were joined at the hip for now, and I'd have no reason to feel uncertain about a fork if there were months of preceding argument about project direction here at trac-dev. I would be blatantly obvious that a fork was needed, costing what it may. However, it is my firm belief that a software fork born out of critical discussion between people that disagree, will be of much better quality than a fork largely built by consensus in the offices of a corporate sponsor. People? Thoughts? :::simon http://trac-hacks.org/wiki/osimons https://www.coderesort.com -- 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.
