Unter Endbenutzersoftwareentwicklung verstehen wir im Rahmen dieser Studienarbeit alle Erzeugnisse von Anwendern der Software, welche wiederrum von anderen Benutzern zur Verwendung der Software genutzt werden können.
Beispiele für Endbenutzererzeugnisse umfassen somit Dokumentation, Vorlagen (Templates), Makros, Konfigurationseinstellungen und -skripte, Änderungen des Aussehens des Programms (Skins, Iconsets,...), Tutorials, Howtos. Auch Quellcode selbst kann Endbenutzersoftwareentwicklung sein, aber üblicherweise sollte man nicht davon ausgehen, dass Endbenutzer über mehr als eingeschränkte Programmierkenntnisse verfügen.
Ziel dieser Studienarbeit ist es nun, eine Prozessverbesserung im Umgang mit den Erzeugnissen der Endbenutzersoftwareentwicklung in einem Projekt einzusetzen. Hierzu gibt es zwei Vorschläge:
Eine dieser beiden Prozessverbesserungen soll an einem Projekt eingesetzt werden, bei dem die Hoffnung besteht, dass sich Endbenutzer für die Verwendung dieser Prozesse finden lassen.
Die folgenden Definitionen dienen als Grundlage für die Bearbeitung des Themas. Da dieses im Allgemeinen ein sehr weites Feld ist, wird nicht der Anspruch auf Vollständigkeit erhoben. Sie dienen lediglich als Rahmen für die Forschungsaktivitäten.
EndbenutzerZiel dieser Studienarbeit ist es ein Abhängigkeitsmodell zwischen Opensource-Software und Endbenutzerentwicklung aufzustellen, welches dann mit Hilfe empirischer Untersuchungen untersucht werden soll. Um bedeutsame Zusammenhänge aus diesem Modell zu überprüfen, sollen ein paar Thesen aufgestellt werden, an denen dann konkret das Modell überprüft wird.
Thesen1. HowTos und ähnliche “nichterklärenden Hilfen” (Forenbeiträge), helfen nicht beim Bewältigen der Lernhürde, denn sie tragen nicht zum Lernen / Verständnis bei, sondern sind gefährlich da sie den Endbenutzer nicht vorhandenes Können suggestieren.
2. Die große UserCommunity ist der entscheidende Faktor für die Motivation des Endbenutzers.
3. Die große UserCommunity trägt mehr zur Motivation des Endbenutzers als zur Verringerung der Lernhürde bei.
4. Die oftmals schlechte Dokumentation kommt oft einer unüberwindlichen Lernhürde gleich.
5. Der modulare Aufbau der Software, bedingt durch die verteilte Entwicklung ist ein Vorteil beim Schaffen veränderbarer Architekturen.
6. Bei OSS ist die Lernhürde zu hoch, wenn sie darin besteht die Programmiersprache und Systemarchitektur zu erlernen.
7. Besteht die Lernhürde im Erlernen einer komplexen und mächtigen Programmiersprache, wird diese von den wenigsten erklommen, statt dessen bildet sich eher ein “Zusammenschustern”, als ein Entwickeln heraus.
8. Dokumentation darf nicht durch “Community-Aktivität” verwechselt oder ersetzt werden, selbst Wikis sind diesbezüglich kritisch zu sehen.
9. OSS überwindet die Unausgeglichenheit (zugunsten der Mächtigkeit) von Mächtigkeit / Benutzerfreundlichkeit durch das herabsetzen der Lernhürde.
10. Die fehlende geordnete Managementstruktur in OSS wirkt sich positiv auf die Motivation des EUDs, kann aber die Lernhürde heraufsetzen.
11. Das breite Rollensystem von Entwicklern in OSS und die Vielzahl derer, erleichtert es OSS die Rolle des EUD zu integrieren.
Diese Thesen sind erstmal nur vorübergehende Vorschläge.