|
From: Patrick O. <pat...@gm...> - 2011-01-03 21:44:01
|
On Mo, 2011-01-03 at 16:05 -0500, Chris Frey wrote:
> On Mon, Jan 03, 2011 at 02:32:52PM +0100, Patrick Ohly wrote:
> > Of course I am thinking of SyncEvolution here. It already works very
> > well for SyncML. I also have support for additional protocols, which I
> > will be able to publish soon. I think it would be worthwhile successor
> > of OpenSync, but obviously I'll need help to cover all the use cases
> > that you were shooting for with OpenSync.
>
> My personal opinion is that the steps of your proposal are just slightly
> backwards. I think that before we declare anything dead, that the
> replacement should first be just as much alive.
Is OpenSync 0.4x alive today or vaporware? Is it recommended for
production use?
Is OpenSync 0.22 alive and supported? I know that it works for some
users and clearly SyncEvolution is no alternative to those users unless
it implements the same features.
> So I'm also interested in the answers to Graham Cobb's questions.
That deserves a more in-depth reply. I'll do that tomorrow.
> The project that is most useful and supports all useful features is
> the one that deserves to keep going. But in the meantime, I don't
> believe there is any harm in having both. It's the Linux way. :-)
The harm is that in the end, we end up with no project that really has
the desired features.
> In other words, if you want the support of the OpenSync developers
> (such as it is), implement OpenSync's features in SyncEvolution
Here's the catch: without support from additional developers, some
things will never get implemented because there are areas that I myself
cannot or do not want to support (for example, devices that I don't
have). GPE is one example. Akonadi another. I already wrote a prototype
backend for Akonadi, but now need a developer who is motivated to finish
and maintain it.
If everything already works and is implemented, why should I still want
the support of the OpenSync developers? Clearly your skills would be
wasted when focusing exclusively on maintenance.
> (and maybe even change the name, since it sounds overly linked to
> Evolution syncing)
I considered a name change, but rejected the idea because SyncEvolution
already had a good page ranking and was well-known under that name at
the time. I'm still reluctant to change it - too much uses the name
(domain, command line tool). But if a name change is considered crucial
despite the new interpretation of it ("the missing link"), then we can
discuss it.
> and you'll win automatically. You won't need
> proposals. You'll have the features, and therefore the users *and*
> the developers.
So far I have plenty of users, but only one additional developer (Ove
Kaaven, for the N900 port). I can only speculate about the reasons, but
I guess one of them is that OpenSync is still seen as the future for
syncing on Linux. I hesitate to describe it with such a slightly
disparaging comparison, but it is a bit like a honeypot that attracts
new developers who then get stuck without ever getting nearer to a
stable release of their work.
--
Bye, Patrick Ohly
--
Pat...@gm...
http://www.estamos.de/
|