Scott Jenson
I need some help. My current theory is that for #opensource projects, bad #UX is a lot like #techdebt, both just creep into a project slowly over time. Much of this is likely due to small contributions that are easier to accept politically.
So I'm wondering: Are there any good talks or blog posts about managing technical debt in #FOSS projects? I expect it would speak to the same stresses of managing code (and UX!) complexity.
Tobias Bernard
@scottjenson In my experience it's usually the other way around: Software starts with good/bad UX depending on whether the early contributors are good at design, and either stays bad (most common) or gets better over time.
The problem tends to be that once a bad UI is widely used, there are huge political costs to changing it, which is why it's harder to fix a well-established app than a new and relatively unknown one.
Tobias Bernard
@scottjenson I'm curious though, what examples do you derive the tech debt theory from? I can think of plenty of examples of proprietary software getting worse over time, but off the top of my head, none in free software.
Matteo Gratton
I was writing about UX and Open Source this morning..
I agree that UX (and often UI) is not the only one technical debt. But it often is the dominant one that ditch a FOSS project.
It seems way easier to correct code debts than design ones. As usually they are inherited from the beginning of the project and a better UI cannot change it, but only makes a project look pretty.
Jan D
@scottjenson no blogpost but I think the idea makes a lot of sense. We had both tech- and UX debt at Mediawiki and I think often they are very much intertwined – you can't fix UX without some code change, but the code change would propagate, so you patch over it but the solution is not consistent with other code nor UX, so now you have more debt in both UX and code. However, this is not just an opensource thing, I guess…
Scott Jenson
@simulo completely agree this is NOT just an #opensource thing! However, it seems to be _easier_ for #FOSS projects.
My working theory is that there is a tendency for more decentralized decision making which, unfortunately, let's both creep into a project.
Repos can slide along, staying afloat for a long time, avoiding all sorts of best practices. While UX is the most famous way FOSS projects fail, my point is that it's not limited to just UX.
Adrian Cochrane
@scottjenson I'm seeing lots of great answers in your replies, but let me list the issues I see:
* A frequent lack of structure facilitating the decision-making UX-designers can participate in.
* Established projects often have a userbase hostile to change.
* Visual, etc designers often struggle to know who needs their help.
* There's a certain FOSS subcommunity who does not want to welcome non-techies.
Often UX-wise its easiest to start from scratch, though you loose the name-recognition.
1/2
Adrian Cochrane
@scottjenson Personally, for my own projects there's the fact that the UX considerations I'm striving to keep in mind are somewhat-intentionally weird. Because that's what I find interesting!
This does make it harder for me to accept feedback...
2/2
Adrian Cochrane
@scottjenson Anyways I suspect @cassidyjames would have something interesting to say, if he hasn't already written a blogpost!
Scott Jenson
@alcinnz @cassidyjames
It's just such a huge topic and, you know, it's perfectly fine for #FOSS to just be 'weird", that's part of it's charm.
And honestly, there will always be UX-indifferent repos and honestly, I don't care, it doesn't affect me if they don't want help.
What I'm trying to tackle are the teams that WANT help but don't know what to do. There is a clear mismatch and we should be able to figure this out.
Juliu
@scottjenson @alcinnz @cassidyjames perhaps something like https://readthedocs.org but for UX, that provides some default structure that makes it easy for newcomers to know what the UX plan was (if there was one). And provide a structure for how to ask questions at the right level.
I have long term plan to grow my UX app (TinyUX) into a platform that holds UX patterns, so you can also compose those. Maybe something like readthedocs could be part of that.
Scott Jenson
@rsms oh completely agree. It's more of a social observation: tech debt often accumulates as small hacks are easy to accumulate. You need a strong centralized set of decisions to fix it. Decentralized vs centralized thinking.
My hypothesis is that ux requires more centralized thinking and that is just harder for open source projects.
Rasmus Andersson
@scottjenson It’s an interesting comparison but I think a well-designed user interface is much harder to “codify”, to rationally specify and measure, compared to program code. With technical debt you can fairly easily identify what is inefficient or gnarly code and have a hundred people help with a hundred tiny fixes. What is that for UI I wonder?
joerick
@scottjenson @rsms I agree with that. Most OSS projects with excellent UX have leaders that work to keep things up to a high standard. One project that arguably bucks this trend, and I think is worth a look is Python- their PEP process is used for both design (E.g pep 498) and tech debt elimination (E.g. pep 594)
０７６萌ＳＮＳ is a social network, courtesy of ０７６. It runs on GNU social, version 2.0.2-beta0, available under the GNU Affero General Public License.
All ０７６萌ＳＮＳ content and data are available under the Creative Commons Attribution 3.0 license.