Re: Subversion's community health

I agree to all you wrote. But the increased speed of releasing new
versions with unstable experimental features somehow contradicts the
otherwise mature development state. As a user of the JavaHL API we only
consider a feature as stable if it is reflected in all binding APIs, too.

-- 
Best regards,
Thomas Singer
=============
syntevo GmbH
https://www.syntevo.com
https://www.syntevo.com/blog
On 2019-06-14 16:34, Eric S. Raymond wrote:
> Julian Foad <julianfoad_at_apache.org>:
>> Anyone with constructive suggestions, please do share them. Please let us
>> not dwell on our sadness and criticism of what went before; let us try to
>> keep this thread focused on positive solutions for what to do next.
> 
> You guys know me.  I'm a past contributor, occasional critic, often a
> supporter. I did my best to push back when Linus Torvalds accused this
> crew of incompetence.  And I, too, have had the recent experience of
> watching a project I was hugely invested in - GPSD - slide into a
> semi-active maintainence mode.
> 
> The main piece of advice I have for all of you is that you should
> keep your expectations about Subversion's future realistic.
> 
> The brute fact is that git has taken over the version-control world.
> It has stomped flat a couple of sttempts to compete with it in DVCS -
> Mercurial, bzr, monotone. And Subversion is at a massive disdavantage
> relative to *any* DVCS for reasons that should be too obvious to
> need repeating.
> 
> Does Subversion have a future at all?  I think the answer is "Yes",
> but it's not an exciting, sexy future.  You guys have only two selling
> points I can see for new installations (1) Subversion's UI is
> *massively* simpler than git's, and (2) some customers have
> political/cultural reasons to prefer a centralized VCS with
> repositories that can't be easily cloned.
> 
> I think that's enough for survival.  But it's not exciting, not sexy,
> and not a recipe for drawing in new development talent.  Thus, if you try
> to plan for big things, you will almost certainly fail because you won't
> be able to collect the investment of developmen time required to
> realize them.
> 
> What you *can* hope for is to ship occasional releases of high quality
> and maintain Subversion's deserved reputation as the best of the pre-DVCS
> version-control systems.
> 
> This is what I mean by setting realistic expectations.  It means gearing
> down - accepting that your release tempo is going to be low and your
> main goal is to keep the issue tracker relatively clean.
> 
> This is where I am now with GPSD.  I had to struggle a bit to accept it,
> but the truth is GPSD is mature software that doesn't have much of
> anything left to do in its application domain.  In an important way,
> that is victory.
> 
> I'll pitch in here myself; I have plans to collect some more information
> about the semantics of the dump format and add it to the documentation
> already in the source tree.  Because I believe in finishing what I
> started and leaving behind artifacts that say "Damn, that guy was a
> pro."
> 
> You can still have that kind of excellence.  It's not a trivial thing.
>