The KIPI fate

[Harald Sitter]

On Sun, Apr 17, 2022 at 12:46 PM Albert Astals Cid <aacid at kde.org> wrote:
>
> El divendres, 15 d’abril de 2022, a les 13:42:43 (CEST), Harald Sitter va escriure:
> > On Fri, Apr 15, 2022 at 12:22 PM Albert Astals Cid <aacid at kde.org> wrote:
> > >  * "severly lacks UI polish" *SO WHAT*
> >
> > I like to think the quality of our products matter.
>
> Of course quality matters, and one very important part of quality is "can this software do what i need it to do?"
>
> > 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.
>
> What about the exporter you have been using for decades being removed just because another totally unrelated exporter didn't work?
>
> Software removing features that work and you use without any replacement given would be really a deal-breaker for me.

We can probably agree that removing features is never very cool. At
the same time I would argue that there must be space for this. If we
had a myspace exporter and nobody was willing to port it to purpose
for the 3 remaining myspace users, then that's just something the
myspace users have to deal with (obvious strawman example - I don't
know what exporters kipi had that purpose does not :)). Realistically
there ought to be a cut off point where a feature is not interesting
for us because it has too few users, having both kipi and purpose just
to not lose the myspace exporter seems impractical cause you'd either
force someone to port code for 3 users or to hold on to complexity
that is only there for 3 users. A bad deal one way or the other.

KWin had some effect or other removed a while ago because nobody
maintained it - it's since been redone because people cared enough
IIRC. That is why I think exploring ways to garner metrics before
removals would be super handy.

HS