How KDE can transcend the cycle of Geeks, Mops, and Sociopaths

A few years ago I read a fascinating article about the cycle of how subcultures grow, mature, and die. The whole thing is worth a read (as well as the whole site), but here’s the abridged version:

  1. Creators invent something new and cool, attracting fanatics who validate them and help spread it around. These people are the “Geeks.” I would guess that most current users of KDE software are in or near this group.
  2. The coolness attracts “Mops”–normal people who want to enjoy the cool thing with minimal effort or investment. They dilute the coolness by demanding that it be simplified, sanitized, and mainstreamed for them. In KDE terms, these people would be our non-technical friends and relatives.
  3. At this point, the Geeks may start to quit because the coolness has been destroyed by the Mops. However sometimes the Geeks realize that Mops are key to expanding the cool thing even further.
  4. At this point Sociopaths will appear–people who participate in a system for the money or power games. They figure out how to monetize the Mops, allowing some Geeks to go pro and create the cool thing full time.
  5. Sociopaths increasingly exploit both the Geeks and the Mops, because they’re in it for the money and social power.
  6. The Geeks increasingly burn out because they’re spending their time unpleasantly interacting with exploitative Sociopaths and compromising their original vision to placate demanding Mops who provide their income.

I’m old enough that I’ve started to notice this cycle play out in various hobbies, subcultures, and even commercial companies I’ve been involved with: they start out small and cool, but along the way, mainstreaming and commercialization seem to corrupt everything.

I’ve also noticed that many FOSS projects seem to avoid this cycle and the dark fate at the end. Not all do, but some seem to. Why? How?

How FOSS helps

In the FOSS world, Mops are not easily monetized. The product is given away for free, after all! Only mildly Geeky Mops will be attracted, and the more entitled mainstream Mops can be told to pound sand when they start to demand more. They didn’t pay anything, so they’re not entitled to anything.

As a result, many FOSS projects are able to preserve their stable niche status because they explicitly reject a strong Mop appeal, limiting the attractiveness for Sociopaths. To tie this fairly theoretical discussion back to the software world a bit, Arch Linux is a good example: not having an installer acts as a gate to keep out low-investment Mops, ensuring that the project remains safely in the hands of the Geeks.

However this kind of gatekeeping–intentional or not–has a drawback: if the gate is too strong, the project may shrink over time as the original Geeks get bored or driven away by internal politics. Because the pool of Geeks is fairly limited, Geek-only growth largely involves poaching from other Geek projects; it’s a zero sum game.


What to do? Is it really a matter of keeping out the Mops and staying small, or letting them in and burning out after growing huge? And how am I able to reconcile knowledge of this cycle with my stated goal to get KDE Plasma onto every computing device on planet Earth? Earthlings are mostly Mops, after all.

How KDE can do it

Well first of all, I acknowledge that my goal is more aspirational than realistic. 🙂 Better to shoot for the moon and fall short, I think. I’d be pretty happy if we get Plasma to 15% global market share. That’s enough to be a major player with a direct and ongoing positive impact on human civilization.

Anyway, here’s how I think KDE can avoid the cycle, and grow powerful without being corrupted:

Attract all the Geeks

You may notice how many sysadmins, software devs, and general nerds have Apple computers outside of the FOSS world. In the early 2000s, Apple attracted a huge number of Geeks by pairing support for power-user workflows with an attractive user interface and high reliability. This was the “It Just Works” factor, for people who were doing work. It allowed Apple’s ecosystem to maintain a favorable Geek-to-Mop ratio, at least until the iPhone took off. KDE can realistically follow this path as well. I myself am a former Apple nerd. We can convert them. And the more Geeks KDE has, the more engineering talent it will accumulate, and the more Mops it can safely support.

Minimize the project’s reliance on Mop money

This avoids creating a financial incentive to dilute the product, and it reduces the project’s appeal to Sociopaths (at least, the ones who are attracted to money). KDE already has this pretty well covered, because we don’t sell products directly to consumers for money–with the exception of Krita on the Windows store (to my knowledge), and even then there are simple ways to get Krita for free if you want. The existence of a free version is a pressure valve.

Preserve the KDE community’s gravitational center for development

Today KDE benefits from outside companies paying people to work on KDE who are benevolent: Blue Systems (my employer), Enioka Haute Couture, KDAB, SUSE, the city of Munich, and various others. But it won’t always be this way as KDE rises in importance.

Large companies with little exposure to the FOSS world, but who use or sell products with KDE software, will want to hire their own engineers to contribute to KDE so they don’t feel like they’re shut out of the development of a product that significantly affects them. If enough of this happens outside of KDE itself, we run the risk of the project being taken over by sheer weight of outside contributions by large companies.

This is why I feel so strongly that the KDE e.V. should start hiring community members for technical roles. With the KDE community itself clearly in charge of the gravitational center of paid engineering, these outside companies would find it more convenient to simply pay money to the e.V. to strengthen those development efforts, join a sort of technical advisory board, or pay for priority access to engineering resources to fix bugs affecting them (not features, only bugs). These could give those companies the the “seat at the table” that they’re looking for while keeping technical decision-making firmly in the hands of the community. The project would be able to remain independent more easily.

It’s not a problem we urgently need to solve right now, but it will be in the future if we’re as successful as I want us to be. I think it behooves us to do it now rather than later.

Hire Geeks, not Mops

Whenever someone is paid to work on KDE stuff–either by the KDE e.V. or anyone else–always prioritize hiring KDE community members over outsiders. There’s always the risk that the outsider is a Mop who just wants a paycheck rather that someone who truly believes in KDE. Those with the privilege of being paid to work on KDE stuff should be people who go above and beyond because they love it.

Foster a culture of resistance to Sociopathy

KDE will probably never be an institution where you can get rich quick, and I see this as a good thing. But not all Sociopaths are in it for the money; some crave power. An important project like KDE will still hold appeal for the type of Sociopath who wants to push everyone around as the king of a little digital fiefdom. We need to keep these people out.

Unfortunately, while Geeks are generally good at noticing when Sociopaths show up, they are generally terrible at kicking them out. Geeks can be conflict-averse, or believe that the Sociopaths can be reasoned with, reformed, or safely tolerated because they do some good work. They cannot be.

KDE needs to maintain and expand a culture of resistance to Sociopathy by teaching its members to harden themselves against Sociopaths and and use some of their own tactics against them when they show up. Nobody should be the king of KDE. KDE should not have a king! Central leadership is a risk factor, as I blogged about earlier.

What it all looks like

KDE will attract as many Geeks as possible through our continued commitment to technical excellence and supporting power user workflows in our software. We minimize the risk of demanding Mops burning everyone out by not selling anything to them directly and maintaining a favorable Geek:Mop ratio through our attraction of lots of Geeks. We start paying for engineering talent, but we hire insider Geeks, not outsider Mops. And we do it within KDE itself. Then we remain vigilant for Sociopaths craving power, and we kick them out so that KDE can remain a safe place for the Geeks.

So who’s ready to take over the world with love and positivity and user-empowering high quality software?

43 thoughts on “How KDE can transcend the cycle of Geeks, Mops, and Sociopaths

  1. Fantastic and thought provoking post, Nate. I’m glad yourself and hopefully others in the gang at KDE are thinking of these things. Open source projects are certainly not immune to this kind of rot and I’ve seen others where a new wave of joiners become particularly obsessed on the ‘governance’ front in an unhealthy way without seeming to contribute much of use.

    I’m also absolutely in favour of prioritising the ‘geek’ element who have a proven track record with the project on the hiring front.

    I’ve often thought old Linus himself should be funded purely by donations (without the reigns of a foundation) so he’s free to do it his way – the way that has proven itself.

    Like

  2. The level of damage people like Coraline Ehmke have done also can’t be understated, – the particular brand of sexism coupled with control issues and a pathological hatred of one specific gender also needs to be tackled, because “hiring geeks” doesn’t preclude us from getting into the mess that Ehmke generated. We need to be kinder while still hiring on merit and skill.

    Like

    1. We need to be kinder while still hiring on merit and skill.

      I think that’s key. These aren’t mutually exclusive. Hiring based on merit doesn’t have to exclude women, and being kind and inclusive doesn’t require abandoning meritocracy.

      Liked by 1 person

  3. Interesting read – as an non-coding user I guess I am a Mop 😮
    With an increasing user-base (on commercial side but also on private side) to my understanding the amount of geeky coders have to scale up in the same way. You described how companies could contribute (with money or talent), but what about the pure users? Of course money donation is an option – but, what do you think of a Kickstarter-style approach for paying for certain features?

    Like

    1. FWIW If you participate at all in promo, outreach, making the devs feel happy, reporting bugs, triaging bugs, evangelizing the thing to your friends and family, then you’re more likely a fanatic, and thus a geek. 🙂

      I think it’s great when regular users contribute financially, but I think it’s somewhat important that this money is seen as a donation and not a pay-for-service contract, either explicit or implicit. Because we don’t have the capacity to use money to provide the level of service that regular people typically demand. Not accepting money for explicit service helps to set their expectations accordingly, so they don’t feel like they’re not getting what they paid for.

      Liked by 1 person

  4. “KDE will attract as many Geeks as possible through our continued commitment to technical excellence and supporting power user workflows in our software.”

    You can’t imagine how much, the mere consideration of this by one of the most visible faces of KDE, can put me (a geeky mop) at ease.

    Liked by 1 person

  5. I really not a fan of this article. We shouldn’t call user “mops”. Users are an important part of the community. They don’t write code but they are the reason we write the software. So a bit thanks to all the users who are using KDE software 🙂

    And about hiring, while hiring devs is really important and I think it is a bad idea for the e.V. for not wanting that. We should also hire people who are not developers. In the promo team, it’s mostly Paul who is working and we desperately need more talented marketing people. Same with translations, we are missing large markets because we don’t have enough Chinese, Arabic, German, … translations, making it unable to use our software in these countries (or only for the few who know English). https://l10n.kde.org/stats/gui/trunk-kf5/team/

    Like

    1. I’m sorry you didn’t like it. I had a feeling that it would be somewhat controversial. 🙂

      The intention is not to insult our users, not at all. I see now that the original post was insufficiently clear about that, and I will update it. I agree with you: users are key! We are doing this for them!

      Rather, I was trying to call attention to a describe the pressure to change the fundamental nature of our software to attract a different kind of user who is is farther from the community, less technical, less engaged, and potentially with more feelings of entitlement. Basically I believe there are risks to courting these users without laying the necessary groundwork first. Not that we shouldn’t do it, but that we should do it safely, and smartly, so their influence doesn’t come to dominate everyone else’s.

      FWIW I think hiring more promo people and translators would be a fine idea. I don’t think that we should hire only devs and sysadmins. If there’s enough money available, we should spread it around widely IMO!

      Like

    2. End-users are the real KDe. Because without end-users the instrument is useless. Problem is that developers often don’t accept user’s feedback. The developer knows as the instrument is done, the end users knows as the instrument works based on its own experience. When end-user indicates a problem or make a suggestion, the developers think the end-user be criticizing in negative purpose. Often happens that both end-users and developers are sociopaths.

      Like

    3. I think we do a pretty good job of listening to feedback, actually. Tons of the changes we’ve made are based directly on user feedback. Again, we’re doing this *for* the users, wo not listening to them would be silly.

      The challenge is in creating something that works for everyone, because users are not a monolithic group. Some people want thing A, and some people want thing B. But what do you do when A and B are fundamentally opposed to one another? Pleasing everyone is harder than it looks. 🙂

      Like

    4. YEs. In this case the solution is simple. There are suggestions or critics about objective aspects and others dealing with personal preference, that is subjective aspects. It is necessary to divide what is objective from what is subjective. If the user talks about the way the desktop works, he is talking about objective arguments. As example, if I say that the arrow icon on the PRINTER menu of the notification area is useless, because all that space is uselessly used, forcing the end-user to click over the arrow icon to show both print config and print queue, I’m talking about an objective aspect. Why is it objective? Because the action I’m describing happens for all the users unequivocally, while, if I expose a consideration about PLASMA environment colors or preferred style of its icons, I talks in subjective perspective. Now the developer who was committed to make the arrow to show both print setting and print queue could be unhappy to read that something he made is useless, however for end-user it is useless anyway, because it is not productive to make something of completely useless when there is space in the menu appearing during printer activity for both printer settings and printer queue which are hided. I hope the example clarifies the concept. The wide person is the proactive one. the several type of categorization you have issued in this post are extreme cases. There is the trivial end-user which is happy if an improvement is made because he suggested it, and another kind of end-user which is happy because the product he sometimes critics works better not only for him. These are different perspectives. Fundamentally end-users are just feedbacks of your own product. They are the way to know what is working and what doesn’t work so to make your own abilities better. The best end-user is the one able to recognize the positive and to highlight what can be improved. Critics are always good. There is the fanatic and the end-user satisfied to use a product. The same subject sometime can be wide, in other case sociopath, sometime nerd, other times mop, or geek.

      Like

    5. I say that the arrow icon on the PRINTER menu of the notification area is useless, because all that space is uselessly used, forcing the end-user to click over the arrow icon to show both print config and print queue, I’m talking about an objective aspect.

      This seems like a reasonable critique. Did you file a bug report about it? If not, can you? I’d be more than happy to look into it. I wrote the relevant code so I know how to change it pretty easily.

      We love feedback, especially sensible, constructive feedback like what you pointed out. However it needs to reach us. 🙂 Bug reports are the best way to make sure that happens.

      Like

    6. If I send this feedback to a wrong section among the different categories listed in the main site of Kde bugs site, it will be obviously deleted. Sometimes, end-users have difficult to detect the right section to address the suggestion or the problem because what is clear to the developer could not be clear to the end-user, so the end-user prefers to renounce. Probably if all those categories were included in macro-categories would be more simple to get the right section in which notify the issue. Example: all what deals with printer is in printer category. I’ll try to try.

      Like

    7. If I send this feedback to a wrong section among the different categories listed in the main site of Kde bugs site, it will be obviously deleted.

      That’s not true at all. What will happen is that one of the bug triagers (me, Christoph, Justin, and others) will move it to the right place.

      If you have no idea where to put a bug, the generic “kde” product is acceptable.

      Like

    8. As I outed myself as a mop up in an earlier comment, two more comments to this thread:

      I did not felt insulted or anything like that being a mop. I was doing very little software development ages ago, so I am fully aware of the cultural differences between developers, users and everything in between. Of course others might be, which are not aware of that – but everybody has to speak for himself.

      Regarding reporting bugs:
      I used the first (german) lockdown to move to Linux & KDE, so I consider myself still kind of a newbie. Till now I have not opened a bug report 1) as I am running on Kubuntu, so my packages are not bleeding edge and the issue might have been fixed already 2) I am fully aware that most of you are doing this in you free time, so I did not want to waste your time with technical limited written reports (but I hope this will change over time, once my technical understanding is getting better)

      Question about 2): if the user base increases, do you see a risk of drowning in “meaningless” bug reports? If yes, what to do about it?

      Like

    9. The Krita people have already experienced that success brings in less-technical users who file worse bug reports. I haven’t followed the situation as closely as I should have, given my interest in this topic, but the last impression I took was that they’re still kind of struggling with it. They tried setting up a StackExchange-style site where users can help each other with support-type questions but I think it didn’t work for whatever reason. It’s definitely a challenge.

      Like

    10. Bug reports don’t get deleted, they get closed if they are fixed or are not actionable.

      Please file bug reports when you experience problems.

      Like

  6. A really thought-provoking article! Thank you for that! I can see this lifecycle in many (used-to-be) cool projects. I think that as long as we keep the common understanding why we need and develop KDE then the project will live. I think with the bigger, mainstream scale the reinterpretation of the project goals will come and it will be the make-or-break point for the KDE.
    When the project and this kind of idealism becomes diluted, the community needs to act fast, but I’m sure it’s the problem we will be prepared to deal with.

    Like

  7. Hi Nate,

    I am really enjoying your blog. I usually get a sense of progress for KDE as a whole which is difficult to get it from elsewhere.

    This article as you guessed it is somewhat controversial. It certainly provides an interesting theory that may explain the rise and the fall of some other software projects (free or not).

    I understand that the underlying theory comes from a book. In a book the author has more time to explain the terms it uses. A short blog post doesn’t have this capability. For example I stumbled in the word fanatic (others in the word mops).

    I consider myself a geek but not a fanatic. I like KDE but I am not trying to impose it to others in every discussion. My life is not KDE although I like to get updated about it. I can talk about other things that may be computer related or not. How can I be a fanatic? Is it possible that I am and just don’t admit it? That’s terrifying…

    Or as I would like to think the book uses the word fanatic way more lightly that its normal use. I certainly hope so…

    All in all a thought provoking article.

    Thanks.

    Like

    1. Yeah, “fan” is actually short for “fanatic.” 🙂 In this context it just means “person who is obsessed with something” (guilty as charged!), not “political or religious wacko who wants to kill people.”

      Like

  8. Greetings!

    First time writing a comment here but I have being following your blog development for a relatively long time and I always find very interesting to see the changes and contributions made into Plasma and all other Kde projects even though I am not directly involved with the development process – something that I want to change very soon but at least for now I opted in the telemetry setting.

    Just want to applaud all the work within the project and all your dedication. Your most recent participation in LUP was very entertaining and my venture into Wayland is almost a success 🙂

    Have a nice week!

    Like

  9. A very interesting read! I really appreciate these more philosophical discussions regarding open source and KDE and especially your thoughts in these regards.
    I too have certainly noticed this ‘Geeks, Mops, and Sociopaths’ cycle although not quite in the way you have articulated it.

    Overall you make an excellent assessment of issues. They bring up points to be made about sustainability, funding, rewarding, paying as well as organisation, control and power.

    A former Apple geek myself, I agree with you assessment of Apple. Yes, sociopaths do exist and they cannot be reasoned with. They are a hard set case. Demarcating between Geeks & Mops though is not as clear cut. Wozniak is most certainly a geek. Jobs however I would argue has one foot in the geek world and one foot in the Mop world. Of course this does not dismiss your argument. You make the point of a balance between geeks and mops but this does not mean to say they are mutually exclusive of each other. Categorisation of course is necessary to make sense of order.

    This however leads me to thinking, “Does there even need to be a (regulated) gateway keeping?” and as you point out with ‘How FOSS helps’ the very nature of open source mitigates the problems of what I would argue are the rotten fruits of of proprietary software and government regulations/manipulations.*

    ‘Growing huge’ is more the exception than the rule in open source but this is also the case even with commercial ventures. Perhaps the focus should be on fueling the dev so that they do not burn out. That is, funding/paying devs so that they are sustained to produce FLOSS and rewarded for adding value to others. Is it the demands to produce FLOSS (something they enjoy) that burns them out or is it the fact they have to do it in their recreation time that burns them out?

    With regards to this you recommend a (part) solution of
    “KDE e.V. should start hiring community members for technical roles.”
    Is this the answer? What have other open source communities done?

    Recently Bitcoin Cash had an issue on how to pay devs. One faction wanted a guaranteed income controlled by a centralised company. The community chose to continue with a decentralised system and allow all funding to be self directed and left up to those within the wider ecosystem.

    If you wish for a “seat at the table” situation should the KDE community look towards the Linux Foundation for inspiration? This org has many outside companies that have paid for the privilege of being inside. Many linux advocates do not consider many of these corporations to be benevolent though!

    Of course you can set a rule to “prioritize hiring KDE community members over outsiders”. This is how most uncoerced/free market businesses operate – in the absence of outside manipulations (by government) . They recognise the previous efforts and commitment. From what I have observed both Canonical and Red Hat do so.
    Would such a rule suffice though?

    History shows us that when power becomes more centralised then it tends to grow and become corrupted despite any set limitations. eg the USA

    Would not the greater risk be a “seat at the table” rather than the “risk of the project being taken over by sheer weight of outside contributions by large companies.”?
    As KDE rises in importance do we inevitably end up with a ‘Linux Foundation’ in which those who run it do not even use free software?

    I think this is worth consideration especially after you so eloquently made the case for the advantages of the ‘anarchic’ approach. Be careful not to throw the baby out with the bath water. Acknowledge and foster the strengths KDE has.

    That said, are there way in which KDE can be more organised in its approach without succumbing to the perils of central control that sociopaths eventually co-opt?

    Dash crypto is an interesting case. They try to solve the governance and payment problem though a decentralised voting budgeting system.

    “Functioning like a decentralized Kickstarter or Lighthouse, the budget can be used for anything that creates value within the ecosystem.

    This is a 100% decentralized system” also “allows Dash to hire core developers and pay them directly after approval of the work in a decentralized fashion.”

    KDE is of course not a crypto currency but perhaps lessons can be learnt to use blockchain technology in order to maximise accountability, transparency, efficient funding and to minimise the influence of sociopaths in governance.

    Thank you for a great read!

    *[Is the problem really ‘commercialization’ and “monitization” per se?
    Commercialisation in a benign perspective is simply the sustainable (profit based) practice of bringing to a greater number of people the virtues of a creative product though artistic means. Nothing wrong there. In fact is beautiful and should be celebrated.

    Things get ugly however when market power is artificially monoplised into corporations through the violence backed practice of false property rights called ‘Intellectual Property’.
    Add to that the hyperisation of consumerism produced by an artificially enforced inflationary money system. These factors are a bigger argument though.]

    Like

    1. You raise a lot of thought-provoking questions, and I admit I don’t have a lot of answers. But I think it’s good that people think about this stuff before we get huge; we have an opportunity to plan our own future proactively, not reactively.

      Regarding outside companies, I think they will want power over KDE in some capacity once they become dependent on us for their revenue streams, infrastructure, etc. So my thought is how to give them a little bit to satisfy their desires while keeping ourselves firmly in control. I think if we don’t do this, there’s a risk that their attempts to exert control will overwhelm our ability to maintain it in the community.

      Like

    2. Indeed it is preferable to plan than react and it is certainly in everybody’s interest to have good communication and efficient networks in place for all involved including companies.

      Can this be done with out centralising power too much? Following on from my thoughts about how blockchain may help in this regard it seems Bilgin Ibryam (Red Hat) has written a very interesting article in this regard: How blockchain will influence open source https://opensource.com/article/18/8/open-source-tokenomics

      eg: “If users of open source projects can donate money and the foundations can distribute it in a fair way, what is missing?

      What is missing is a direct, transparent, trusted, decentralized, automated bidirectional link for transfer of value between the open source producers and the open source consumer. Currently, the link is either unidirectional or indirect:”

      He acknowledges that companies that back open source projects play an important role in the ecosystem: “They are the catalyst between the open source projects and the users.” but then adds “Imagine there is a model with mechanisms and tools that enable direct interaction between open source users and developers.”

      Hopefully you get a chance to read it Nate!

      Using such tech may help for interaction with companies but also importantly for the end user! I for one have been frustrated in my ability to donate to people and projects that I wish to support. There is surprisingly not much in terms of infrastructure in place. One can support KDE but this appears to go to the KDE.e.v and you cannot specify the area or project you wish to support, reward and incentivise. It is great when a ‘Pineapple Fund’ can support KDE in general but what if a user wants to signal interest, support and fund a single project like Banji, Kmail, Kwave or an active dev working on digiKam?
      Blockchain systems and token can help send funding to where users want it and ‘democratise’ the ecosystem for all participants.

      Like

    3. Democratic systems need some controls to prevent abuse by some of the actors (to stay with the terms, these would be sociopaths). They could drive campaigns to shape opinions with the goal of directing funds to the devs of their preference or divert funds away from other devs. A technical control could be to have a percentage of the donation, say 30%, always go into into the general pot. Though purely technical controls won’t cut it. Social controls would be needed as well.

      Like

    4. Please do not mistake my use of the term ‘democratise’. Hence the quotation marks. I do not mean democratic systems or collective voting. I simply mean -formal : to make (something) available to all people. I mean giving individuals actors (including orgs) customised ‘purchase power’. As opposed to limited options and centralised control.

      Yes, sociopaths can be charming and persuasive and can shape opinions but so can those who have shown proven leadership and value within the KDE community.
      To do anything about this other than open discussion would mean censorship – which is a terrible idea.
      I do not think there should be any ‘social controls’ outside of those stated in the KDE manifesto.

      Like

    5. > Regarding outside companies, I think they will want power over KDE in some capacity once they become dependent on us for their revenue streams, infrastructure, etc.

      This is the GNOME / Red Hat issue. Over there, Red Hat is doing so much (mostly good) work that they have more or less taken over leadership for GNOME and also control asignificant amount of related projects, like systemd or Pipewire, even Wayland and the Linux kernel to a lesser extent.

      It’s an excellent question to ask what should happen once a large, beneficial entity comes around and makes outsized contributions to KDE – and chances are that significant growth will be driven by one or max two commercial entities. Do we tell them to get a minority (say, not more than 33%) on some sort of technical steering committee or conflict resolution board? Are we going to stay deliberately small and “focused on power-users” to allow the rest of the community to catch up with the growth? Saying no to growth in order to preserve our principles? Who gets the authority to reject otherwise valuable technical contributions? How do we protect KDE from a situation where Red Hat is acquired by IBM and shifts its focus away from community needs / towards enterprise cloud offerings?

      KDE has so far avoided these questions by being strictly owned by the community, but has stayed relatively small as a result. GNOME has embraced corporate sponsorship and got promoted to default in a number of distributions, mainly because the commercial entities feel comfortable with their power to mold it to their use cases.

      On this front, Roman Gilg and KWin-FT comes to mind – his vision and timelines didn’t match up with the “community” (particularly Blue Systems?) so he directed his efforts elsewhere. KDE will have to find a delicate middle ground between being “moldable” enough for commercial solutions while also preventing companies to do hostile forks for taking over control and large parts of the user base. I think the Geek-focused approach is the right one, but in order to get large-scale buy-in, I think it would help to formalise it with a set of principles to lock in such decisions in advance, as good as possible. When the time comes, the draw towards widespread adoption may already be too large to say no to it then.

      Further complicating is that this is a decision that each sub-project and maintainer may end up making by themselves. I mean, obviously Krita leadership will decide their fate and not a hypothetical KDE technical steering committee, right? If someone productizes Maui apps over standard Plasma Mobile, they’ll hire a bunch of people from that team and by putting lots of work into it, *this* will be the new face of KDE. Not the UX we old folk know and are comfortable with. They’d likely start out using KDE tech, namelessly hidden under different branding, and swap it out later with replacements that they have more control over. Krita, being the awesome and successful project that they are, may well decide to prioritize their own users over the good of KDE as a whole – Boud has already blogged about such thoughts.

      So there’s not just an issue of decision-making, but also of branding and unity. If KDE is as swappable as, say, the Unity and GNOME desktops on Ubuntu, then whatever decisions the community makes won’t matter all that much in the end. To retain control, KDE will need to keep a direct channel to users that can’t be easily co-opted. Not unlike Apple, which didn’t let phone vendors co-opt the iPhone updates and branding. Owning the full vertical stack, with defined but limited extension points. But how to square that with KDE’s open source heritage, which promotes modularization and customizability? Tough problem. After all, we want to empower people and not limit them.

      Then again, most freedoms are bought with restrictions for a group of people. For freedom of speech, you have to restrict governments to pass censorship laws. For freedom from harassment, you have to restrict other people’s freedom to harass you. Freedom of religion requires freedom from other religions’ rules. And such. KDE is a step ahead here because it has a formulated set of values. It could pay off not just to list its values, but also to contrast them to other desirable values and model a head-to-head competition of values. No strawmen, there are lots of tough and valid choices out there.

      And then you’d want to think about how to deal with people who haven’t signed up to these guidelines (rules?) from the start. Lose people and sponsoring companies like GPL3, throw them out of KDE? Compromise in certain ways, tiered association levels?

      There are a ton of questions to figure out if you want to drive this successfully. I’ll stop here because it’s already too long.

      Like

  10. Isn’t all of this already happening / already happened in the past?

    For example, Linux and foss in general with the whole Coraline Ehmke thing (post meritocracy manifesto is literally a direct political attack on open source software, a thing to gain “social power” as you describe it)

    Another example in kde: https://mail.kde.org/pipermail/plasma-devel/2018-June/086117.html
    Another example is the recent pride month / blm / witch hunt stuff that has created a lot of useless flamewar in the chats

    An open source community should not engage in any kind of non technical discussion (I consider UI design and marketing technical discussions) because it has nothing to gain from it, and all to lose, again: a “power game” for some users to witch hunt other users on an arbitrary and often indefinite moral standard, this has nothing to do with software. I’ve seen this happening in kde chats.

    Like

  11. I consider myself a typical “mop”. I am a very happy user of Plasma. But I like computers in general.
    Other than e.g. food, software is very easy to multiply. That is the nature of software. A member of the public such as I is very happy that it is. That means that a software project could very easily have a great audience.
    But if there is one thing: I would NOT like it to stand in the way of anyone. I would not like to consume your time with no useful purpose.
    Perhaps it’s best to look upon me as an ordinary customer. But then one who likes to file a bug from time to time. If I think it can help. Apart from that I am an avid follower of “Nate’s Blog”.
    To communicate in such a way leaves the impression that there is life in the project. Not only to the “mop” but also to fellow software projects. I think it is very wise to do so.
    I wish all members of the KDE ecosystem a good new year.

    Like

  12. There might be some truth in the model used like that having more mainstream users can be leading to more workload (like bug triaging).

    However, I am currently wondering whether using this model can provide much benefits. First of all, grouping people is always problematic. It creates artificial borders where in reality is a continuum. One has to be pretty careful when one wants to derive conclusions from such biased models.

    I also skimmed through the original article you linked. I am unsure what “subcultures” it was talking about, as some generalizations made there might not apply to KDE or FOSS projects after all rendering the model pointless in that field.

    Also please note the following quote from there:

    “Anyway, horribly, geeks need sociopaths—if the New Thing is ever going to be more than a geeky hobby, or a brief fad that collapses under the weight of the mop invasion.”

    This is contrary to what you state, so I think at least one should explain why you come to a different conclusion here.

    That are just some thought of mine that I had when reading the post.

    Also there might be a different view on this describing the situation better:

    KDE is a community of individuals who are losely organized and losely work on a software project out of different motives. The overall goal of the KDE project seems to be to grow. That means reach more individuals who ideally will also contribute and keeping the already involved individuals. [I know this is extremely broad, but it had to be that broad to not make false assumptions].

    Now after the scope has been established one could dive in more deeply.

    For example one can analyse the motives for individuals to work on projects, find out how to reach more individuals and what consequences might araise from there.

    Like

    1. It’s British English slang for “Member Of The Public”; it was used in the original article so I just used it here too.

      Like

Leave a comment