Einleitung

Vor rund einem Jahr habe ich ein Projekt für zwei Freunde umgesetzt, die ein Startup gründen wollten. Ich programmierte ihre Webseite, komplex, aufwendig, mit vielen Stunden Arbeit und auch mit einem grossen Teil an improvisiertem Design, das sie selbst nicht mitbrachten. Am Ende war ich stolz auf das Resultat, weil es funktionierte, weil es schön aussah und weil es meine Handschrift trug.

Damals dachte ich: Für sie ist das Thema erledigt, sie haben jetzt eine Webseite. Und ich habe daraus gelernt. Doch wie ich später feststellen musste, war die Geschichte noch lange nicht vorbei.

Was passiert ist

Ich machte die beiden regelmässig darauf aufmerksam, dass sie die Seite pflegen und aktuell halten müssten, damit sie als Grundlage für ihr Geschäft funktionieren würde. Doch über Monate passierte nichts.

Als wir im Studium ein weiteres Modul hatten, in dem es wieder um Startup-Ideen ging, meldeten sie sich, relativ spät und fragten, ob ich Teil ihres Teams sein wollte. Ich hatte jedoch bereits ein Team gefunden. Also gab ich ihnen den bestehenden Code, in der Annahme, dass sie mich zumindest als Ausgangspunkt erwähnen würden.

Das Gegenteil war der Fall: Bei ihrer Präsentation stellten sie die Webseite so dar, als hätten sie diese selbst programmiert. In Wahrheit hatten sie gerade einmal ein Bild auf der Startseite ausgetauscht und ein paar Links angepasst. Der gesamte Unterbau, Vue.js, 3D-Integration, Backend mit Supabase, stammte von mir. Und doch sassen sie da und präsentierten meine Arbeit als ihre eigene. Ich die weiss wie viel Zeit und Arbeit es gekostet hat, hätte mich geschämt so was zu machen zu irgendeinem anderen Programmierer.

Wie ich damals reagierte

Und ich? Ich schwieg. Ich sagte nichts, weder während der Präsentation noch danach. Ein Teil von mir wollte ihren Pitch nicht sabotieren. Ein anderer Teil war einfach überrumpelt. Erst im Nachhinein sprach ich mit meinem Professor darüber.

Heute weiss ich: Damit tat ich mir selbst keinen Gefallen. Schweigen heisst in solchen Situationen leider auch Zustimmung.

Wie ich es hätte besser machen sollen

Rückblickend wäre es wichtig gewesen, direkt im Moment klarzustellen:

„Die technische Umsetzung stammt von mir. Die beiden haben lediglich kleine Anpassungen gemacht.“

Nicht angriffig, nicht beleidigend, sondern einfach sachlich.

Studien zeigen: Menschen nehmen Attribution sehr ernst. In der Wissenschaft spricht man von akademischer Redlichkeit, jede Form von Plagiat oder falscher Zuschreibung untergräbt Vertrauen (Bretag, 2016). Auch in der Softwareentwicklung ist Credit Attribution zentral. In Open-Source-Projekten gilt es fast schon als „unwritten law“, dass man die ursprünglichen Entwickler:innen nennt, selbst wenn man etwas verändert oder weiterentwickelt (Fogel, 2017).

Meine Entscheidung, den Code einfach so weiterzugeben, war aus heutiger Sicht naiv. Ohne klare Vereinbarungen, etwa zu Copyright, Mitautorenschaft oder Nutzungslizenzen, begibt man sich schnell in eine schwache Position (Lessig, 2008).

Was ich daraus gelernt habe

  • Klare Grenzen setzen: Projekte, in die man viel Zeit investiert, brauchen Regeln – schriftlich festgehalten.
  • Für sich selbst einstehen: Wenn jemand die eigene Arbeit beansprucht, ist es legitim und notwendig, das klarzustellen.
  • Nein sagen: Ich werde mit diesen Personen nicht mehr zusammenarbeiten. Vertrauen ist die Basis jeder Kooperation. Ist das einmal gebrochen, lohnt es sich nicht, noch mehr Energie hineinzustecken.
  • Fokus auf die eigenen Projekte: Statt mich auszubeuten, möchte ich meine Energie in Dinge stecken, die wirklich mir gehören.

Fazit

Es fällt mir nicht leicht, über diese Erfahrung zu schreiben. Aber sie hat mir eines gezeigt: Arbeit ist nicht nur Zeit, sie ist auch Identität. Wenn jemand meine Arbeit als seine eigene ausgibt, dann geht es nicht nur um Code, es geht um Respekt.

Heute würde ich sofort reagieren, wenn so etwas wieder passiert. Ich würde sachlich, aber bestimmt aufzeigen, wo die Arbeit herkommt. Und ich weiss: Das hat nichts mit Kleinlichkeit zu tun, sondern mit Fairness.

Literatur

  • Bretag, T. (2016). Defining and promoting academic integrity: Global perspectives. Academic Integrity, 11(1), 1–12.
  • Fogel, K. (2017). Producing Open Source Software: How to Run a Successful Free Software Project. O’Reilly Media.
  • Lessig, L. (2008). Remix: Making Art and Commerce Thrive in the Hybrid Economy. Penguin Press.