I see four large topics here: infrastructure and separation, autochecks and scratching own itches
Infrastructure
Most infrastructure in open source has code as its core “type” of thing. This is not surprising given that most code is text and given the status of text media in western culture.
Everything else is modeled after or around text: Communication media, storage of content, collaboration systems. Thus, doing non-text things in the existing infrastructure is hard.
Separation of parts
Design is hard to split up in parts which you patch together. For code, you can relatively easy define input and desired output and then it can be developed and if it adheres to the spec it will work. There are more elaborate versions of this to standardize this connectability. I guess “pipes” in unix are very well known, and this directs us also to where open tools seem to shine: Small tools, text interfaces, standards.
At least according to best UX practices, what the user sees should be coherent and it is hard to distribute.
Autochecks
A lot of coding infrastructure has “decisions” build in: Unit tests, coding style checkers, compiler errors and warnings etc. Designs are checked manually. We might have been closer to it in the 90s when Human Interface Guidelines were very strong, but they seem to have less strength today (maybe still at Apple?)
Scratching own itches
Scratching our own itch in code is seen as a core motivation in open source (see cathedral and the baazar). It is also easy to do this in code. You can easily start by writing the code that scratches your itch. A commonly named best practice in UX is “you are not your user” (Source). This gives less agency to the designer as you need somehow find out what other people’s itches are (hard, time consuming) and you do not have the motivation of doing away a problem which is yours and thus where graspable.
Addition to Scratching own itches: A source on this is “Scratching Someone Else’s Itch (Why Open Source can’t do Usability)” (also in ACM/Interactions, January 2004)
Addition to separation of parts: Limits of self–organization: Peer production and “laws of quality” argues that a lot of web collaboration projects assume that the modularity of small parts in much software does often not work for non-software.