Hi,
> Sometime during the upcoming month I am supposed to pitch Trac to > high-management for organizational-deployment > (so far it's only "proof-of-concept" with participation of teams and > projects that were interested). Great! > For instance- > "Trac is being actively developed for X years, > by a dedicated community of N core-developers (average N over project life, current N) Uh oh, this would be a false positive ;) - trac is currently being developed by only two core developers, and O.Simons is rather short of allowing others to join in in the effort, except for providing patches via the standard channels such as the ticket system, which is IMO counter productive as it dispels many capable developers in the first place; which is basically due to the fact that they never can identify themselves with the project. This might also be a reason for why overall commit to the core project is rather low, and why there are still so many long standing open issues, IMHO. However, rblank and cboos lately increased their output by increasing the rate by which releases will be output to the public. In addition they made available public GIT and HG repositories for everyone to participate in further developing the software. This, however, requires acquiring additional developers participating in the effort and assigning them as core developers. Yet, still, the core architecture and overall complexity of the system still keeps developers away from the software, especially more so in that capable developers must first prove themselves by providing 100+ patches before getting "core developer" status. And, lastly, trac competes with many solutions out there, keeping it low means more market share/revenue to those who provide the other solutions. Overall translation effort of the intrinsic texts was lately increased, which is double plus good. SCNR So emphasizing on that fact would raise a warning sign in my opinion. However, trac was and is being included with all the major Linux distributions, and, yes, it was actively maintained by the two guys for years. Better rely on the fact that trac is component based and highly extensible and also features a rather easily maintained code base (sort of once you get a grip to its overall complexity), and that it is being used by a wide range of organizations, for example even the source forge team used to use the trac wiki for both documenting purposes and keeping trac(k) of issues etc. last time I checked their site (>1yr). > and several M's (tens? hundreds?) of contributors and plugin-developers. See trac-hacks.org, but you need to seed out the maintained projects from the unmaintained first, leaving you with only a handful of actively maintained projects. > Trac is not likely to disappear because a, b & c. It surely will not, ask O.Simons and others on IRC, as they are likely to use it in productive, commercial to non-commercial environments. Dunno about 'em two core developers, and if they actually use trac for every day work... would be nice fact to know, though. > In addition to the open-source aspect of Trac, > do you know of companies that offer "commercial support" for Trac? (does > the Trac license allow such things?) Trac's license is AFAIK an MIT based license, sort of. So it actually supports commercial use of the software. And I am sure that there is someone who actually makes money out of it by providing services based on trac. > (e.g., a company that I can go to and have them solve issues or implement > enhancements / plugins according to my requirements) You are free to do that. However, it would still be nice to have feedback and patches for bugs/issues fixed along the way of implementing your own extensions/enhancements. -- Carsten -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@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.
