This blog post expresses my personal opinion. Currently I’m not an active KWin developer, thus I think I have an outside view. I’m not contributing due to personal reasons, mostly lack of time. I would love to start contributing again, but in the current pandemic situation I won’t find the time for it. Given that I’m just an armchair developer with some background view of KWin.
As the former maintainer of KWin I’m rather shocked to read that a fellow KWin developer announced a fork. Personally I find this very disappointing and very sad. In my opinion a fork should be the last option if any other option failed. There are very few legitimate reasons and I think a fork always harms both projects due to the split of development efforts and the bad publicity such a fork creates. The announcement renders KWin in a light it doesn’t deserve. There are of course successful forks such as X.org and LibreOffice.org, but those forks were created due to serious issues with the project and had most of the developers on board. I do not see any reason in the current KWin development! For the same reason I also do not like the lowlatency fork. Of course it is an important area where KWin needs improvements, but I would love to see that happen in the KWin repository and not in an outside repository. Working together, bringing the experience together is much better than working on your own.
Personally I am very happy how KWin evolved since I stepped down as the main developer and maintainer. I was afraid that my loss in activity could not be compensated and I am very, very happy to see that development activity in KWin is much higher than it was most of the years before. Looking at the mailing list I see new names and old ones. KWin looks very healthy to me from a developer perspective.
Having read the announcement and the reasoning for the fork, I was left puzzled. What went wrong? When I looked at the mailing lists I never noticed any conflicts. In fact there is even strong agreement on the areas which need work. Such as a reworked compositor pipeline, the KWayland situation, etc. Of course we need to be careful when rewriting, reworking central parts of KWin. One of the main areas in the work for preparing KWin for Wayland was to move the code base in ways allowing to rewrite parts without risking the stability of the whole project. Personally I think this served KWin well. And even if the KWin team does not want a quick rewrite of central parts it’s no reason for a fork. This still can be handled upstream, through branches. One could even release an “experimental” KWin release with central parts reworked. Overall I just don’t get it and hope that what matters is a good KWin.
Also I must say that if I wanted to write a new Wayland compositor I would not fork KWin. KWin started as an X11 window manager and those roots will always be there. In our decision on how to handle the transition to Wayland this was a central aspect as we still have to provide an X11 window manager for those who cannot and do not want to switch. Thus we needed to evolve KWin instead of starting something new. But for a Wayland first compositor I would not start with KWin.
This blog post has comments disabled as I won’t have the time to moderate or answer.