On Fri, Jun 21, 2019 at 10:38 AM Mark Phippard <markphip_at_gmail.com> wrote:
> I think the reason that both Subversion and Git were successful is that
> they both had very clear and compelling visions and goals for what they
> wanted to accomplish and then they did that.
>
> I do not think a few new features or design changes to Subversion will
> make a difference at this point .. and I am not saying that is what you are
> suggesting. I would want to be sold on some compelling new ideas for a
> product, and then probably why building those ideas on the Subversion 1.x
> code base makes sense.
>
Agreed 100%.
The purpose of this thread is to have a community-wide brainstorming
session to figure out exactly what we want from the Subversion of the
future, for that very reason.
As a cautionary tale I would look at Veracity.
> http://veracity-scm.com/compare/
>
> I struggle to find some of the original blog posts that Eric Sink made
> when they were creating this product but I know they set out to fix a lot
> of the shortcomings in Git and they did so using an Apache license. AFAIK,
> they accomplished most of their initial goals and then went on to also
> incorporate some of the ideas from Fossil in adding a distributed agile
> tracker and wiki to the product as well. Despite all of this the product
> landed with a thud and has been discontinued. Aside from wondering why it
> would not be a better code base than Subversion to start a new product from
> I come back to the compelling idea point. What are the ideas that are
> going to move the needle? Who is the target audience? The corporate world
> is probably still in play but it seems very difficult at this point to move
> the open source world away from Git.
>
I'm glad you brought that up because it's exactly what I want to
address today.
One of my goals for Subversion 2.0 is to attract new users and
developers to the project.
The obvious question is: How?
Git is the 800 pound gorilla in the version control room, so any
strategy to attract new users and developers to Subversion must deal
with Git (among other things).
Veracity SCM tried to be a better Git. One could argue that Mercurial
tried the same thing. But Git has been far more widely adopted, at
least it appears that way in public, in the open source world. We
don't know what goes on behind closed doors.
Mercurial could be perceived as a Git wanna-be. It's easier to use but
a little slower. Git blasted Mercurial out of the water because people
generally don't like imitations. People want the real deal. Given the
choice between real Git and imitation Git (even if it's not true; it's
perceived), most people will probably choose real Git.
That should give us a hint. The goal "be a better CVS" worked in 1999.
"Be a better Git" will _not_ work in 2019. So we have to go a
different way.
My suggestions for a strategy with respect to Git:
* Do not compete with Git in areas where Git is strong. Instead,
cooperate with Git in those areas.
* Compete with Git in areas where Git is weak.
Do not compete with Git: I do not suggest to turn Subversion into a
DVCS because we'll be perceived as imitation Git. Subversion is
centralized and that is NOT a weakness. I'd like to point out that in
2004, Internet access was slow and therefore "everything is local" was
a big selling point of Git. But in 2019, when broadband Internet is
cheap, when cell phone plans come with mobile hotspot, with 5G on the
horizon (and they're talking about massive amounts of data at near-
instant speeds), this is becoming much less of a concern with every
passing minute. People want to be on the same sheet of paper with each
other. People are comfortable with "the cloud." As telecommunications
get better and faster every day, Git's "everything is local" starts to
become more of a liability than an asset. GitHub exists because people
want and need a central repository. Like the saying goes, what's old
is new again.
Compete with Git: I suggest to start by amplifying the best things
about Subversion that make it different and better than Git. But
that's just incremental change. We need something more. As Mark said,
we need something compelling. So I will close for now with the
following question, which I have been asking myself: How can we
leverage Subversion's centralized structure to give something _better_
than modern workflows?
If we come up with some compelling ideas, it might be interesting to invite
> Eric to conversation to share what they learned and why what they were
> doing never worked. The one thing I can say is that while they were open
> source and tried to create a community and be open maybe there are things
> they could have done differently that would have had more impact ... such
> as trying to make it an Apache Foundation product.
>
I would like as many people as possible to be invited to the
conversation.
Received on 2019-06-24 07:38:15 CEST