[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Looking to hire Software Engineers to Help Develop Subversion

From: David Richards <david_at_wandisco.com>
Date: Tue, 21 Dec 2010 12:32:16 -0800


Absolutely correct!

Your analysis / explanation is much better than my own. Thank you.

- David

On Tue, Dec 21, 2010 at 12:25 PM, David Weintraub <qazwart_at_gmail.com> wrote:

> On Tue, Dec 21, 2010 at 3:03 PM, Pablo Beltran <pablo_at_svnflash.com> wrote:
> > Hi,
> >
> > I have no doubt about those all features will be good for the future of
> > Subversion, from a technical point of view.
> >
> > On the other hand, the underlaying message scares me. The message is
> clear:
> > Apache can't drive the development process by itself and only Wandisco
> can
> > do it in the right way and in timing.
> >
> > And I think that this exceeds Subversion project and undermines Apache's
> > authority.
> >
> > Today is Wandisco and Subversion. Tomorrow could be Oracle or Microsoft
> > doing the same with other project. I would not like see Apache become in
> a
> > silly Software Factory.
> >
> > But of course, I have not enough knowledge about how Apache internally
> works
> > and perhaps I'm saying a very great stupidness. So, my apologizes for
> that
> > if that is the case.
> >
> I am going to look at this a bit differently: Has IBM taken over
> Linux? A majority of the changes in Linux are done by IBM paid
> employees. IBM has its own goals and its own ideas about what they
> want to do with Linux.
> However, I believe most people feel that Linux isn't an IBM project
> despite the massive amount of work done by a single company.
> Basically, IBM benefits from Linux, so they do a lot of code work,
> sometimes working on areas that have been previously neglected. The
> better Linux is, the more IBM can sell Linux solutions.
> Subversion has had a lot of problems since version 1.5 has come out.
> Basically, the merge/branch tracking isn't that great. In fact, many
> people prefer the 1.4 version which doesn't make any pretensions about
> tracking branching and merging.
> Meanwhile, many people feel Subversion is past its prime. Many open
> source projects are moving from Subversion to Git. Actually, this
> makes sense for open source projects, but it is beginning to affect
> commercial applications. People are starting to push Git as a
> commercial SCM package.
> I recently pointed out on another list that I might recommend a piece
> of software I don't think is as good as another piece of software
> simply because the "inferior" product plays better with the other
> software the company uses and because users are more familiar with it.
> I might not like Git as a commercial version control system, but if
> most developers are more familiar with Git than Subversion, and 3rd
> party products start integrating with Git in better ways than they
> integrate with Subversion, guess what I'm going to start to recommend.
> So far, Subversion isn't being forked, and a fork would not be good
> for WANdisco. They are heavily dependent upon people selecting
> Subverson as a version control system. What they want to do is fix
> some of the underlying issues Subversion has had for the last three
> years and get the Subversion project to accept them. I can't see any
> reason why the Subversion project would reject them. After all,
> Subversion was once run by CollabNet which had commercial interests in
> Subversion. Yet, no one complained about CollabNet "dominating" the
> project.
> I hope that WANdisco is able to fix many of the issues that have been
> plaguing Subversion for years. I don't believe that those who are
> leading Subversion have "failed", but that a private company
> committing resources to an open source project can be a good thing.
> --
> David Weintraub
> qazwart_at_gmail.com
Received on 2010-12-21 21:33:14 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.