The KIPI fate

[Harald Sitter]

On Fri, Apr 15, 2022 at 12:22 PM Albert Astals Cid <aacid at kde.org> wrote:
>
> In December KIPI support was removed from gwenview and spectacle with this commit message
>
>
> ************
>     Drop KIPI support
>
>     KIPI offers export functionality for various external services
>
>     However it has been abandoned from its original authors and receives no real development any more
>
>     A lot, if not all of its providers are defunct and it severly lacks UI polish
>
>     Gwenview already has integration with Purpose which offers a similar (albeit theoretically reduced) functionality with a much more polished experience
> ************
>
> I disagreed loudly on IRC, because we:
>
>  * If we had to remove things that "receives no real development" we would remove more than half of KDE Gear, remember again, no new features doesn't mean that the software is not maintained.
>
>  * "A lot, if not all of its providers are defunct" that's just simply not true since upon removal i went and tested various of the providers.

I don't know the background but to me it sounds like there's
functionality overlap between kipi and purpose and to that end if one
receives development and the other is only getting kept alive as part
of Gear maintenance then I see why the argument for removal was made.
Specifically having two things cover the same use case seems a bit
silly. I mean, competing is all good and fine, but maybe not in the
same application ;) Whether or not some or even most of the providers
still work only plays a minor role there, if they work the code could
just be salvaged and moved into purpose given interest from someone.
Seeing as this has not happened I'm somewhat leaning to read it as
nobody cares enough, proofing the original point about
non-development. My 2 cents anyway.

>  * "severly lacks UI polish" *SO WHAT*

I like to think the quality of our products matter. If something looks
unpolished it reflects badly on us and the product. That in particular
also applies when we have 300 exporters but the one the user wanted to
use isn't working. One bad apple spoils the bunch, as it were.

>  * "integration with Purpose" useless unless Purpose starts supporting all the providers that KIPI used to support. Unsurprisingly, Purpose has not gained any new plugin support since December
>
> This means that for the KDE Gear 22.04 release both gwenview and spectacle will have less features for our users for no real reason, it's not even that the code removed has hard to maintain in those two applications, it was not more than 500 lines of code in isolated classes.
>
> Personally I would really like to revert those changes, but if not, I would like a wider confirmation that we have decided we don't care about our users that were potentially using those features (we have no way of knowning if 3 or 3 million) and if that's the case just archive libkipi and kipi-plugins on invent.kde.org so we can stop releasing and translating them.

After all is said and done, this close to release I would leave things
as they are TBH. If lots of users complain we can still pull a revert
in a patch release, and then expand Purpose's feature set so we can
drop kipi in 22.08. If not enough people complain, I'm +1 on archival
for 22.08. (all with my limited understanding of kipi and purpose mind
you)

Going off on a tangent:
I think you are hitting on a very important point. No matter what
happens with kipi here, we should add userfeedback support for
features that we'd like to remove and get a sense of the users the
removal impacts. Right now we have no metrics, so all we are left with
is removing stuff and see how many people complain and possibly
backpedaling after the fact. That is not ideal.

HS