Hello Anatoly,
While I can understand your concerns, hostility will bring us nowhere,
so please try to keep an open mind ;-)
On 12/28/2011 10:25 AM, anatoly techtonik wrote:
There is an opinion that WANdisco tries to gain market share by
pretending they are the major driving force behind the open source
communities that support projects like Subversion and Trac.
They indeed are one of the major contributors for Subversion (sponsoring
Greg and employing Hyrum, AFAIK).
But in case
of Trac the marketing efforts can be wasted, because IIUC none of
WANdisco employers have a trail of commits to Trac core. So, the best
way to build up a "reputation" is to place WANdisco members name on the
official page of Apache Software Foundation with Trac and Apache logos
and a new project name announcement. And then include this new project
name in all marketing materials.
The strategy that hurts an ecosystem.
Nothing prevents WANdisco from contributing back to Trac, but they
didn't and probably don't want to, so I believe the true motives are
somewhat different from the goals of community.
Well, they made their true motive clear enough, no need to search for an
hidden agenda. They want to try to build a JIRA competitor and selected
Trac as the starting point, then hope that having one or two full time
paid developers plus an emerging Apache-based community will do the
rest. There's of course no guarantee that this strategy will work (and
during the first "private" rounds of discussion I think I did my best to
draw their attention to the various risks this implied), but they
nevertheless want to try it out, so let's just hope we can get a
positive outcome from this initiative. I imagine that at the very least
those full-time developers will manage to produce some interesting
changes that we, hobbyist developers, could learn from ;-) And then
maybe not, we'll see.
Somebody said that there is no time to review changes from Wd members.
This problem can be solved without Apache projects and all that buzz.
First, Wd can stash the changes much like everyone else does and just
remove them from their own branch when the changes are merged. It's just
a matter of coding culture and maturity of company processes to be able
to do so.
Remember that they're Subversion proponents, so the fork/merge mentality
of DVCs is not exactly part of their culture [1], which I find curious
because it's just a natural extension to the "don't be afraid of
conflicts" motto inherited from CVS [2] (but I digress...)
Second, it could speed up the review process by compensating
time of Trac core developers without buying and restricting them to be a
flag bearers of Wd. There is a legal entity - Edgewall Software, that's
year after year supported this project (unlike Wd), so nobody would
really object if you could try to cooperate with them first instead of
jumping into your own public project and calling for everyone to move.
This didn't work out for various reasons, and no matter how you look at
it, it's hard to imagine that any kind of sponsorship / compensation
would go without influencing the technical decisions we could make (e.g.
what if we were wanting to put svn and git at the same support level as
optional components under tracopt?).
-- Christian
[1] http://blogs.wandisco.com/2008/07/17/what-a-git/
[2]
http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge
--
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.
