Uwagi dotyczące usability w otwartym oprogramowaniu Matthew Paul Thomas spisał w tekście pt. Why Free Software has poor usability, and how to improve it. Jest to rozwinięcie jego wcześniejszego artykułu pt. Why Free Software usability tends to suck.

Na wstępie artykułu MPT zaznacza, że wymienione przez niego problemy nie są tylko przypadłością wolnego oprogramowania, ale wszystkich programów tworzonych przez ochotników. Ponieważ w w przypadku wolnego oprogramowania większośc programistów to ochotnicy, to problemy te są wyjątkowo widoczne w tym obszarze.

Poniżej lista problemów i rozwiązań proponowana przez MPT:

1. Brak zachęt do usability - dla twórców wolnego oprogramowania użyteczność programu nie przekłada się na pieniądze. Dlatego nie dbają oni o usability. Rozwiązaniem problemu mogłyby być konkursy na najlepszy wolny (od wolności) interfejs, za który twórca otrzymywałby nagrodę.

2. Brak projektantów interfejsu – twórcy wolnego oprogramowania są dobrymi programistami, ale nie muszą być dobrymi projektantami i specjalistami w dziedzinie usability. Rozwiązaniem problemu może być stworzenie kursów usability dla programistów oraz wyznaczenie w społecznościach osób odpowiedzialnych za projektowanie interfejsu (np. głównego projektanta), które posiadają odpowiednią wiedzę.

3. Niemile widziane uwagi dotyczące projektu – twórcy wolnego oprogramowania nie lubią uwag dotyczących interfejsu, choć dużą uwagę przykładają do kodu. Rozwiązaniem problemu byłaby taka organizacja pracy, aby główny projektant mógł publikować sugestie na temat projektu oraz zbierać informacje na jego temat na podobnej zasadzie, na jakiej działa zgłaszanie błędów w kodzie.

4. Usability trudno zmierzyć – o wiele łatwiej jest ocenić szybkość działania programu niż jego funkcjonalność. Ta druga cecha może być postrzegana subiektywnie. Zdaniem MPT należałoby więc rozwinąć narzędzia do testów użyteczności, które można przekazać deweloperom.

5. Kodowanie przed projektowaniem – oprogramowanie według MPT jest lepsze, jeśli kodowanie poprzedził choć powierzchowny projekt. Rozwiązaniem mogłaby być zmiana "kultury pracy" - najpierw projektowanie, potem kodowanie.

6. Gdzie kucharek sześć... - każdy chce się wypowiadać na temat interfejsu (i projektu w ogóle), ale nie każdy ma wiedzę na ten temat. Dlatego wyznaczenie głównego programisty i projektanta może uchronić od przeniesienia na projekt dziwactw charakterystycznych dla danego programisty.

7. Naśladownictwo – wielu deweloperów uważa, że dobre jest to, co już zrobiły firmy takie jak Apple lub Microsoft. Według MPT konieczne jest zachęcanie do innowacyjnych rozwiązań.

8. Szycie na własną miarę – ochotnicy nierzadko piszą programy, których sami będą używali. Dlatego np. oprogramowanie adresowane do szerszych rzesz okazuje sie produktem dla geeków. To jeden z problemów, który trudniej rozwiązać. Generalnie należałoby nagradzać programistów za proste projekty i nie tolerować rozwiązań bardziej złożonych.

9. Ignorowanie drobnych niedociągnięć – detale mogą sprawiać, że użytkownik będzie miał poczucie lichego wykonania programu. Tymczasem w przypadku wolnego oprogramowania detale naprawiane są po latach. Zdaniem MPT małe problemy z interfejsem powinny być usuwane natychmiast, a programiści nie powinni mówić "to tylko mały problem z UI".

10. Zarzucanie użytkowników opcjami – zwykle ochotnicy tworzący program mają różne wizje, ale w przeciwieństwie do programistów w firmach nie decydują się na określone rozwiązanie. Ich sposobem na taką sytuację jest pozostawienie wyboru użytkownikowi. Jego z kolei może to dezorientować. Rozwiązaniem problemu powinno być promowanie "kultury prostoty".

11. 15 pikseli sławy – ochotnik nierzadko chce się pochwalić swoim wkładem i wykorzystuje do tego interfejs. Czasami owocuje to pojawieniem się w programie dodatkowych opcji lub obiektów, które w ogóle nie są potrzebne. Rozwiązaniem mogłoby być stworzenie bloga lub innych miejsc w sieci, na których publikowano by informacje o twórcach programu.

12. Problemy z komunikacją w projekcie – nierzadko programiści pracujący nad programem po prostu nie mogę się dogadać. Ich koledzy tworzący zamknięte produkty nie mają z tym problemów, gdyż są w jednym pokoju. Rozwiązanie: promować VoIP, wideoczaty, narzędzia do pracy kolektywnej itd.

13. Częste wypuszczanie nowych wersji – programiści nie dają czasu na poprawienie interfejsu a osoby, które w trakcie testów przyzwyczają się do danego rozwiązania, nie będą chętnie korzystać z interfejsu poprawionego. Rozwianie: publikować specyfikację interfejsu tak szybko, jak to możliwe.

14. Modularność – tworzenie aplikacji z wielu gotowych fragmentów kodu sprawia, że niektóre elementy trudno przystosować do potrzeb użytecznego programu. Tutaj również rozwiązaniem powinno być projektowanie interfejsu w pierwszej kolejności.

15. Rozproszenie projektów – jeden projekt może korzystać z dorobku kilku innych projektów, które z kolei mają różne cykle wydań. Uczestnicy projektów nierzadko w ogóle nie kontaktują się ze sobą. Trudno w takich warunkach o poprawki w dziedzinie usability. Rozwiązniem byłoby zacieśnienie współpracy pomiędzy projektami.