Kategorien
Open Source: Wann an die Öffentlichkeit gehen?
Punkt Nummer 1: Ich habe durchbekommen, dass das Test-Tool, das wir gerade schreiben Open-Source werden darf. Huray for me. Peinlicherweise ist das mein erstes Open Source-Projekt, an dem ich teilnehme. Also hab ich natürlich ein paar Fragen an euch. Das ist jetzt man wieder ein bisschen übertrieben, aber Fragen hab ich trotzdem.
Heute beantworten wir erst mal eine und zwar: Wann an die Öffentlichkeit gehen? Ich glaub da gibt es zwei Möglichkeiten. Möglichst früh oder möglichst spät. Was spricht für möglichst früh? Alle Leute, die Interesse haben, können teilnehmen. Schnittstellen können in der Gruppe diskutiert werden und irgendwie kann jeder glücklich gemacht werden.Nachteil ist natürlich, dass man die Leute erstmal überzeugen muss, dass die Idee gut ist. Man muss auch beweisen, dass man so ein Projekt auf die Beine stellen kann.
Was passiert wenn man spät an die Öffentlichkeit geht? Also erstmal hat man viel mehr Arbeit am Anfang. Alle Konzepte entstehen nur in einem Kopf. Vorteil ist, dass einem niemand reinquatscht und man das Tool so umsetzen kann, wie man gerade Lust hat. Später wird da schon niemand mehr was gegen haben. Das Tool funktioniert ja schließlich. Und wie heißt es so schön im Sport: Wer trifft hat Recht! Spät bedeutet auch, dass die Struktur schon klar ist und es viel einfacher für neue Entwickler ist mit Hand anzulegen. Wo Tests und Co. hinkommen ist auch klar.
Wie es nun mal fast immer ist. Die Wahrheit liegt wohl irgendwo in der Mitte. Was bedeutet das für uns? Ich werde erstmal mit einem Kollegen das Projekt bis zu einem Stand entwickeln, dass die Struktur klar erkennbar ist und die gröbsten Unit-Tests geschrieben sind. Einfache Tests, die das Tool ausführen soll, gibt es auch schon. Was bedeutet das für euch? Ihr müsst noch ein bis zwei Wochen warten und dann stelle ich LiveTest hier offiziell vor. Wer schon in einer sehr frühen Phase mitmachen will, der meldet sich bei mir und darf vielleicht ein wenig mitprogrammieren. Wer weiß?
Ach ja. Seht ihr das genau so oder gehen da die Meinungen auseinander?
Ich denke das hängt sehr davon ab wer das Tool einsetzt. Je mehr Techniker, desto früher möglich. Klarerweise sollten die Mainfeatures ersichtlich sein und lieber weniger liefern und das funktioniert als mehr und das nur halbfertig.
Vielleicht sollte man eine einfache Analogie waehlen und es mit der Geburt eines Kindes vergleichen?
Raus damit sobald es selbststaendig lebensfaehig ist, also alle zentralen „Features“ ausreichend (!) ausgebildet sind. Denn mit der Geburt beginnt der Lernprozess so richtig zu greifen. 🙂
Ich finde, das haengt auch stark davon ab, wie das Projekt nach der Veröffentlichung gemaintained werden soll. Ob es wirklich Community-getrieben weiterlaeuft, oder ob es einen zentralen Maintainer gibt, der die Community-Contribs filtert und einfließen laesst oder ablehnt. Wenn die Idee wirklich gut ist, muss man natuerlich auch immer aufpassen, dass man einen entsprechenden Reife-Grad erreicht hat, so dass nicht die Idee einfach von jemand anders mit mehr Resourcen übernommen und ein neues weiteres, besseres, kommerzielles Projekt entsteht und das eigene Kind in den Keller kommt.
Ich glaube, gerade weil es sich um ein Test-Tool handelt, ist es wichtig möglichst früh an den Start zu gehen. Es sollen möglichst viele und die unterschiedlichsten Fälle abgedeckt werden. Das kann ein kleiner Kreis meiner Meinung nach nicht alleine schaffen, da man hier primär immer von seinen eigenen Bedürfnissen ausgeht. Für ein Open Source Test Tool finde ich es wichtig, dass es von möglichst vielen Personen profitiert, die möglichst viele verschiedene Anforderungen haben, um eben einen großen Teil abdecken zu können.
Hallo,
Ich hab da mal einen netten Artikel gelesen, (find ihn leider nicht mehr, afair war er von einem google developer) über den besten Zeitpunkt mit einem OpenSource Projekt public zu gehen.
Die Grundaussage war lieber früher wie später. Wurde auch mit gründen argumentiert an die ich mich leider nicht mehr errinere, aber vielleicht hast du mehr glück den artikel zu finden 🙂
Ludwig
Release early, release often:
http://en.wikipedia.org/wiki/Release_early,_release_often
Ich denke auch möglichst früh. Klar hat man erst mal Angst was die Leute denken wenn da was nicht so toll ist. Aber wenn es erst mal in einem öffentlichen REPO ist, ein paar Docs dazugemacht und ein Release getagged ist, dann ist das Kind mal soweit das sich jemand anderes daran bereichern kann ;). Du bekommst früher Feedback etc.
Vielleicht solltest du Marketing für das OS Produkt und Sourcecode auch trennen. Sollten doch alle in das Repo schauen, du musst ja nicht gleich auf Planet PHP was veröffentlichen 😉
Im großen betrachtet, gibt es keine wirklichen Vorteile die Öffnung nach hinten zu verschieben.
Man wird sich zwar vielleicht mit nervigen Kommentaren abmühen müssen, aber das wird im Zweifelsfall sowieso nie mehr aufhören.
Und sich nach anderen zu richten ist auch bei open source keine Pflicht, was ja deutlich an der Menge an monarchisch geführten Projekten erkennbar ist.
Nun hat man hier jedoch den Sonderfall, dass es Software ist, die primär in einem Unternehmen entwickelt und eingesetzt wird.
Was vermutlich selbstverständlich sein sollte, ist also zunächst nötig alle internen Verweise usw. aus dem Source zu entfernen.
Hierbei sollte man beachten, dass man als open source dann den derzeitigen Stand veröffentlicht und nicht das gesamte vcs Repo, schließlich sind die empfindlichen Infos noch in der History vorhanden.
Damit wären wir auch bei dem nächsten Punkt, es ist nicht nur von Bedeutung wann man sich öffnet, sondern auch was für ein vcs man verwenden will.
Will man komplette Kontrolle haben und niemanden am Source rumfuschen lassen, der nicht vorher eine Genehmigung erhalten hat, so ist ein zentrales vcs wie svn sinnvoll.
Will man eine möglichst große Zahl an Mitarbeitern am Code, so nimmt man ein dezentrales vcs wie git.
Aber zurück zum Zeitpunkt. Wir haben hier nämlich einen weiteren Sonderfall. Das Projekt hat nämlich bereits eine größere Aufmerksamkeit in der Öffentlichkeit.( was für ein Zufall^^)
In diesem Fall sollte das Projekt bei der Offenlegung zumindest schon erste Grundfunktionen besitzen, die ohne großes zu tun bereits lauffähig sind.
Es sollte auch schon eine klare Verzeichnisstruktur sowie Benennungsweise erkennbar sein oder noch besser dokumentiert sein.
Und damit sich nicht alle zuerst auf den Source stürzen, sollten die genauen Spezifikationen, Ziele und ähnliches ein paar Tage vorher veröffentlicht werden, die dann auch gleich die ersten Anregungen liefern.
Und damit fließen wir auch schon wieder zu einem anderen Punkt. Wie sollen Anregungen in Zukunft gesammelt und festgehalten werden?
Je nach größe des Projekts und der Community reicht eventuell ein Issue tracker wie er bei Github vorhanden ist. Aber ab einer gewissen Größe wird das einfach unübersichtlich.
Als Unternehmen habt ihr dafür ja sicher schon eine vorhandene Infrastruktur. Es bleibt also die Frage, wollt/dürft ihr die vorhandene nutzen, kriegt ihr Hardware um die Infrastruktur selbst aufzusetzen?(Jenkins und Trac benötigen ja von sich aus schon ne größere Kiste) Oder braucht ihr mangels Ressourcen eher eine leicht gewichtigere Lösung wie http://arbitracker.org ?
Das wäre glaub ich der größte Teil an Fragen die sich so auftun.
http://test.ical.ly/2010/03/01/wann-wie-und-warum-man-etwas-open-source-machen-sollte/
Eventuell interessant
http://producingoss.com/
Meiner Meinung nach sollte man früh öffentlich werden. Man sollte ein solides Fundament schaffen, das gut dokumentiert ist und eine gute Testabdeckung aufweist. Guter Code ist wichtig, weil gute Entwickler ungerne an Gammelcode arbeiten und gute Entwickler ja die Zielgruppe sind, deren Aufmerksamkeit und Mitwirkung man schlussendlich haben möchte. Es sollte eine grobe Roadmap definiert sein, damit klar ist wo perspektivisch die Reise hin gehen soll, aber man muss sich im klaren darüber sein das viele Wege nach Rom führen. Entwickler haben unterschiedliche Methoden und Ideen, deren kleinster gemeinsamer Nenner dann schließlich implementiert wird. Speziell für die Teamarbeit in verteilten Softwareprojekten hat Atlassian tolle Webapplikationen wie Jira, Confluence und FishEye, die für Open-Source-Projekte kostenlos zur Verfügung gestellt werden und die Teamarbeit enorm erleichtern. So oder so, finde ich es klasse Software öffentlich zu machen, man weis ja nie was daraus werden kann 😉