KDE Culture

KDE is a large, diverse, multi-generational organization, with a certain culture that has developed over time. A formal Code of Conduct governs how contributors and users ought to behave with respect to one another. Beyond that, certain cultural conventions have emerged over time in KDE. These are not formal rules, but rather shared norms and guidelines that tend to reduce interpersonal and technical friction over time.

Find a third way rather than taking sides and defending a position

It is common for a proposed change to be polarizing such that people align in different factions: one faction loves it, while an opposing faction hates it and feels the need to try to block it. In such an environment, emotions flare and productive conversation becomes difficult. Everyone walks away upset, no matter what the final outcome is. And any changes made with only minority or slim majority support will experience pressure to revert them when users start complaining and the original opponents say "see, I told you so!"

In such a situation, it's helpful to step back and try to find a third way that satisfies everyone--or at least more people. The result will hopefully be a larger majority in support, which will help the new proposal avoid controversy, get merged more quickly, and be more defensible if and when users complain--and they will, because every change upsets someone.

Examples where this worked:

• Instead of unconditionally increasing the transparency of Plasma panels and apps, make it adapt to the environment such that it becomes more transparent normally, but opaque when there is a maximized window

Hacks vs purity

KDE developers strongly prefer to fix issues in "the right way" rather than using workarounds. This means thinking about matters of technical correctness and long-term maintainability rather than rushing to ship something out the door right now. And when a bug is discovered at a higher or lower level of the stack, ideally the bug gets fixed there.

As such, never implement a workaround for issues in KDE code; instead, fix the issue there.

However there are various circumstances where this is impractical or impossible. A common scenario is when a depended-upon library is buggy but poorly maintained--for example X11. Another scenario is when a popular but poorly-behaving closed-source app or game triggers the wrong behavior in Plasma.

When a bug at a different layer of the stack cannot be fixed in the correct place for whatever reason, it needs to be worked around in KDE code. While this is unpleasant, insisting on purity of code and avoiding all workarounds for problematic upstream or downstream code will result in software that's very buggy and produce a torrent of angry users whose expressions of anger will de-motivate contributors and scare away other users. In a for-profit company, management chains and power structures exist to compel engineers who don't understand this to implement the workaround anyway so that the end product meets requirements and satisfies users. In a FOSS community, it's up to the engineers themselves to have the humility and wisdom to admit this and act accordingly to implement whatever unavoidable workaround are necessary to produce a high-quality end result.

When implementing a workaround, it's critically important to include a comment in the relevant code describing why the workaround is needed, including the URL of a bug report filed against the component being worked around. This ensures that the workaround can be removed if and when the bug gets fixed, because anybody can visit the URL of the bug report to see the status of the bug being worked around.

Work conservatively

In KDE, we value incremental change over huge redesigns. Where possible, it is preferred to fix bugs in existing code rather than to throw it out and start over from scratch. Mega-changes are harder to review, take longer to get merged, and risk unintentionally regressing things.

Such a drastic outcome should generally only be done where this is demonstrated to be necessary because the existing technical architecture is fundamentally incorrect or unable to be modified to meet current needs. And when proposing changes, only make the minimum change necessary to produce the desired end result. Resist the temptation to throw in "everything but the kitchen sink."