Tipps Für Open Source Projekte
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Startpunkte für diese Seite sind die Ratschläge des Buches OpenSourceProjekteMitCVS (mit allen Unsicherheitsvorbehalten, die der Autor Karl Fogel für ein so frisches Gebiet einräumt):
- Jedes OS-Programm braucht für ein längerfristiges Überleben eine Gruppe von engagierten Benutzern, die mit dem Programm einen Teil ihrer Arbeit erledigen können. Ohne eine solche Gemeinschaft wird das Projekt zu einem Fehlschlag (nicht offiziell und mit Getöse, aber es schläft ein und nur mehr der Autor verwendet die Software).
Wichtig für ein erfolgreiches OS Projekt:
- Es nicht zu machen, wenn auch eine Beteiligung an einem ähnlichen, adequaten Projekt möglich ist
- Recherche
- (eventuell ist die Wiederaufnahme oder "Übernahme" eines stagnierenden Projektes sinnvoll)
- Es soll schon am Beginn einige Funktionen haben und zumindest ein konkretes Problem lösen, das derzeit ungelöst ist.
- (ferne Visionen sind zu wenig).
- die Motivation für andere Benutzer und Entwickler, sich zu beteiligen
- Es soll zuverlässiger Code vorhanden sein.
- "...am Anfang, am Ende, immer..."
- (vermutlich wäre eine TestSuite - selten vorhanden - nützlich)
- Das richtige Timing.
- Zu früh veröffentlicht enttäuscht es die Interessenten.
- Zu spät veröffentlicht verschenkt es Marktanteile in der Entwicklergemeinde.
- Die Verpackung darf nicht vernachlässigt werden
- Homepage
- Die Lizenz (keine eigenen Formulierungen)
- Die klar sichtbaren Ziele
- Die grundlegende Dokumentation
- Wie kann man zum Projekt beitragen
- Eine SiteMap? zu allen Resourcen
- ProgrammierStandards
- Dokumentation
- vorzugsweise in einfacher Form: Text oder HTML.
- Nur optional PS, PDF oder RTF.
- Keine Dokumentation, die spezielle Viewer benötigt.
- Infrastruktur für die Kommunikation (am einfachsten: OpenSourceHosts)
- für die Entwicklerkommunikation (e-mail, MailingListe, WebForum, WikiWeb, ...)
- für die Code-Patches (CVS, e-mail, ...)
- für Bug-Reports (Tools, e-mail, ...)
- Der Betreuer
- mit natürlicher Authorität nicht aus Besitzanspruch sondern aus Verdiensten um das Programm.
- der weiß wann er "ja" sagen kann und "nein" sagen muss
- mit Überblick, um die Nützlichkeit des Programmes für die Benutzer zu maximieren
- mit Fingerspitzengefühl, um die Teilnehmer nicht unnötig zu verärgern
- Die Werbung
- Ankündigung des Projektes
- Laufende Informationen zu den Neuerungen und Fortschritten
- FreshMeat?, Communities
- Es soll ein stetiger Projektfortschritt sichtbar sein.
- (trivial, aber wichtig: Es muss von Anfang an eine klare Versionsnummerierung geben)
Siehe auch OpenSourceUndXp
KategorieOpenSource
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 11. Mai 2002 9:45 (diff))