On change management and display servers

There’s been a post, titled Why the display server doesn’t matter. It received a few responses:

Aaron and Martin are not saying anything that hasn’t been said before. What I find interesting is how the communication is happening. Martin is a well known developer and has spent a lot of effort on porting KDE to Wayland. Aaron communicates a lot :P Now I know various developers will hate “change management” courses and the theory, but one thing that is stressed during such courses is to acknowledge and understand what people affected by a change are saying.

Looking into the responses given by “Canonical” (in quotes because I’m not sure if every response was from a Canonical person) towards the various feedback given regarding the change (Mir as additional display server), one common theme is highlighted by the various responses: “it doesn’t matter”, “it is just a bug in the application”, “it is just a bug in the toolkit”, “the toolkit abstracted wrongly”, etc. Sometimes these answers are conflicting. Saying partly that the toolkit abstracts it, while also saying that currently the toolkit is lacking should indicate that there is a problem (at least in the communication).

Despite the pain caused by this change, there is no acknowledgement. Just a repeat of “it doesn’t matter”. As a result, the very people you need to make this change happen will feel ignored and being dismissed. You need these people, yet they’re being dismissed. What gives? It seems headed towards failure. Why not acknowledge and try to understand?

8 thoughts on “On change management and display servers”

  1. Maybe because the answers were not given by “Canonical” but by a diverse number of people with diverse number of opinions?

  2. +1 This is an excellent observation and I concur that most engineers would benefit from higher awareness of the sociological issues around software development. I’ve been wondering if there is a fundamentally an issue with
    stakeholder identification / inversion. Naively, I would assume that a display server team would consider the various UI toolkits as clients/stakeholders and try to cater to their needs. However, the public communication from the Mir team seems to indicate that the relationship is the other way around and that the various toolkits need to adapt to their product/API. I imagine the “display server wars” dialog would be considerably different if there had been more consideration of the
    big picture stakeholder structure.

  3. Communication is very important.

    What I find very frustrating about this post is the way you frame the discussion. You introduce Martin and Aaron by name yet you don’t treat me as an individual, instead as a faceless “Canonical”. Neither my blog post or any of my comments said I spoke on behalf of Canonical in that post nor the comments I made would be necessarily shared by other Canonical employees. You even speculate that other commentators are “Canonical” with no attempt to actually fact check that. Sure you put a disclaimer there that you don’t know but by writing it you are continuing to add to this notion of “Canonical” as some sort of evil empire.

    There is absolutely no conflict that I know of between display server and toolkit developers. So I hope you have some more information there that I don’t know about because otherwise you are sidetracking my message with yet another pointless argument.

    Communication is incredibly important and I’m trying to help people understand complex engineering decisions that I and other people make every day. There are many people out there who struggle to understand these decisions and need to hear more than just the loudest people in the room. I’ve seen some good feedback that it has helped people. Sure it’s inflamed those who already think this is a “them versus us” argument but I don’t know a way around that.

    Constructive feedback welcome.

    1. You’re working for Canonical and you’re a developer for Mir. Mark reshared your blogpost and said he agrees. What you blog about will and is seen as you as a Canonical employee.

      I don’t know which people are Canonical employees and which are not. But that is another thing which why I wrote the blogpost: You’re saying that the display server doesn’t matter. People believe that, while actual feedback is being ignored. Now when there are real issues, people will keep repeating “toolkit will handle it” as a response to blogposts like yours.

      From what I understood, there is no code shared with Gtk+, nor any discussions taken place. The Qt bit seems in another branch from what I heard. I haven’t stated anything about toolkit developers though, just that your communication will not make me want to help out in any way.

      I didn’t name you because I didn’t want it to be seen as something personal. You’re assuming you’re talking on your own, I don’t see that. You’re part of Mir project, your part of Canonical, your blogpost get shared by the Canonical CEO. This isn’t framing things, if you’re saying “display servers do not matter” as a Mir developer and Canonical developer, it is highly relevant. That’s more than just “personal opinion” or “personal blog”.

      Regarding your last bit: Why assert that display servers do not matter? There is a huge pain due to the change. The title makes it appear that you’re not acknowledging this. I think you agree (pain), but the title of your post is IMO bad. I think I saw that you mention it will take some time, but based on the title of your blogpost, it seems people aren’t being taken seriously.

      Anyway, it is still unclear what is expected from various groups and at which timeframe. It still seems you expect e.g. Gtk+ developers to write the Mir code or maintain it. I don’t see this happening.

      I’m trying to understand Mir and followed e.g. a unexpected Mir presentation at FOSDEM. I found it rather painful to attend. Seems various decisions were taken by mobile bit, then hacks are needed on desktop side. I still have no idea toolkit developers should spend any time on this, nor do I expect them to.

      1. I don’t work on the Mir project.
        My opinion of Mir/Wayland is probably not what you’d expect. I’m not interested in wading into the merits of Mir, but I do assert that it like any project has a right to exist and be talked about.
        Mark is not the CEO of Canonical.
        As I understand it no-one has asked the GTK+ developers to write a Mir module or support it.
        I wrote the title of the blog because that’s what I believe. I know others believe the same and I know that many people who don’t know much about the subject think the display server is more important than it is.
        It’s a title, the rest of the argument is laid out in the article.
        I didn’t attend or watch the FOSDEM article. I’m glad you’re trying to find out about Mir and I hope the Mir team provides you with the required information.

        1. You’re getting pretty defensive? I’m really direct, don’t take that personal please.

          I find it odd that you think you have to say “has a right to exist”. I don’t see the point to state this. If toolkit doesn’t support it, assuming toolkit will hide all the details is incorrect. What is important is to get other people onboard. I think a large amount of people which should be assisting either are ambivalent or .

          Thanks for clarifying regarding what you NOT work on. Seems a got a basic assumption wrong. I read someone saying (reddit/LWN/Google+) that you’re on the Mir team. Oops.

          I still heavily disagree with you regarding importance of Mir though as well as the importance of a good title.

  4. This idea is very simple. In HTML, we used to check which browser and version of that browser the user was using, then adapt the webpage to that browser. This became increasingly difficult and if nothing had been done to fix it, it would’ve continued to become more and more difficult.

    So in HTML5, you’re no longer supposed to check for browser and version. Instead, you’re supposed to use standard tools that checks for features in different browsers. “Does this browser support feature X?” Either it does or it doesn’t. The reason is unimportant. This is a _very_ important development in the web scenario, which makes everything a lot simpler. It is very carefully designed that way in order to allow more rapid progress and more diversity.

    In the native scenario, toolkits have neglected this because it’s been safe to assume that there is only one display server for Linux. Now, this has suddenly changed and the toolkits haven’t kept up. That is the problem. That is the cause of the bugs Martin Gräßlin is referring to. Rather than checking if you’re using X, Mir or Wayland in order to see if grab is properly supported, this question should be moved into the toolkit so that you have a uniform way of asking for the feature without caring which DS is in use.

    I agree; Robert Ancell should probably have written; “Display servers _must_ not be allowed to matter to app devs or users”. Because right now, there are many bugs and those have consequences for both. But that doesn’t mean that we must only allow Free Software operating systems to use Wayland, enabling the bugs to become a design decision. It means toolkits must be improved to acknowledge the fact that there are differences between systems. And this would not only be a good idea for Linux systems. Qt also supports OS X, Win32, Android, etc. They’ll probably also have to manage large differences between Win32 and WinRT. These features are necessary. Sure, Mir might make the current bugs more visible, but that certainly doesn’t mean Mir is causing the bugs. That is a dangerous misconception.

    1. What I am after is that currently are multifold. The toolkit require changes. The assumptions are changing. Existing applications won’t work suddenly just if you provide a new toolkit. Further, toolkit developers are not using Ubuntu, so saying that this is up to toolkit developers is digging your head in the hand IMO. Canonical is creating a distribution specific display server and nobody is interested. The issue of being distribution specific is explained thoroughly by Aaron.

      Repeating again and again that it does not matter or that the toolkit will handle this: it is more than that. It’ll be repeated by people who don’t know any better. The very people you need to make the transition will be annoyed by the simplification. I’m seeing this happen already.

      You mention “toolkit developers” and Qt. Where are all the other toolkits in this? Why not talk about specific people? Whom in Gtk+ have been contacted? Canonical wants Mir, a lot of people see work for something they just don’t care for.

Comments are closed.