Open Source Projekt gruenden

[Kay]

Moin Forum,

ich beabsichtige an meiner FH ein laengerfristiges OpenSource-Projekt zu gruenden, um Studenten die Idee und den Workflow von OpenSource naeher zu bringen. Was Bestandteil des Projektes/der Software sein wird, wird spaeter gemeinsam abgestimmt.

Hat jemand Literaturempfehlungen oder Links, die sich mit Gruendung und Projektmanagement von OpenSource-Projekten beschaeftigen, damit der Start ein wenig leichter von der Hand faellt?

Gruss,
Kay

[Sven Rautenberg]

Moin!

ich beabsichtige an meiner FH ein laengerfristiges OpenSource-Projekt zu gruenden, um Studenten die Idee und den Workflow von OpenSource naeher zu bringen. Was Bestandteil des Projektes/der Software sein wird, wird spaeter gemeinsam abgestimmt.

Ich will dein Engagement ja nicht gleich wieder total zerstören, aber ich glaube, Open Source Software entsteht aus anderen Gründen.

In den allermeisten Fällen, bei denen am Ende OS rauskommt, hat jemand, der in der Lage ist, zu programmieren, ein Computerproblem, welches er mit der vorhandenen Software nicht lösen kann. Deshalb schreibt er sich seine Software selbst. Und nur weil er vermutet oder von anderen darauf hingewiesen wird, dass die Software auch für andere nützlich sein könnte, veröffentlicht er sie, und je nach Bedarf des Marktes wird sie dann von mehr oder weniger Leuten dankbar eingesetzt - und unter Umständen eben auch verbessert. Beispiele: Jemand brauchte einen Webserver -> Apache. Jemand brauchte einen Browser -> Firefox. Jemand brauchte ein Officepaket -> OpenOffice.org. Jemand brauchte eine dateiauswertende Programmiersprache -> Perl. Jemand brauchte ein programmierbares Templatesystem für Webseiten -> PHP.

Dein Ansatz hingegen ist: "Wir gründen eine Programmierergruppe und gucken mal, was man so programmieren kann." So funktionieren auch privatwirtschaftliche Softwarefirmen, möchte ich meinen (nur fragen die nicht, was ihre Programmierer gern coden würden, sondern womit sich am meisten Geld verdienen läßt).

• Sven Rautenberg

[Ludger]

Hi,

schoene Analyse.

Die Erstellung von Software erfolgt natuerlich nie grundlos.

Gruss,
Ludger

[christopher]

Beispiele: Jemand brauchte einen Webserver -> Apache. Jemand brauchte einen Browser -> Firefox. Jemand brauchte ein Officepaket -> OpenOffice.org. Jemand brauchte eine dateiauswertende Programmiersprache -> Perl. Jemand brauchte ein programmierbares Templatesystem für Webseiten -> PHP.

Die Beispiele sind mir nicht ganz einleuchtend: bensonders OpenOffice nicht. Da hat sich doch nicht irgendwer hingesetzt und gedacht:"Ach, ich bräuchte mal ein komplettes Office-Paket".
Soviel ich weiss, ist da vorhandener Quellcode geöffnet worden. Genauso beim Apache, der ja auch ursprünglich nicht OS war.

[Kay]

Moin!

In den allermeisten Fällen, bei denen am Ende OS rauskommt, hat jemand, der in der Lage ist, zu programmieren, ein Computerproblem, welches er mit der vorhandenen Software nicht lösen kann. Deshalb schreibt er sich seine Software selbst. Und nur weil er vermutet oder von anderen darauf hingewiesen wird, dass die Software auch für andere nützlich sein könnte, veröffentlicht er sie, und je nach Bedarf des Marktes wird sie dann von mehr oder weniger Leuten dankbar eingesetzt - und unter Umständen eben auch verbessert. Beispiele: Jemand brauchte einen Webserver -> Apache. Jemand brauchte einen Browser -> Firefox. Jemand brauchte ein Officepaket -> OpenOffice.org. Jemand brauchte eine dateiauswertende Programmiersprache -> Perl. Jemand brauchte ein programmierbares Templatesystem für Webseiten -> PHP.

Nun ja,  Sun oeffnete damals den Quellcode von Staroffice und so entstand OO. Die Idee von OS ist mir schon bewusst. Das was Du geschrieben hast, kann ich vollkommen unterstreichen!

Dein Ansatz hingegen ist: "Wir gründen eine Programmierergruppe und gucken mal, was man so programmieren kann." So funktionieren auch privatwirtschaftliche Softwarefirmen, möchte ich meinen (nur fragen die nicht, was ihre Programmierer gern coden würden, sondern womit sich am meisten Geld verdienen läßt).

Wenn ich Dich recht verstehe, siehst Du einen Unterschied zwischen "Wir gruenden eine Programmiergruppe und gucken mal, was man so programmieren kann" und "Wir schreiben ein Computerprogramm fuer ein Problem, welches mit vorhandener Software nicht geloest werden kann"?

Ich denke nicht, dass dort ein gravierender Unterschied besteht, zumal die Gruppe durchaus Vorschlaege fuer ungeloeste Probleme macht. Nocheinmal: Die Idee hinter der Idee ist, dass Wirtschaftsinformatiker (die durchaus programmieren koennen und wollen) zusammenarbeiten und a) mit OS vertraut gemacht werden b) Projektmanagement in der Praxis "kennenlernen" c) Spass an der Sache haben (Reihenfolge mal alphabetischer Reihenfolge).

Gruss,
Kay

BTW: Eine Antwort auf die Frage im Ausgangsposting ist natuerlich immernoch willkommen ;)

[Sven Rautenberg]

Moin!

Wenn ich Dich recht verstehe, siehst Du einen Unterschied zwischen "Wir gruenden eine Programmiergruppe und gucken mal, was man so programmieren kann" und "Wir schreiben ein Computerprogramm fuer ein Problem, welches mit vorhandener Software nicht geloest werden kann"?

Richtig. Im ersten Fall sucht der Programmierer ein Problem, im zweiten Fall sucht das Problem den Programmierer (heim ;) ).

Warum gibt es wohl Abermillionen von ASCII-Texteditoren? Weil jeder etwas fortgeschrittene, aber "problemlose" Programmierer sich denkt, er könne doch mal den besten und für seine Belange idealen Editor schreiben. Heraus kommt dann erstmal ein 08/15-Editor mit noch weniger Features, als der Windows-Notepad in Win95 hatte.

Ich denke nicht, dass dort ein gravierender Unterschied besteht, zumal die Gruppe durchaus Vorschlaege fuer ungeloeste Probleme macht. Nocheinmal: Die Idee hinter der Idee ist, dass Wirtschaftsinformatiker (die durchaus programmieren koennen und wollen) zusammenarbeiten und a) mit OS vertraut gemacht werden b) Projektmanagement in der Praxis "kennenlernen" c) Spass an der Sache haben (Reihenfolge mal alphabetischer Reihenfolge).

Ich glaube, der Ansatz ist falsch. Zuerst hat man ein Problem. Ob man es gefunden hat, oder es einen, sei dahingestellt. Dann wird dieses Problem durch ein Programm gelöst. In dieser Phase ist die Gruppenzusammenarbeit wichtig. Und wenn am Ende (wobei: Software ist niemals fertig...) eine erste funktionierende Version besteht, geht es darum, sie zu veröffentlichen. Und erst dann kommt die Frage nach "Open Source" und eine passende Lizenz überhaupt ins Spiel. Sie betrifft den Entwicklungsprozess aber nicht, denn alle beteiligten Programmierer haben ja den kompletten Einblick in den Source. Es ist also vollkommen egal, unter welcher Lizenz das Programmprojekt steht.

Der einzige Unterschied, den ich mir vorstellen kann, zwischen der lokalen Entwicklergruppe und "echter" Open-Source-Entwicklung ist die virtuelle Zusammenarbeit. Es ist eben ein extremer Unterschied, ob man sich im realen Leben bei Bedarf spontan oder geplant ohne großen Aufwand treffen und abstimmen kann, oder ob man aus Kostengründen auf elektronische Kommunikation angewiesen ist. Aber genau dieser Aspekt wird sich, so wie ich anhand der Informationen die Lage beurteilen kann, schwierig simulieren lassen, weil es unmöglich zu verhindern sein wird, dass die Teilnehmer sich doch im realen Leben treffen und auch über das Projekt reden.

Dabei halte ich diesen Punkt für den entscheidendsten. Denn erst wenn das Projekt tatsächlich echt released OS ist, also die Arbeiten an einer ersten Version hinreichend weit gediehen sind und deswegen Mitarbeiter in der Welt interessiert haben, daran teilzunehmen, wird die Lage ernst - und lehrreich. Denn irgendwo muß die Projektkoordination liegen, es muß einen irgendwie geregelten Austausch geben, definierte Regularien etc. - und all das virtuell abgestimmt. Mit solchen Arbeitsprozessen kann sich nicht unbedingt jeder identifizieren.

• Sven Rautenberg

[Thomas W.]

Hallo,

Und erst dann kommt die Frage nach "Open Source" und eine passende Lizenz überhaupt ins Spiel. Sie betrifft den Entwicklungsprozess aber nicht, denn alle beteiligten Programmierer haben ja den kompletten Einblick in den Source. Es ist also vollkommen egal, unter welcher Lizenz das Programmprojekt steht.

Waehrend ich Dir bei Deinen uebrigen Aeusserungen zustimme, bin ich hier anderer Ansicht. Es duerfte deutlich einfacher sein, sich auf eine Lizenz zu einigen, wenn man noch nicht viele Mannstunden reingesteckt hat. Allerdings ist es wohl auch ungewoehnlich, ein Projekt mit mehreren Leuten zu beginnen.

Gruss
Thomas

[Frank (no reg)]

Hi,

so ungewöhnlich sollte es wirklich nicht sein, mit mehreren Personen ein Projekt zu starten. Woher nimmst du diese Ansicht?

In meinen Projekten gibt es (seit einiger Zeit immer) eine klare Rollen und Kompetenzverteilung:

• Commercial Project Steering
• Technical Project Steering
• Business Case Analyst
• System Designer
• Developer
• Build Manager & QA Manager

... wobei die ersten 4 + der letzte von Anfang an dabei sind

Nicht dass dies gleich ein professionelles Projekt ausmacht aber alle diese Aufgaben in einer Person zu bündeln und froh ins Blaue hinein zu entwickeln, endet aus Erfahrung immer in Frickelsoftware ;-) Da ist es egal, ob man später auf dieser "coolen" OpenSource Welle mitschwimmt oder "böse" kommerziell wird.

Wozu soll es gut sein, sich am Anfang auf eine Lizenz zu einigen, wenn man noch nicht mal absehen kann, ob und wann etwas brauchbares rauskommt? Besser erstmal schön geradeausdenken, anstatt "überholen ohne einzuholen", sonst wird es, du weißt schon: Frickelsoftware.

Gut Nacht, Frank

[Anonymous]

• Commercial Project Steering
• Technical Project Steering
• Business Case Analyst
• System Designer
• Developer
• Build Manager & QA Manager

Spielen wir hier Bullshit-Bingo?

[Frank (no reg)]

In deinem Beispiel habe ich nicht einen meiner Begriffe wiedergefunden ... wenn du kein Englisch verstehst, ist dies dein Problem. In einem englischsprachigen Berufsumfeld werden die Rollen nun mal auch auf englisch benannt.

Wie auch immer, du machst nicht gerade einen diskussionswürdigen Eindruck.

Ciao, Frank

[Johannes Zeller]

Hallo Frank,

In deinem Beispiel habe ich nicht einen meiner Begriffe wiedergefunden ... wenn du kein Englisch verstehst, ist dies dein Problem. In einem englischsprachigen Berufsumfeld werden die Rollen nun mal auch auf englisch benannt.

Dann erläutere doch mal ein bisschen näher die Aufgaben der entsprechenden Personen. So kann man sich jedenfalls nichts darunter vorstellen...

Schöne Grüße,

Johannes

[Frank (no reg)]

Hi,

für dich gern.

• Commercial Project Steering

• übernimmt wirtschaftliche Verantwortung
• ermittelt Resourcenbedarf und koordiniert Resourcenbeschaffung
• Mitarbeit im CCB (Change Control Board - Einsteuerung von Änderungen)
• kontrolliert den Projektablauf aus wirtschaftlicher Sicht

• Technical Project Steering

• das fachliche Pendant zu obiger Rolle
• kennt fachliche Internas und ist Entscheider für technische Fragen (Offene Punkte, Änderungsanforderungen etc)
• übernimmt die Aufgabenverteilung für die Resourcen
• kontrolliert Projektablauf aus fachlicher Sicht, werden gesetzte Ziele eingehalten, gibt es Leerlauf bzw. verhindert diesen´

• Business Case Analyst

• einer der in der fachlichen Materie, nicht "Softwareentwicklung", sondern in dem was evt. über ein Tool abgebildet werden soll solides Wissen hat, ergo Anwendungswissen einbringt, er betrachtet die "Lösung" aus Sicht des Benutzers
• erstellt Anforderungsspezifikationen (Use Cases etc)

• System Designer

• erarbeitet aus den Anforderungen dann das Konzept, die "logische" Sicht auf die Dinge, z.b. wird 3-Tier oder Client/Server verwendet, etc
• eruiert die Verwendung von Entwicklungstools und Basissystemen (welches DBMS eignet sich am besten)
• validiert vorgeschlagene Mechanismen  (proof-of-concept)
• erstellt mit der Projektführung den Release-Plan, definiert Arbeitspakete
• Review von Dokumentation und Code
• zentraler Ansprechpartner in Bezug auf Design und Implementierung für alle anderen

• Developer

• der reine Entwickler, ausgewählt nach Fähigkeiten, betraut mit definierten Aufgaben
• implementiert gemäß existierenden Spezifikationen

• Build Manager & QA Manager

• definiert den Qualitäts-Sicherungs-Plan, was für Tests, wann und wie (manuell oder automatisch: z.b. jUnit/nUnit), welche Voraussetzungen müssen für Code Releases erfüllt sein ... usw
• definiert und evaluiert Sicherheitsanforderungen (nicht unbedingt allein)
• beurteilt die Qualität des Codes in Bezug auf Release-Fähigkeit
• erarbeitet Testspezifikation aus Anforderungen und Use-Case Modellierungen
• führt Tests durch (fängt beim erfolgreichen kompilieren an und hört beim erfolgreichen Benutzen nicht auf :-))
• betreut CVS / IssueTracking System

Warum kannst/konntest du dir nichts drunter vorstellen? (Okay, der Blick auf deine HP sagt mir, dass du das Wissen noch nicht wirklich haben kannst)

• QA ist allgemeinhin bekannt als Quality Assurance, Qualitätssicherung
• Commercial -> kommerziell -> wirtschaftlich
• Steering -> Steuerung
• Build -> ist eigentlich auch ein eingefahrener Begriff in der SW Entwicklung für das Ergebnis einer Kompilierung

Für kleinere Projekte wie ne Homepage für ne Tischlerei ist das sicher zu oversized, aber sobald es darum geht, einen bestimmten Workflow in einem Unternehmen als Tool abzubilden und das Projekt nicht wie jedes 2. gegen die Wand laufen zu lassen, wirst du um solch eine strikte Rollenverteilung schwer herumkommen.

Und merke, es gibt immer 3 Sichten auf eine Lösung: Aus der Benutzerperspektive, logisch und technisch. :-)

Ciao, Frank

[Johannes Zeller]

Hallo Frank,

für dich gern.

Danke sehr ;-)

Warum kannst/konntest du dir nichts drunter vorstellen?

Weil ich mich noch nicht in dem Ausmaße damit befasst habe, wie man ein größeres Software-Projekte leitet.

• QA ist allgemeinhin bekannt als Quality Assurance, Qualitätssicherung
• Commercial -> kommerziell -> wirtschaftlich
• Steering -> Steuerung
• Build -> ist eigentlich auch ein eingefahrener Begriff in der SW Entwicklung für das Ergebnis einer Kompilierung

Natürlich lassen die Bezeichnungen einiges erahnen. Was genau jedoch die Rollen der einzelnen Personen sind, kann man ohne entsprechendes Hintergrundwissen zu haben nicht kennen. Und in diesem Forum lesen und posten ja nicht nur professionelle Softwareentwickler.

Schöne Grüße,

Johannes

[Frank (no reg)]

Hi Johannes,

deswegen hab ich dir es auch gern erläutert, weil ich es nach dem Kurzbesuch auf deiner HP sehen konnte, aber da hatte ich das Posting schon fast zuende geschrieben...  ich musste mir diese "Weisheiten" auch erst mühsam erarbeiten

Aber ich hoffe, du konntest mit der Beschreibung der Verantwortlichkeiten (auch wenn da immer noch viel Denglisch drin war) etwas mehr anfangen.

Ciao, schönen Pfingstmontag morgen,
Frank

[Daniela Koller]

Hi Frank

Das sind nur gerade die aktuellen Modebegriffe in deinem Umfeld. Auf normal ist das nichts anderes als:

• Business Projektleiter
• Technischer Projektleiter
• Spezialist aus der Fachabteilung
• Softwarearchitekt
• Entwickler (erstellen üblicherweise auch das Paket für die     Auslieferung)
• Test- / Abnahmeverantwortlicher

Von daher stimm ich Anonymous zu, Bullshitbingo in seiner reinsten Form.

Nicht dass dies gleich ein professionelles Projekt ausmacht aber alle diese Aufgaben in einer Person zu bündeln und froh ins Blaue hinein zu entwickeln, endet aus Erfahrung immer in Frickelsoftware ;-) Da ist es egal, ob man später auf dieser "coolen" OpenSource Welle mitschwimmt oder "böse" kommerziell wird.

Nein, bei Kleinstprojekten können die sehr gut auf eine Person zusammengefasst sein. Wenn ich für mich irgend ein GUI entwickle, bestimme ich, was ich will (Qualifiziert, weil ich weis, wie es für _mich_ am besten ist und ich der Zielanwender bin), ich bestimme, wie ich das implementiere (kann ich auch da ich doch inzwischen viel Erfahrung habe) und wann ich damit zufrieden bin, bestimmt auch ich da ich der Anwender bin.

Bei Projekten für einen grösseren Anwenderkreis ist es sinnvoll, diese Rollen auf wenigstens 2 Leute zu verteilen.

1. Definiert was gemacht werden soll. Testet zum Schluss, ob
      es das ist, was er wollte und es funktioniert, wie er es
      wollte.
2. Erstellt das Produkt.

Je grösser das Projekt, desto mehr Leute werden es dann natürlich die auf die entsprechenden Rollen verteilt werden, üblich ist aber, dass der Business-Projektleiter dem Team aus Anwendern und Fachspezialisten vorsteht und der technischer Projektleiter dem Team aus Softwareentwicklern und Architekten. Qualitätssicherung wird üblicherweise auf 3 Parteien verteilt, die Fachleute, ob es das ist, was sie wollten, die Techniker, ob es funktioniert und die Abnahmetestleute ob es sich mit der Umgebung verträgt und ob alle anderen ihre Tests ordentlich gemacht haben.

Wozu soll es gut sein, sich am Anfang auf eine Lizenz zu einigen, wenn man noch nicht mal absehen kann, ob und wann etwas brauchbares rauskommt?

Um Streit zu vermeiden, wenn etwas gutes raus kommt. Um sicherzustellen, dass die Beteiligten das gleiche Ziel haben. Was machst du sonst, wenn einer deiner Beteiligten damit Geld verdienen will, ein anderer aber nicht zustimmt, dass seine Arbeit für Geld verkauft wird weil er sie gerne frei zur Verfügung stellen will?

Gruss Daniela

[Frank (no reg)]

Hi Daniela,

versuche die von dir genannten deutschen Rollen doch bitte mal fachkorrekt ins Englische zu übersetzen. Ich bezweifle nicht, dass du das kannst. Aber du wirst sicherlich sah nah an meinen Formulierungen landen. Was ist dann daran noch Bullshitbingo? In dem von diesem "anonymen Heinz" (Anonymous) gegebenem Beispiel hättest du keine 5 Felder vollbekommen. Also war deine Plautzerei noch müßiger als umsonst...

Nein, bei Kleinstprojekten ....

Mich deucht, dass ich weiter unten ähnliches gesagt habe, außerdem habe ich bereits eingeräumt, dass mein Modell nicht das Allheilmittel für jede Art von Projekt sein muss. Oder war dies nicht deutlich genug.

Bei Projekten für einen grösseren Anwenderkreis ist es sinnvoll, diese Rollen auf wenigstens 2 Leute zu verteilen.

Was ist ein größerer Anwenderkreis? Die Masse der Internetsurfer, die die Website besuchen soll, die Abteilung, die die Pflege der Website betreiben soll, .... es ist alles relativ zu betrachten. Sicher kann man Aufgaben in Abhängigkeit vom Projekt in einzelnen Personen bündeln, das stell ich ja auch gar nicht außer Frage (nicht immer hat man die Mittel um entsprechend viele Resourcen zu erzeugen). Was ich in Frage stellte, war die Aussage, dass es "wohl auch ungewoehnlich" wäre, Projekte mit mehreren Personen zu beginnen.

In Sachen der Lizenzfrage, was warum wie wer und wann, magst du deinen Punkt haben, da gehen die Meinungen sicherlich subjektiv begründet stark auseinander.

Aber warum nicht eine kollektive Entscheidung (wozu haben wir denn Demokratie) wenn denn mal was wirklich brauchbares da ist, anstatt von nur heißer Luft? Wer entsprechend Einsatz gezeigt hat, soll auch seine Meinung haben. Aber wer ist noch so idealistisch, dass er nicht sein ausgelöstes Gehirnschmalz entlohnt sehen möchte? Persönlich finde ich, dass die Motivationskurve der gesamten Gruppe (sofern man denn eine kleine Programmiergruppe gebildet hat) steil nach unten geht, wenn man Einsatz für lau bringen soll, nur weil es die Ideale einiger weniger verlangen. Wie gesagt, hängt von der Betrachtungsweise ab. Und über Subjektivitäten streiten zu wollen, bringt uns sicher nicht weiter.

Ciao, Frank

[Frank (no reg)]

Hi,

nennt es doch einfach "Programmierzirkel" oder "Programmierstammtisch" ohne euch gleich mit der Zierde von "OpenSource" schmücken zu wollen, dann seid ihr aber/zwar vielleicht nicht so "cool" und "trendy" gegenüber euren Mitstudis.

Es kommt deswegen aber nicht mehr oder minder Frickelsoftware[tm] heraus. *SCNR*

Also bleibt auf dem Boden.

Ciao, Frank

[Thomas J.S.]

Hallo,

Wenn ich Dich recht verstehe, siehst Du einen Unterschied zwischen "Wir gruenden eine Programmiergruppe und gucken mal, was man so programmieren kann" und "Wir schreiben ein Computerprogramm fuer ein Problem, welches mit vorhandener Software nicht geloest werden kann"?

Ich denke nicht, dass dort ein gravierender Unterschied besteht,

Der Unterschied ist recht gravierend.
Nehme uns hier.  z.B. die Forumssoftware: erst gab es Matt Wright's Forum. Dann war sie für die unsere Anforderungen unzureichend geworden und es entstand eine eigene Forumssoftware. Irgendwann war sie auch nicht mehr so wie wir es uns vorstellten und es wurde eine neue Software entwickelt. Erst nur für unsere Foren, dann hat Christian sie weiterentwicklet und daraus ein eigen Software das "Classic Forum" entwickelt und diese setzen wir nun auch ein.

Also es war erst der Bedarf da, dann das Programmieren. "Aberwitzinge" Weise also nicht wie heute - wie Sven es schon sagte - oft der Fall ist,  erst "wir Programmieren" und dann "brigen wir die Software an den Mann".

Ansonsten empfehle ich dir die Seiten von http://berlios.de/ bzw. http://www.berlios.de/index.php.de

Grüße
Thomas

[Tim Tepaße]

Hallo Sven,

ändert zwar nix an Deiner Argumentation, nur der Vollständigkeit halber. ;)

Jemand brauchte einen Webserver -> Apache.

Das National Center for Supercomputing Applications programmierte aus irgendwelchen Gründen den Webserver NCSA httpd → Leute sammelten Patche, um ihn zu verbessern/zu erweitern → „a patchy server“ → Apache httpd

Jemand brauchte einen Browser -> Firefox.

Netscape gibt den Quellcode für Netscape 5 frei (weil: Open Source Hype & kein wirtschaftlicher Grund, ihn als Closed Source zu entwickeln, will aber auch nicht von der Bildschirmfläche verschwinden) → Mozilla wird darauf ausgehend größtenteils neu entwickelt → Mozilla erbt die Netscape-übliche überfrachtete Nutzeroberfläche und wird von nicht auf Usability achtenden Leuten weiter in diese Richtung getrieben → Dave Hyatt denkt: „Hey, Mozilla wäre vielleicht populärer, wenn er sich auf die Kernkompetenz, das Browsen, konzentriert“ → Phoenix → Firefox

Jemand brauchte ein Officepaket -> OpenOffice.org.

Irgendein Wunderknabe aus Norddeutschland will Geld verdienen, gründet StarDivision und bringt StarOffice als Kaufsoftware raus → Er will noch mehr Geld und verkauft an Sun → Sun will auf der OS-Welle mitschwimmen und Entwicklerkosten reduzieren → OpenOffice

Ok, Deine Variante ist knackiger. ;)

Tim