Der Forge und der Handel: Wie VA Software Open-Source-Workflows in eine Kontrollfläche verwandelte – und dann die Stücke verkaufte

Zusammenfassung

• VA Software kontrollierte mehr als einen Code-Host. SourceForge.net kombinierte Projektidentität, Auffindbarkeit, Repositories, Issue-Tracking, Mailinglisten, Releases, Download-Statistiken und ein einflussreiches technisches Publikum, was dem Betreiber eine ungewöhnlich breite Macht darüber verlieh, wie Open-Source-Arbeit gefunden und koordiniert wurde.
• Das Unternehmen wandelte die gewonnenen Erkenntnisse und Glaubwürdigkeit aus diesem öffentlichen Dienst in SourceForge Enterprise Edition um, ein separates proprietäres Produkt für Organisationen, die Entwicklungsaktivitäten hinter der Firewall wünschten, verbunden mit Unternehmensidentität, Reporting und bestehenden Source-Control-Tools.
• Die beiden Seiten hatten unterschiedliche Wirtschaftlichkeiten. Die gehostete Community erzeugte Aufmerksamkeit, die an Werbetreibende verkauft werden konnte, während die Unternehmenseinnahmen von langen Verkaufszyklen, Installation, Integration, Wartung und Support abhingen. Die eingereichten Ergebnisse zeigen steigende Softwareeinnahmen, aber anhaltende Betriebsverluste im Softwarebereich vor dem Verkauf des Geschäfts.
• Der Verkauf im Jahr 2007 zog die entscheidende Grenze: CollabNet übernahm das Enterprise-Produkt, das geistige Eigentum und einen Großteil des Arbeitsteams, während SourceForge.net und das Medienpublikum bei dem Unternehmen blieben, das sich in SourceForge, Inc. umbenannte. Kunden und Maintainer erbten daher unterschiedliche Nachfolger.
• Die bleibende Lektion ist eine der Governance. Ein kostenloser Kollaborationsdienst kann zu kritischer Infrastruktur werden, bevor seine Nutzer Portabilität, Change-of-Control-Schutz oder die Anreize des Betreibers getestet haben; ein On-Premises-Produkt kann die Hosting-Abhängigkeit verringern, schafft aber eine andere Abhängigkeit von proprietären Workflows, Integrationen und Support.

Ein Wort, zwei Kontrollflächen

Am 24. April 2007 hörte „SourceForge“ auf, eine nützliche Antwort auf die Frage zu sein, was VA Software besaß. Das Unternehmen kündigte an, dass CollabNet sein SourceForge Enterprise Edition-Geschäft übernehmen würde, einschließlich des relevanten geistigen Eigentums und der Vermögenswerte, und Stellen für Mitglieder seiner Entwicklungs-, Support-, Vertriebs- und Feldservice-Teams anbieten würde. Dennoch ließ die Transaktion SourceForge.net – den öffentlichen Projekt-Hosting-Dienst – ausdrücklich bei VA Software. Ein zeitgenössischer Bericht beschrieb den Ausschluss deutlich: Die öffentliche Seite wurde nicht von dem verkauften Enterprise-Produkt betrieben. Eine einzige Marke hatte zwei Systeme, zwei Benutzergruppen und zwei verschiedene Machtquellen verborgen. Der Verkauf machte die Naht sichtbar.Die bei der SEC eingereichte Ankündigung des Unternehmensunddie zeitgenössische Berichterstattung über den Ausschlussbelegen diese Unterscheidung.

Diese Naht ist auch der Schlüssel zur Identifizierung von VA Software selbst. Dies war nicht einfach ein lockerer Begriff für jedes Unternehmen, das später SourceForge nutzte, noch war es der aktuelle Betreiber der SourceForge-Website. Das Unternehmen begann als VA Research und wurde für Linux-Hardware bekannt. Im Jahr 2001, nachdem es das Hardwaregeschäft aufgegeben hatte, bat der Vorstand die Aktionäre, den Namen VA Software Corporation zu genehmigen. Der Grund, der in derProxy-Erklärung des Unternehmensangegeben wurde, war ungewöhnlich direkt: Die Entwicklung, Vermarktung, der Verkauf und der Support von SourceForge-Kollaborationssoftware waren zu seinem Hauptgeschäft geworden, während „VA Linux Systems“ immer noch Hardware suggerierte. Die Aktionäre genehmigten die Änderung im Dezember 2001. Die hier untersuchte Identität ist daher historisch begrenzt: VA Software nach diesem Übergang und vor der Änderung zu SourceForge, Inc. im Mai 2007.

Die Grenzen sind wichtig, weil die Vermögenswerte in verschiedene Richtungen gingen. Das Enterprise-Produkt und seine Kundenverpflichtungen gingen an CollabNet. Die öffentliche Website, das Werbepublikum rund um die technischen Medienangebote und der ThinkGeek-Handelsbetrieb blieben bei der ursprünglichen Körperschaft. Diese Körperschaft übernahm dann den SourceForge-Namen und wurde 2009 zu Geeknet. Die öffentliche Website selbst wurde in späteren Jahren erneut verkauft.

Alle diese Perioden als ein kontinuierliches Unternehmen zu behandeln, würde Entscheidungen dem falschen Eigentümer zuschreiben; SourceForge.net und SourceForge Enterprise Edition als dieselbe Software zu behandeln, würde falsch verstehen, was Käufer kauften.

Innerhalb der begrenzten VA Software-Periode waren die beiden Oberflächen jedoch strategisch verbunden. SourceForge.net war die öffentliche Werkstatt: ein gehosteter Ort, an dem Maintainer Projekte organisieren und Nutzer sie entdecken und herunterladen konnten. SourceForge Enterprise Edition war der private Kontrollraum: Software, die an Unternehmen und öffentliche Einrichtungen verkauft wurde, die eine vergleichbare Koordination innerhalb ihres eigenen Sicherheitsperimeters wünschten. Die öffentliche Website lieferte den Beweis, dass ein browserbasierter Kollaborationshub in erheblichem Umfang funktionieren konnte.

Sie lieferte auch einen berühmten Namen und Kontakt mit der Praxis der Entwickler. Das Enterprise-System verwandelte diese Beobachtungen in bezahlte Governance – Berechtigungen, Berichte, Integrationen, Support und eine zentral verwaltete Arbeitsaufzeichnung.

Dies war ein kluger Handel, aber kein stabiler. Öffentliche Maintainer schätzten Autonomie, freien Zugang und die Möglichkeit, ihre Werkzeuge zu inspizieren oder zu reproduzieren. Unternehmenskäufer zahlten genau dafür, dass ein Anbieter diese Werkzeuge standardisieren, den Zugang einschränken und eine Supportverpflichtung übernehmen konnte. Medienökonomie belohnte Publikumswachstum und Seitenaufrufe; Unternehmensökonomie belohnte weniger, größere Konten und geduldige Implementierung. VA Software kontrollierte beide Oberflächen eine Zeit lang, aber sie machte ihre Anreize nie identisch.

Die freie Schmiede war ein Bündel von Machtbefugnissen

SourceForge.net wird oft als Repository-Host in Erinnerung gerufen. Diese Beschreibung ist zu eng. Beim Start Anfang 2000 bot der Dienst Projekt-Webspace, Quellcodeverwaltung, Kommunikation und Zugriffskontrollen über einen Browser. Einezeitgenössische Wiedergabe von VAs Startankündigungberichtete von rund 700 Projekten und 3.000 Entwicklern; sechs Monate später behauptete eineVA-Veröffentlichungmehr als 6.000 Projekte und 40.000 registrierte Benutzer. Die Zahlen sind Unternehmensbehauptungen, keine geprüften Nutzungsmaße, aber die schnelle Akzeptanz des Dienstes steht unabhängig mit seiner späteren Bekanntheit im Einklang.

Die wichtige Einheit war nicht das Repository. Es war das Projekt. Ein Projekt konnte einen Namen, eine öffentliche Seite, Mitgliedschaft, Release-Dateien, einen Bug-Tracker, Patch- und Aufgabenaufzeichnungen, Dokumentation, Foren, Mailinglisten, Neuigkeiten und Statistiken haben. Benutzer konnten projekteübergreifend suchen und entscheiden, wo sie einen Beitrag leisten möchten. Maintainer konnten Versionen veröffentlichen, ohne eine eigene Download-Infrastruktur zu betreiben.

Die Präsenz eines Projekts auf der Website akkumulierte daher mehrere Formen von Kapital auf einmal: eine stabile Adresse, Auffindbarkeit, Beitragshistorie, Problemwissen, Publikumsaufmerksamkeit und sichtbare Aktivität.

Die Kontrolle über dieses Bündel verlieh VA Software mehrere unterschiedliche Machtbefugnisse. Sie legte die Projektregistrierungs- und Nutzungsregeln fest. Sie entschied, welche Funktionen Ingenieurarbeit erhielten. Sie betrieb die Konten, über die Personen Projekten beitraten. Sie kontrollierte die Download-Mirrors und die Messungen, die Maintainern angezeigt wurden. Sie bestimmte, wie Projekte in der Site-Suche und in Kategorien erschienen. Durch die umliegenden Open Source Development Network-Eigenschaften – einschließlich Slashdot, Linux.com und Freshmeat – saß sie auch nahe an den Kanälen, durch die technische Neuigkeiten und Softwareveröffentlichungen Aufmerksamkeit erlangten. Diehistorische Unternehmensseite von VAbeschrieb das Netzwerk als großes Publikum für Technologievermarkter. Die Seite ist jetzt ein Vermächtnisartefakt auf einer Domain, deren gegenwärtiger Zustand sie als alleinigen Beweis ungeeignet macht; ihre historischen Behauptungen sind nur nützlich, wo Einreichungen und datierte Berichte sie bestätigen.

Diese Kontrolle war teils infrastrukturell und teils sozial. Das Hosten von Servern, Speicher, Datenbanken und Bandbreite war teuer, besonders wenn eine beliebte Version einen plötzlichen Anstieg der Downloads verursachen konnte. VA sagte 2002, dass SourceForge.net zu IBM DB2 migriert war und täglich 3,2 Millionen Seitenaufrufe bei 45.000 Projekten und 460.000 registrierten Nutzern bediente. DieseMigrationsankündigungwar auch Marketing für IBM, daher sollte ihre Leistungssprache als gemeinsame Behauptung gelesen werden. Dennoch zeigt sie das operative Problem: Die freie Schmiede war zu einem gemeinsamen Dienst geworden, dessen Ausfall oder Vernachlässigung Tausende unabhängiger Projekte gleichzeitig betreffen konnte.

Die soziale Macht zeigte sich, als kleine Funktionen nicht mehr funktionierten. In einer 2007 erschienenen Retrospektive, die auf Interviews mit Maintainern und ehemaligen Mitarbeitern basierte, berichteteDatamation, dass SourceForge.net Mitte des Jahrzehnts dünn besetzt war. Der Gründer von Audacity erinnerte sich an langsamen Source-Control-Zugriff und grundlegende Ausfälle; ein Gallery-Entwickler sagte, dass Download-Statistiken über lange Zeiträume hinweg defekt bleiben konnten. Statistiken waren wichtig, weil Maintainer sie nutzten, um Reichweite gegenüber Mitwirkenden, Arbeitgebern und Sponsoren zu demonstrieren. Der Bericht beschrieb diese Zahlen als eine Form von Währung. Ein Zähler auf einer kostenlosen Website konnte somit den Status eines Projekts beeinflussen, obwohl kein vertraglicher Service Level ihn schützte.

VA kontrollierte den Open-Source-Code, der auf der Website gehostet wurde, nicht allein durch das Hosten. Lizenzen, Mitwirkendenvereinbarungen und Projektleitung blieben projektspezifisch. Auch besaß es nicht jede Diskussion oder entschied über jedes Release. Seine Macht war bedingter und in gewisser Weise moderner: Es kontrollierte die Umgebung, in der viele unabhängige Entscheidungen lesbar und nützlich wurden. Maintainer konnten gehen, aber Gehen bedeutete, mehr als einen Quellbaum zu rekonstruieren. Die Bequemlichkeit des Dienstes war ein Netz von Abhängigkeiten.

Diese Unterscheidung erklärt, warum Community-Vertrauen wirtschaftlich wertvoll war. Der öffentliche Dienst füllte sich mit nützlichen Projekten, weil Maintainer glaubten, dass es sich lohnte, dort ihre Zeit zu investieren. Ihre Arbeit zog Downloader und Leser an; diese Aufmerksamkeit unterstützte Werbung in VAs Medienangeboten. Das Unternehmen bezahlte die Infrastrukturrechnung und erleichterte die Koordination, während die Community den Großteil der Software, Diskussionen und Gründe für Besuche lieferte. Keine Seite spendete einfach an die andere. Sie tauschten verschiedene Dinge ohne einen konventionellen Preis für jeden Austausch.

Von der Referenzimplementierung zur proprietären Governance

VAs erster Versuch, die öffentliche Schmiede in eine bezahlte Umgebung zu überführen, war SourceForge OnSite. Angekündigt im Dezember 2000, wurde es als Abonnement angeboten, das hinter der Firewall des Kunden installiert und von VA angepasst, implementiert und unterstützt wurde. DieStartmitteilungnannte Agilent Technologies als ersten Kunden und listete Quellcodeverwaltung, Bugs, Patches, Aufgaben, Dokumente, Kommunikation und Projektstatistiken unter den Funktionen auf. Die öffentliche Website, damals mit 12.000 Projekten und 92.000 Nutzern, diente als Nachweis der Nachfrage nach dem Workflow.

Dieser Ursprung schuf eine verlockende Geschichte: Open-Source-Kollaboration hatte einen besseren Weg zur Softwareentwicklung entdeckt, und große Organisationen würden zahlen, um dieselbe Arbeitsweise nach innen zu bringen. Im Juni 2001, als VA das Hardwaregeschäft aufgab und etwa 35 Prozent einer 436-köpfigen Belegschaft entließ, sagte das Unternehmen, es werde sich auf SourceForge OnSite konzentrieren. Es nannte SourceForge.net eine „Referenzimplementierung“ und erwartete, dass Unternehmenssoftware den Großteil der Einnahmen ausmachen würde. DieStrategieankündigungist ein Beleg für die Absicht des Managements, kein Beweis dafür, dass die erwartete Umsatzverschiebung tatsächlich eintrat.

Das Produkt wurde bald zu SourceForge Enterprise Edition oder SFEE. Sein Zweck war nicht einfach, eine öffentliche Website auf einen privaten Server zu klonen. VA präsentierte es zunehmend als Managementsystem für den Software-Lebenszyklus. Eine Version 3.0 aus dem Jahr 2001 betonte Suche, Überwachung, Berichte, Dokumentversionierung, Issue-Workflow und Integration mit Oracle. Spätere Versionen verbanden Unternehmensverzeichnisse, bestehende Quellcodeverwaltungssysteme, Microsoft Project und Office sowie Entwicklungsumgebungen. Mit Version 4.1 sagte VA Linux Systems Japan, die Anwendung sei auf J2EE neu geschrieben worden und biete ein SDK und eine SOAP-Schnittstelle. Diejapanische Release-Beschreibungist eine primäre Wiederverkäuferaussage und keine unabhängige technische Bewertung, aber sie hilft zu belegen, dass das Enterprise-Produkt eine eigene Codebasis geworden war.

Diese Trennung ist entscheidend. Community-Kritik beschrieb VA manchmal als Schließung von SourceForge. Auf der Ebene der Plattform-Governance hatte die Kritik Gewicht: Die Software, die zur Entwicklung des öffentlichen Dienstes verwendet wurde, wurde nach 2001 nicht mehr unter einer freien Lizenz veröffentlicht.LWNs zeitgenössischer Berichtdatierte die letzte freie SourceForge-Veröffentlichung auf November dieses Jahres und verfolgte die daraus resultierenden GForge- und Savannah-Forks. Doch in der späteren VA Software-Periode war SFEE nicht einfach dieselbe Anwendung, die SourceForge.net mit einer umgeschalteten Lizenz betrieb. Die Berichterstattung um den Verkauf von 2007 besagte, dass die öffentliche Seite nicht das Enterprise-Produkt betrieb, und CollabNet beschrieb die kommerzielle Anwendung später als Neuschreibung. Der gemeinsame Name kommunizierte Abstammung und Glaubwürdigkeit mehr als identische Maschinerie.

Was von öffentlich zu privat überging, war daher ein Arbeitsmuster. Gib jedem Projekt ein dauerhaftes Zuhause. Bringe Code, Issues, Dokumente und Diskussionen in die Reichweite desselben Kontosystems. Verknüpfe einen Commit mit der Aufgabe oder dem Fehler, den er adressiert. Lass einen Manager Aktivitäten projektübergreifend sehen, anstatt separate Statusberichte anzufordern. Bewahre genug Historie, um zu rekonstruieren, warum eine Änderung stattfand. In einer öffentlichen Community senkten diese Funktionen die Kosten der freiwilligen Koordination. In einem Unternehmen konnten sie zu Mechanismen der Aufsicht werden.

Diese Zweckänderung betraf den Governance-Handel. Ein öffentlicher Maintainer konnte ein Projekt erstellen oder beitreten und den Dienst nutzen, ohne eine Beschaffungsabteilung überzeugen zu müssen. Eine Enterprise-Bereitstellung benötigte Executive Sponsorship, Systemadministration, Identitätsintegration, Rollendesign, Migration und Schulung. Öffentliche Offenheit begünstigte breite Sichtbarkeit; Unternehmensadoption erforderte vertrauliche Projekte und differenzierte Berechtigungen. Community-Normen tolerierten heterogene Prozesse; Management-Käufer wünschten oft gemeinsame Berichte und durchsetzbare Übergänge.

SFEE war in dem Maße wertvoll, wie es diese Übersetzung ermöglichte, ohne jedes Team in ein völlig neues Source-Control-Tool zu zwingen.

Das Unternehmen konnte glaubhaft sagen, dass es Kollaboration in großem Maßstab beobachtet hatte. Es konnte nicht automatisch ableiten, dass öffentliche Popularität die Eignung für Unternehmen bewies. Der öffentliche Dienst testete Verkehr und freiwillige Nutzung, nicht die Zugangskontrollrichtlinie einer Bank, den Änderungsprozess eines Herstellers oder die Aufzeichnungsanforderungen eines staatlichen Käufers. VAs kommerzielle Chance lag in der Lücke zwischen diesen Welten. Sein Risiko war, dass das Überbrücken der Lücke teure Verkäufe, Beratung und Unterstützung erforderte, die das Wachstum der kostenlosen Seite nicht demonstrierte.

Was ein Unternehmenskäufer tatsächlich installierte

Die aufschlussreichste Beschreibung von SFEE ist nicht eine Startrede, sondern die 440-seitigeVersion 4.3 SP1-Benutzerhandbuchdes Unternehmens, datiert September 2006. Es zeigt eine zentrale Webanwendung, die von Entwicklern, Projektmanagern, Projektadministratoren und Site-Administratoren genutzt wird. Projekte enthalten Anwendungen zur Verfolgung von Arbeit, Dokumenten, Aufgaben, Diskussionen, Wikis und Quellcode. Das System integriert sich mit CVS, Subversion und Perforce, anstatt von jedem Kunden zu verlangen, Code in ein neues proprietäres Repository zu legen. Es kann eine Verbindung zu einem Unternehmens-LDAP-Verzeichnis herstellen und den Zugriff durch Projektmitgliedschaft und Rollen zuweisen.

Für einen gewöhnlichen Entwickler lag der Reiz im Kontext. Ein Commit konnte mit einem Tracker-Element, einer Aufgabe oder einem Dokument verknüpft werden. Ein Fehler konnte Kommentare, Anhänge, Abhängigkeiten und eine Historie von Statusänderungen enthalten. Ein Dokument konnte eine Überprüfung durchlaufen, während Versionen erhalten blieben. Foren, Mailinglisten und Wikis hielten die Diskussion in der Nähe der Arbeit. Die Suche reduzierte die Notwendigkeit zu wissen, welcher Silo die Antwort enthielt.

Dies war besonders nützlich in verteilten Organisationen, wo die Alternative eine Mischung aus E-Mail, gemeinsamen Laufwerken, Tabellenkalkulationen und nicht verwandten Issue-Trackern sein konnte.

Für einen Manager lag der Wert in der Sichtbarkeit. Berichte konnten Aktivitäten zusammenfassen, obwohl das Handbuch sagt, dass die Ergebnisse nach den Berechtigungen des Betrachters gefiltert wurden. Aufgaben konnten in Hierarchien angeordnet und mit Microsoft Project synchronisiert werden. Tracker-Workflows konnten einschränken, wer ein Element von einem Status in einen anderen verschieben durfte, und bei einem Übergang einen Kommentar oder Anhang erfordern. Eine zentrale Anwendung ermöglichte es, Projekte zu vergleichen und Verzögerungen zu sehen, ohne jedes Team zu bitten, einen maßgeschneiderten Bericht zu erstellen.

VAs öffentliches Produktmaterial beschrieb dies als verbesserte Kontrolle und Ressourcenmanagement. Dies sind Anbieterbehauptungen; das Handbuch beweist, dass die Funktionen existierten, nicht dass sie die Lieferung in jeder Organisation verbesserten.

Für einen Administrator schuf das Produkt eine erhebliche Designaufgabe. Rollen waren kumulativ: Die Berechtigungen eines Benutzers konnten aus mehreren Rollen stammen. Berechtigungen konnten Anwendungen und Ordnern zugewiesen werden, mit dokumentierten Grenzen für eine feinere Vererbung. Die Projektmitgliedschaft konnte Genehmigung erfordern. Administratoren konnten Tracker-Felder und Workflows definieren, Repositories verbinden, Foren steuern und Integrationen konfigurieren. Diese Entscheidungen kodierten die Entwicklungspolitik der Organisation.

Ein schlechtes Rollendesign konnte vertrauliche Arbeiten offenlegen oder legitime Mitwirkende blockieren; ein übermäßig komplexer Workflow konnte Rückverfolgbarkeit in Verzögerung verwandeln.

Die Implementierung war daher teils technische Integration und teils institutionelle Verhandlung. Ein Käufer musste entscheiden, welche Projekte in das System gehörten, wer sie erstellen konnte, wie Teams Verzeichnisgruppen zugeordnet wurden, welche Tracker-Status als Genehmigung galten und welche vorhandenen Aufzeichnungen verschoben werden sollten. Er musste Source-Control-Server verbinden und testen, ob Verknüpfungen zwischen Code und Arbeitselementen den täglichen Gebrauch überlebten.

Wenn Microsoft Project verwendet wurde, warnte das Handbuch vor Synchronisationsprotokollen und beschrieb Umstände, unter denen ein fehlendes Protokoll Fehler oder Datenverlust verursachen konnte. Eine als Integration beworbene Funktion erforderte dennoch einen disziplinierten Betrieb.

VA verkaufte professionelle Dienstleistungen für Installation, Integration, Prozessberatung und Schulung. SeinJahresbericht 2006sagte, dass diese Dienstleistungen in der Regel auf Zeit- und Materialbasis abgerechnet wurden. Das Unternehmen betonte, dass Kunden die Software ohne sie nutzen könnten, aber die Breite des Handbuchs und der Integrationsoberfläche erklären, warum größere Bereitstellungen Hilfe kaufen könnten. Dieselbe Einreichung beschrieb direkten Feld- und Telefonverkauf, Wartung, Support und optionales Hosting über einen Dritten.

Der Bereitstellungsort änderte das Risiko, nicht das Bedürfnis nach Vertrauen. Eine On-Premises-Installation hielt Quellcode und Projektaufzeichnungen hinter der Firewall des Kunden, eine starke Antwort auf Organisationen, die keine vertrauliche Entwicklung ins öffentliche Internet stellen wollten. Eine gehostete Option übertrug mehr operative Verantwortung auf VA und seinen Infrastrukturanbieter. In beiden Fällen war der Kunde für Korrekturen, Upgrades und Produktkenntnisse auf VA angewiesen. Die On-Premises-Kontrolle schützte vor einem Ausfall des öffentlichen Dienstes, aber sie ließ die proprietäre Anwendung nicht sich selbst warten.

Version 4.3 fügte Wikis, konfigurierbare Tracker-Workflows, E-Mail-Interaktion und Single Sign-On für externe Anwendungen hinzu.InfoWorld berichtete, dass Käufer es hinter der Firewall ausführen oder einen gehosteten Dienst nutzen konnten, und nannte einen Preis von 2.725 USD pro Benutzer. Dieser Preis machte das Ziel klar. SFEE war kein billiger Ersatz für den Bug-Tracker eines kleinen Teams; es wurde als gemeinsame Betriebsschicht verkauft, deren Kosten gerechtfertigt werden konnten, wenn Koordinationsfehler, doppelte Werkzeuge und schwache Sichtbarkeit teuer waren.

Die Architektur offenbart auch die Wechselkosten des Produkts. Code konnte in CVS, Subversion oder Perforce bleiben, was eine Form der Gefangennahme reduzierte. Tracker-Berichte und Artefakte konnten in gängigen Formaten exportiert werden. Aber das nützliche Ganze umfasste Rolldefinitionen, Workflow-Regeln, Querverweise zwischen Commits und Issues, Dokumenthistorien, Diskussionen, Wiki-Versionen, Aufgabenstrukturen, Berichtskonventionen und Benutzergewohnheiten. Das Handbuch dokumentiert Exporte für Teile dieses Ganzen; es zeigt keinen einzigen, verlustfreien Export einer gesamten Bereitstellung in ein Konkurrenzsystem.

Der Kunde besaß mehr von der Infrastruktur als ein SourceForge.net-Maintainer, konnte aber dennoch von der Organisationsschicht abhängig werden.

Die Ökonomie des Verkaufs von Kontrolle

VA Software bat zwei verschiedene Gruppen, in unterschiedlichen Währungen zu zahlen. Ein Unternehmenskäufer zahlte Lizenzgebühren, erneuerbare Wartung, Hosting-Gebühren, sofern zutreffend, und Gebühren für professionelle Dienstleistungen. Ein öffentliches Projekt zahlte hauptsächlich durch Teilnahme: Seine Veröffentlichungen und Gespräche zogen Nutzer, Suchverkehr und Seitenaufrufe an, die VA an Werbetreibende verkaufen konnte. Die umliegenden Medienangebote verstärkten diese Aufmerksamkeit, während ThinkGeek ein verwandtes Publikum in Handel umwandelte.

Die Enterprise-Seite zeigte echtes Wachstum. Laut derJahreseinreichung 2006stiegen die Softwareeinnahmen von 4,995 Millionen USD im Geschäftsjahr 2004 auf 7,555 Millionen USD im Jahr 2005 und 9,974 Millionen USD im Jahr 2006. Die Gesamtkundenzahl stieg von 97 auf 130 auf 164, während der durchschnittliche Vertragswert von etwa 75.000 USD auf 106.000 USD und dann auf 129.000 USD stieg. VA führte den Anstieg im Jahr 2006 auf Lizenz-, Wartungs-, Hosting- und Professional-Services-Einnahmen zurück, nicht auf eine einzelne Komponente.

Diese Zahlen bestätigen, dass Organisationen das Produkt kauften. Sie zeigen kein effizientes, eigenständiges Softwaregeschäft. Dieselbe Einreichung verzeichnete einen operativen Verlust des Softwaresegments von etwa 2,7 Millionen USD im Geschäftsjahr 2006, nach einem Verlust von etwa 5,4 Millionen USD im Vorjahr. Etwa 3,2 Millionen USD oder 51 Prozent der Unternehmensausgaben für Forschung und Entwicklung in diesem Jahr wurden für SFEE aufgewendet. Die Verkaufszyklen überstiegen üblicherweise drei Monate und konnten länger als ein Jahr dauern.

Potenzielle Kunden berücksichtigten Implementierungszeit, Kompatibilität und Gesamtkosten, und große Käufer erwarteten Support und Mengenrabatte.

Der Listenpreis und der durchschnittliche Vertragswert beleuchten die Verkaufslogik. Bei 2.725 USD pro Benutzer konnte eine breite Einführung schnell teuer werden. Eine ausgehandelte Enterprise-Vereinbarung konnte Sitze mit Wartung, Hosting und Dienstleistungen kombinieren, so dass der durchschnittliche Vertragswert der Einreichung keine einfache Multiplikation von Benutzern mit dem Listenpreis ist. Dennoch begünstigte die Ökonomie Konten, die groß genug waren, um projektübergreifende Governance zu schätzen.

Jeder Deal konnte bedeutend sein, erforderte aber spezialisierte Verkäufer, Demonstrationen, Sicherheitsdiskussionen, Integrationsarbeit and fortlaufenden Support. Das Produkt konnte die Einnahmen steigern, verbrauchte aber mehr organisatorische Anstrengung als die Bruttomarge eines browserbasierten Tools vermuten ließ.

Die Wartung war zentral für den Handel. VA beschrieb eine jährliche, erneuerbare Wartung, die als Prozentsatz der Produktlizenz berechnet wurde und Support und nicht näher bezeichnete Upgrades umfasste. Periodische Fehler- und Sicherheitskorrekturen waren Teil der Anbieterbeziehung. Ein unbefristetes Recht, eine Version auszuführen, bot keinen praktischen Weg, um unbegrenzt ohne Fachwissen, Kompatibilitätsarbeit und Patches zu betreiben. Dies ermöglichte wiederkehrende Einnahmen und machte den Käufer auch aufmerksam auf die Beständigkeit des Anbieters.

Die öffentliche Seite hatte das gegenteilige Skalierungsmuster. Eine Verbesserung des Projekt-Hostings konnte vielen Projekten zugutekommen; ein zusätzlicher Seitenaufruf konnte Werbeinventar zu geringen zusätzlichen Verkaufskosten hinzufügen. Aber der Verkehr war nicht kostenlos zu bedienen, und die Personen, die den Wert schufen, waren keine Angestellten. Bei Unterfinanzierung des Dienstes erlebten Maintainer langsame Repositories, defekte Statistiken und vernachlässigte Funktionen.

Bei zu aggressiver Monetarisierung konnten sie zu dem Schluss kommen, dass ihre Arbeit genutzt wurde, um ein Publikum aufzubauen, über das sie wenig Mitspracherecht hatten.

Bis zum Geschäftsjahr 2006 waren Online-Medien und Handel nicht mehr peripher. Die Einreichung berichtete von 13,242 Millionen USD Online-Medieneinnahmen und 20,416 Millionen USD aus E-Commerce, verglichen mit 9,974 Millionen USD aus Software. EineMotley Fool-Analyseführte das erste profitable Gesamtjahr des Unternehmens weitgehend auf starkes Online-Medien-Werbungswachstum zurück. Diese Interpretation stammte von einer Investmentpublikation, steht aber im Einklang mit den Segmentzahlen. Das skalierbarere Geschäft wurde zunehmend das Publikum, nicht der Enterprise-Kontrollraum.

Dies bedeutete nicht, dass SourceForge.net nur eine Werbeseite war. Sein Nutzen schuf das Publikum, und seine Marke half, das Enterprise-System zu verkaufen. Doch der finanzielle Schwerpunkt war wichtig, wenn das Management Kapital zuwies. Die Verbesserung eines kostenlosen Entwicklerdienstes schützte Vertrauen und Verkehr. Der Bau von SFEE 4.x, die Unterstützung von Integrationen und die Verfolgung langer Enterprise-Verkäufe schützten die Softwareeinnahmen. Beide Aktivitäten konkurrierten um Ingenieure und Aufmerksamkeit.

Die letztendliche Wahl des Unternehmens – den Enterprise-Betrieb zu verkaufen und die Medien- und Handelsvermögenswerte zu behalten – folgte der stärkeren Ökonomie.

Es gab eine zusätzliche Nuance: SourceForge.net fungierte sowohl als öffentliche Infrastruktur als auch als Demonstration. VA konnte auf einen riesigen, aktiven Dienst verweisen, wenn es Kollaborationssoftware verkaufte, auch wenn die Enterprise-Anwendung getrennt war. Dieser Reputationstransfer senkte die Kosten für die Erklärung des Produkts. Aber er konnte auch die Rechenschaftspflicht verschleiern.

Der Erfolg beim Betrieb einer Open-Projekt-Community bewies nicht, dass eine bestimmte Enterprise-Bereitstellung die Kontrollen eines Käufers erfüllen würde; eine Enterprise-Lizenz finanzierte kein garantiertes Service-Level für jeden öffentlichen Maintainer. Der gemeinsame Name bündelte Glaubwürdigkeit leichter als Verpflichtungen.

Vertrauen war die knappe Eingabe

Der entscheidende Konflikt trat ein, als VA aufhörte, neue Versionen der SourceForge-Plattform unter einer freien Softwarelizenz zu veröffentlichen. Aus der Perspektive des Unternehmens schützte proprietärer Enterprise-Code eine Investition und unterstützte Lizenzeinnahmen.Forbes berichtete 2005, dass VA-Führungskräfte befürchteten, eine offene Veröffentlichung würde es Wettbewerbern ermöglichen, nahezu identische Kopien anzufertigen und den Verkauf zu schädigen. Diese Position war kommerziell nachvollziehbar: Wenn der Hauptvorteil des Produkts ohne Zahlung an VA reproduziert werden konnte, wäre es schwieriger, die Kosten seiner Entwicklung und Unterstützung wieder hereinzuholen.

Aus der Perspektive der Community veränderte die Änderung die in der Offenheit enthaltene Versicherung. Ein gehosteter Dienst ist leichter zu vertrauen, wenn Benutzer die Software reproduzieren, verschieben oder eine glaubwürdige Alternative unterstützen können. Im Oktober 2001 argumentierte der Free-Software-Befürworter Loïc Dachary, dass SourceForge-Benutzer Quellcode und Tracker-Daten abrufen, aber kein vollständiges Projekt exportieren könnten, und kritisierte die Bedingungen der Site und VAs Kontrolle über die umliegende Infrastruktur. SeinFSFE-veröffentlichter Essayist eine Advocacy-Quelle und enthält umstrittene Interpretation, kein neutrales Audit. Seine Bedeutung liegt darin zu zeigen, was technisch versierte Benutzer ihrer Meinung nach verloren: nicht das Recht auf ihren Code, sondern einen praktischen Ausstieg aus der gesamten Kollaborationsumgebung.

Die Reaktion war nicht nur rhetorisch. GForge und GNU Savannah entwickelten sich aus dem letzten freien SourceForge-Code.LWN dokumentierte die Forksund die Lücke zwischen dem proprietären Produkt und der öffentlichen Website. Die Forks reduzierten VAs exklusive Kontrolle über die Idee einer Schmiede. Sie zeigten auch, dass die bloße Verfügbarkeit von Code SourceForge.net's angesammeltes Projektverzeichnis, Konten, Verkehr oder Medienreichweite nicht neu erschuf. Software konnte sich leichter gabeln als die Adresse und Geschichte einer Community.

Dies war das Zentrum des Governance-Handels. VA stellte echte Ressourcen bereit: Maschinen, Bandbreite, Betrieb, Produktentwicklung und einen bequemen gemeinsamen Workflow. Es hatte ein legitimes Bedürfnis, diese zu finanzieren. Maintainer stellten ebenfalls echte Ressourcen bereit: Software, Dokumentation, Support-Gespräche, Aufmerksamkeit und Reputation. Ihre Arbeit machte die Site für andere Benutzer nützlich und für Werbetreibende wertvoll. Da keine Rechnung diesen Beitrag erfasste, konnte das Management die kostenlose Nutzung für Nachfrage halten, die der Plattform gehörte, anstatt Vertrauen, das ihr vorübergehend anvertraut war.

Die Datamation-Retrospektive macht die Kosten dieses Fehlers konkret. Während einer Phase begrenzter Investitionen berichteten Projektleiter über defekte oder langsame Dienste, während SourceForge.net Berichten zufolge nur eine Handvoll Mitarbeiter hatte. Im Jahr 2006, nachdem die Site profitabel geworden war, verbesserten sich Personal und Infrastruktur; Subversion-Support, Überwachung und Suche erhielten Aufmerksamkeit. Der Bericht stützt sich auf Interviews und sollte nicht als vollständige Betriebsaufzeichnung behandelt werden. Er offenbart dennoch eine Anreizschleife.

Werbung hing vom Verkehr ab; Verkehr hing von Projekten ab; Projekte hingen von der Servicequalität ab; Servicequalität hing davon ab, dass das Management sich entschied, in Menschen zu reinvestieren, die nicht direkt zahlten.

Enterprise-Vertrauen funktionierte anders. Ein Kunde hatte einen Vertrag, einen Support-Kanal und Software, die er auf eigenen Räumlichkeiten betreiben konnte. Er konnte Preise aushandeln und bei ausreichender Größe die Roadmap beeinflussen. Aber er konnte das vollständige Produkt nicht unter einer freien Lizenz inspizieren und modifizieren. Seine Hebelwirkung kam von Beschaffung, Wartungsverlängerung und den Kosten für VA, einen Referenzkunden zu verlieren. Der Schutz des Kunden war kommerziell, nicht gemeinschaftlich.

Die beiden Vertrauenssysteme verstärkten sich manchmal gegenseitig. Öffentliche Maßstäbe gaben Enterprise-Käufern das Vertrauen, dass VA verteilte Entwicklung verstand. Zahlende Kunden finanzierten Produktkenntnisse, die die breitere Organisation informieren konnten. Sie standen auch manchmal im Konflikt. Funktionen, die ein reguliertes Unternehmen benötigte, halfen nicht unbedingt einem Freiwilligenprojekt. Öffentliche Offenheit konnte Methoden offenlegen, die das Unternehmen verkaufen wollte. Ingenieure, die einer Lizenzveröffentlichung zugewiesen waren, verbesserten nicht die gehostete Site.

Die Marke implizierte eine gemeinsame Mission, während die Betriebsentscheidungen Priorisierung erforderten.

Es besteht keine Notwendigkeit, VA entweder als Wohltäter darzustellen, der von undankbaren Benutzern betrogen wurde, oder als Ausbeuter, der Freiwillige ausnutzte. Beide Karikaturen verfehlen den Austausch. Das Unternehmen baute einen Dienst, der erhebliche Reibung aus der Open-Source-Arbeit entfernte. Maintainer machten diesen Dienst strategisch wertvoll. Das Versagen war nicht, dass eine Seite Wert erhielt; es war, dass die Rechte und Ausstiegsoptionen, die den Austausch regelten, weniger entwickelt waren als die Abhängigkeiten, die um ihn herum wuchsen.

Abhängigkeit zeigte sich in verschiedenen Formen

SourceForge.net war eine frühe Cloud-Abhängigkeit, bevor dieser Satz gebräuchlich wurde. Ein Maintainer musste keine Server kaufen, Source-Control konfigurieren, Mailinglisten verwalten, Download-Mirrors betreiben oder eine Projektwebsite aufbauen. Der Dienst verwandelte Kapital und Verwaltung in eine URL und ein Konto. Das war befreiend, insbesondere für kleine Projekte. Es konzentrierte auch das Ausfallrisiko.

Die portabelste Komponente war normalerweise der Quellcode. CVS und später Subversion waren etablierte Werkzeuge, und ein Projekt konnte eine weitere Kopie eines Repositories erstellen. Die weniger portablen Komponenten waren Kontext und Koordination: Tracker-Historie, Kontomitgliedschaft, Mailinglisten-Archive, Forendiskussionen, Release-Statistiken, eingehende Links, Suchrank und die Erwartung, dass Benutzer die nächste Version an derselben Stelle finden würden. Eine technisch erfolgreiche Migration konnte dennoch Mitwirkende verlieren oder alte Links hinterlassen.

Dacharys Kritik von 2001 behauptete, dass der Dienst einen vollständigen Projektexport vermissen ließ. Die späteren Benutzerberichte über defekte Statistiken zeigen, warum scheinbar periphere Metadaten wichtig sein konnten.

Das Enterprise-Produkt kehrte einige dieser Risiken um. On-Premises-Bereitstellung gab einem Kunden die Kontrolle über Server, Netzwerkzugriff und Backups. Die Integration mit bestehenden Repositories bedeutete, dass die Quelle selbst nicht in einem neuartigen Speicher gefangen sein musste. Corporate LDAP konnte die Kontoberechtigung beim Kunden behalten. Dies waren sinnvolle Reduzierungen der Abhängigkeit von gehosteten Diensten.

Aber die Zentralisierung schuf eine neue Konzentration. Sobald Teams Commits, Issues, Dokumente, Aufgaben, Diskussionen and Berichte durch SFEE verknüpften, wurde die Anwendung zu einer Karte, wie Arbeit sich bewegte. Manager lernten, sich auf ihre Berichte zu verlassen; Administratoren kodifizierten Genehmigungsregeln; Benutzer lernten ihre Felder und Übergänge. Das Ersetzen bedeutete nicht nur die Installation eines Konkurrenten, sondern die Entscheidung, welche Historie und Richtlinie fortgeführt werden sollten.

Das Exportieren einer Tracker-Tabelle stellte ihre Verknüpfungen zu Quellcodeänderungen oder ihren rollenabhängigen Workflow nicht wieder her.

Optionaler Hosting fügte eine weitere Ebene hinzu. Ein gehosteter Enterprise-Kunde konnte den Betrieb vermeiden, war aber für Verfügbarkeit und Wiederherstellung von VA und einem Drittanbieter-Host abhängig. Die öffentlichen Einreichungen beschreiben Hosting-Einnahmen, keine detaillierten Serviceverpflichtungen oder Leistungshistorie. Es wäre unsicher, aus der Existenz einer Hosting-Option starke Verfügbarkeitsgarantien abzuleiten. Ein sorgfältiger Käufer hätte den Vertrag, die Backup-Vereinbarungen und den Exit-Prozess prüfen müssen.

Die Lektion ist, dass Standort und Lizenz unterschiedliche Fragen beantworten. Software hinter einer Firewall kann dennoch eine Anbieterabhängigkeit erzeugen. Ein kostenloser öffentlicher Dienst kann frei lizenzierte Software hosten, während der umgebende Workflow schwer zu verschieben bleibt. Offene Repositories reduzieren eine Wechselkosten; offene Standards und nutzbare Exporte reduzieren andere; eine glaubwürdige Migrationsübung testet das Ganze. VA Softwares zwei SourceForges machen diese Unterscheidungen ungewöhnlich sichtbar.

Sicherheit, Compliance und die Grenzen der Aufzeichnung

VA verkaufte SFEE teilweise auf der Grundlage des Unterschieds zwischen öffentlicher Kollaboration und kontrollierter Kollaboration. Ein Unternehmen konnte vertrauliche Projekte hinter seiner Firewall platzieren, Benutzer gegen ein Unternehmensverzeichnis authentifizieren und Rollen unterschiedliche Berechtigungen geben. Tracker-Workflows konnten Nachweise bei einem Statusübergang erfordern. Versionshistorien und Assoziationen zwischen Issues, Dokumenten und Commits konnten die Entwicklungstätigkeit leichter rekonstruierbar machen. VAsProduktmaterialverwendete die Sprache der Prüfbarkeit, Rückverfolgbarkeit und Sichtbarkeit.

Diese Fähigkeiten konnten ein Kontrollprogramm unterstützen, aber sie waren nicht dasselbe wie der Nachweis von Compliance. Ein erforderlicher Anhang kann helfen, eine Genehmigung zu dokumentieren; er begründet nicht, dass der Genehmiger unabhängig war oder dass der zugrunde liegende Test angemessen war. Eine Historie kann offenbaren, was die Anwendung aufgezeichnet hat; sie kann keine Entscheidungen erfassen, die per E-Mail oder in einem Meeting getroffen wurden, es sei denn, Benutzer geben sie ein. Rollenbasierter Zugriff kann Richtlinien ausdrücken; eine falsch konfigurierte Rolle kann sie untergraben.

Das Benutzerhandbuch zeigt einige wichtige Kanten. Berechtigungen waren über Rollen hinweg kumulativ. Berichte respektierten die Berechtigungen des Betrachters. Projektadministratoren konnten die Mitgliedschaft und den Anwendungszugriff verwalten. Die Granularität hatte Grenzen, einschließlich der Art und Weise, wie Ordnerberechtigungen angewendet wurden. Diese Details sind für einen Käufer wichtiger als ein breites Versprechen von „Sicherheit“, da sie bestimmen, ob das Produkt die Funktionstrennung der Organisation abbilden kann.

Öffentliche Beweise unterstützen keine stärkere Behauptung über das VA-Ära-Produkt. Die überprüften Einreichungen, Handbücher, Veröffentlichungen und unabhängigen Berichte liefern keine vollständige Sicherheitsbewertung durch Dritte, eine detaillierte Verfügbarkeitshistorie, Wiederherstellungsziele oder eine umfassende Liste von Zertifizierungen für SFEE. Das Fehlen in diesem Beweissatz beweist nicht, dass kein Kunde solches Material unter Vertraulichkeit erhalten hat. Es bedeutet, dass ein Leser die Sicherheitsfunktionen eines Produkts von unabhängig verifizierter Sicherheitsgewähr unterscheiden sollte.

Die gleiche Vorsicht gilt für SourceForge.net. VAs DB2-Ankündigung zeigt Investitionen in die Skalierung, keine vertragliche Garantie für freie Projekte. Die Seite trug öffentlichen Code, aber Konten, Release-Dateien und Projektadministration erforderten dennoch Schutz. Ein größerer Kompromiss, der von SourceForge im Jahr 2011 offengelegt wurde, betraf die von diesem Dienst abgeleitete Infrastruktur, Jahre nachdem VA Software seinen Namen geändert hatte und das Management gewechselt war. DerIncident Report des Nachfolgebetreibersist ein nützlicher Beleg für die Art von Risiko, das durch eine gemeinsame Schmiede entsteht; er ist kein Beleg für einen Bruch in der VA-Ära und sollte nicht rückwirkend VA zugeordnet werden.

Für einen Enterprise-Käufer im Jahr 2006 wäre der praktische Sicherheitstest architektonisch und operativ gewesen. Welche Komponenten waren dem Internet ausgesetzt? Wo befanden sich die Anmeldeinformationen? Konnten LDAP-Gruppen abgebildet werden, ohne übermäßige Berechtigungen zu erteilen? Wie wurden Patches bereitgestellt und getestet? Was deckte die Drittanbieter-Hosting-Vereinbarung ab? Konnten Administratoren Logs exportieren und nachweisen, dass eine Änderung die erforderlichen Zustände durchlaufen hatte? VA bot Funktionen, die für diese Fragen relevant waren. Die öffentliche Aufzeichnung beantwortet nicht alle.

Diese Beweisgrenze ist selbst Teil der Unternehmensgeschichte. SFEE wurde zu einer Zeit verkauft, als Enterprise-Software-Marketing sich oft auf Firewall-Bereitstellung und Zugriffskontrolle als Kurzform für Sicherheit verließ. Das Produkt mag in Bereichen, die die erhaltenen öffentlichen Dokumente nicht zeigen, stark oder schwach gewesen sein. Eine ernsthafte Bewertung muss es vermeiden, die Lücken entweder mit Nostalgie oder zeitgenössischen Erwartungen zu füllen.

Wettbewerb war eine Beschaffungsentscheidung, keine Funktionscheckliste

VAs jährliche Einreichungen nannten ein breites Wettbewerbsfeld: CollabNet, IBM, Microsoft, Borland, Serena und die eigenen Sammlungen kommerzieller, Open-Source- und selbst entwickelter Werkzeuge der Kunden. Diese Alternativen verkauften nicht alle dasselbe. Ein Käufer, der sie verglich, entschied, wie viel des Entwicklungsprozesses zentralisiert werden sollte, welche bestehenden Repositories erhalten bleiben sollten, wessen Support vertrauenswürdig war und wie viel Prozessänderung die Organisation absorbieren konnte.

Der Amtsinhaber war oft nicht eine andere Suite. Es war E-Mail plus gemeinsame Laufwerke, ein Source-Control-Server, Tabellenkalkulationen, ein Bug-Tracker und das Wissen erfahrener Mitarbeiter. Diese Anordnung konnte in Lizenzkosten günstig und in Koordination teuer sein. Sie erlaubte Teams, ihre Werkzeuge zu wählen, machte aber Portfolio-Berichte und teamübergreifende Suche schwierig. SFEEs stärkstes Argument war nicht, dass jede Komponente einzigartig war; es war, dass die Komponenten Benutzer, Berechtigungen und Assoziationen gemeinsam nutzten.

Open-Source-Alternativen wie GForge und Savannah veränderten den Lizenzvergleich. Eine Organisation mit technischen Kapazitäten konnte einen Nachkommen des früheren SourceForge-Codes ausführen und mehr Freiheit behalten, ihn zu modifizieren. Der Trade-off war Verantwortung: Integration, Upgrades, Sicherheitskorrekturen und Support würden bei der Organisation oder einem anderen Anbieter liegen. Das Vorhandensein eines Forks garantierte auch keine funktionale Parität mit SFEEs späterer J2EE-Anwendung, Enterprise-Verzeichnisunterstützung oder Anbieterintegrationen.

Große Plattformanbieter boten andere Hebel. IBM und Microsoft konnten Kollaboration mit breiteren Entwicklungsportfolios und Kundenbeziehungen verbinden. Borland und Serena brachten etablierte Configuration-Management-Produkte. CollabNet kam von kollaborativer Entwicklung und Subversion. VA konterte mit dem SourceForge-Namen, beobachtetem öffentlichem Community-Workflow und einer Anwendung, die dazu entwickelt war, über mehreren Repository-Wahlen zu sitzen. Seine Offenheit an der Integrationsgrenze war strategisch wichtig, obwohl das Produkt selbst proprietär war.

CollabNets letztendliche Rolle als Käufer ist aufschlussreich. Einzeitgenössischer InformationWeek-Berichtsagte, VA habe etwa 200 Enterprise-Kunden und CollabNet etwa 100, während SourceForge.net selbst etwa 146.768 Projekte und 1,6 Millionen registrierte Benutzer hatte. Diese Zahlen wurden um die Transaktion herum berichtet und mögen Unternehmensdefinitionen verwenden, aber sie zeigen, warum der Deal mehr als ein Code-Kauf war. CollabNet erwarb Kundenbeziehungen, ein Team und ein vertrautes Enterprise-Produkt von einem ehemaligen Rivalen.

Ein umsichtiges Beschaffungsteam hätte daher fünf Thesen testen sollen, anstatt Wiki- und Tracker-Funktionen zu zählen. Erstens: Konnte die Suite die tatsächlichen Genehmigungs- und Zugriffsregeln der Organisation ohne übermäßige Anpassung abbilden? Zweitens: Bewahrten ihre Integrationen bestehende Repositories und Planungspraktiken oder fügten sie nur einen weiteren Bildschirm hinzu? Drittens: Konnte ein repräsentatives Projekt mit seiner nützlichen Historie hinein- und hinaus migriert werden? Viertens: Hatte der Anbieter den finanziellen Anreiz und das Personal, das Produkt zu erhalten?

Fünftens: Was geschah mit dem Support nach einem Kontrollwechsel?

VA konnte die ersten beiden mit Demonstrationen und einem Pilotprojekt beantworten. Das Handbuch und die Produktveröffentlichungen zeigen erhebliche Breite. Die dritte erforderte eine Exportübung; die öffentliche Dokumentation unterstützt Teilexporte, aber keine vollständige Portabilitätsbehauptung. Die vierte wurde zunehmend unangenehm, da das Softwareeinnahmenwachstum die Verluste des Segments nicht beseitigt hatte. Die fünfte wurde 2007 real. Beschaffung war nicht nur die Wahl der besten Funktionsmenge. Es war die Wahl eines Governance-Gegenübers.

Warum das Softwaregeschäft verkauft wurde

Der Verkauf an CollabNet war kein abruptes Eingeständnis, dass niemand SFEE wollte. Das Produkt hatte eine wachsende Kundenzahl, steigende durchschnittliche Vertragswerte und erkennbare Käufer. VA berichtete von Wiederholungskäufen von Organisationen wie FedEx, Lockheed Martin und dem US Forest Service, während es neue Kunden in Industrie-, Technologie- und öffentlichen Märkten nannte. Solche Ankündigungen beweisen kommerzielle Transaktionen, nicht Übernahmetiefe oder Kundenergebnisse, aber sie widersprechen der Idee eines Produkts ohne Markt.

Das Problem war die Form des Marktes relativ zu VAs anderen Vermögenswerten. Enterprise-Kollaboration erforderte anhaltende Produktinvestitionen, spezialisierten Support und langwierigen Verkauf. Online-Medien und Handel waren bis zum Geschäftsjahr 2006 größere Umsatzbringer, und Werbung wuchs schnell. Das Management konnte entweder einen subskaligen Software-Wettbewerber weiter finanzieren oder sich auf Publikum und Handel konzentrieren.

Dergeänderte Jahresbericht 2007hält die Wahl in buchhalterischen Begriffen fest. VA übertrug im Wesentlichen alle Vermögenswerte des Softwaregeschäfts und bestimmte Verbindlichkeiten an CollabNet im Austausch gegen 11.733.777 Aktien der CollabNet-Vorzugsaktien, bewertet mit etwa 6,6 Millionen USD zum Abschluss. Es verbuchte einen Gewinn von etwa 5,7 Millionen USD vor Steuern. Das Geschäft umfasste geistiges Eigentum und Ausrüstung; CollabNet bot den übertragenen Mitarbeitern eine Anstellung an, während andere Mitarbeiter entlassen wurden. VA ging mit einer Beteiligung am Käufer hervor, anstatt einfach Bargeld zu nehmen und zu gehen.

Die Vereinbarung bewahrte auch eine Brücke zwischen den Geschäften. Die Berichterstattung sagte, VA würde CollabNet bewerben und Enterprise-Interessenten für 30 Monate weiterleiten. Die SourceForge-Marke und das öffentliche Publikum konnten weiterhin Leads generieren, obwohl CollabNet jetzt das Produkt besaß. Diese Regelung erkannte die kommerzielle Verbindung an, ohne zu behaupten, dass die Produkte ein System seien.

Die Finanzgeschichte verleiht der Entscheidung mehr Gewicht. Die geänderte Einreichung berichtet von Softwareeinnahmen von 7,555 Millionen USD im Geschäftsjahr 2005, 9,974 Millionen USD im Jahr 2006 und 5,236 Millionen USD im Teilzeitraum 2007 vor dem Verkauf, neben operativen Verlusten in jeder Periode. Die genauen Periodenvergleiche erfordern Sorgfalt, da das letzte Jahr gekürzt war. Die Richtung ist dennoch klar: VA hatte ein echtes Enterprise-Geschäft aufgebaut, aber es hatte vor der Veräußerung keine dauerhafte Segmentrentabilität nachgewiesen.

Nach dem Verkauf brauchte die ursprüngliche Körperschaft „Software“ nicht mehr in ihrem Namen. Am 24. Mai 2007 wurde sie zu SourceForge, Inc. und verschmolz die Operationen ihrer Medientochter in die Muttergesellschaft.Computerworlds Berichtbeschrieb ein Unternehmen, das sich auf Web-Eigenschaften, Werbung und ThinkGeek konzentrierte. Die Umbenennung war nicht kosmetisch. Sie erkannte an, dass die öffentliche Marke und ihr Publikum, nicht die Enterprise-Anwendung, das verbleibende Geschäft definierten.

VA Softwares Strategie kann daher als Experiment mit drei Umwandlungen gelesen werden. Es versuchte, öffentliche Kollaborationspraxis in Enterprise-Software, Community-Aufmerksamkeit in Werbeeinnahmen und technische Publikumsaffinität in Handel umzuwandeln. Die erste brachte ein wertvolles Vermögen, aber ein teures unabhängiges Geschäft hervor. Die zweite und dritte passten besser zu dem verbleibenden Unternehmen. Der Verkauf von SFEE trennte die Umwandlung, die Enterprise-Betriebstiefe erforderte, von denen, die am meisten von der Publikumsskala profitierten.

Was Kunden, Maintainer und Eigentümer erbten

Die Transaktion schuf mindestens vier Erblinien, jede mit einer anderen Beziehung zu VA Software.

Enterprise-Kunden erbten CollabNet als Verwalter des Produkts. Die Übertragung umfasste die relevante Entwicklungs-, Support-, Vertriebs- und Feldservice-Operation, wodurch das Risiko eines Kaufs reduziert wurde, der von den Leuten getrennt war, die ihn verstanden. In Japan kündigte VA Linux Systems Japan an, dass es das Produkt nach der Übertragung weiter verkaufen und unterstützen werde. Zwei Jahre später benannte CollabNet SourceForge Enterprise Edition in TeamForge um, teilweise um Verwechslungen mit SourceForge.net zu vermeiden.InternetNews berichtete, dass das Produkt dann als CollabNet TeamForge präsentiert wurde. Die Umbenennung klärte, was der Verkauf von 2007 bereits festgestellt hatte: Die Enterprise-Linie gehörte nicht mehr dem Eigentümer der öffentlichen Seite.

Öffentliche Maintainer erbten Kontinuität des Dienstes unter SourceForge, Inc., nicht CollabNet. Ihre Projekt-URLs, Repositories, Releases und Communities blieben beim ursprünglichen Unternehmensbetreiber. Diese Kontinuität vermied eine erzwungene Migration zum Zeitpunkt des Verkaufs. Sie bedeutete auch, dass Maintainer nicht den Enterprise-Ingenieuren und der Support-Organisation folgten, nur weil beide einst den SourceForge-Namen verwendet hatten.

Open-Source-Schmiedenbetreiber erbten den früheren freien Code und das Argument für Unabhängigkeit. GForge und Savannah hatten bereits gezeigt, dass eine Community eine andere Schmiede aus der letzten frei veröffentlichten Plattform bauen konnte. Sie erbten nicht den Verkehr, das Projektverzeichnis oder die Marke von SourceForge.net. Ihre Existenz gab Organisationen und Projekten dennoch einen alternativen Governance-Pfad und bewahrte die Idee, dass die Kollaborationsschicht selbst inspizierbar und modifizierbar sein konnte.

Die ursprüngliche Körperschaft erbte das Publikum und das Problem, es zu monetarisieren. Sie wurde im November 2009 zu Geeknet. Im Jahr 2012 verkaufte Geeknet das Mediengeschäft, das SourceForge, Slashdot und Freecode umfasste, für 20 Millionen USD in bar an Dice Holdings, gemäß einer späterenSEC-Einreichung. Im Jahr 2016 wechselten die SourceForge- und Slashdot-Eigenschaften erneut den Besitzer; dasSourceForge-Team sagte, BIZX habe sie übernommen und versprach, ein kontroverses Installer-Programm zu beenden. Diese späteren Entscheidungen gehören den Nachfolge-Eigentümern, nicht VA Software. Sie zeigen, warum Markenkontinuität die Unternehmensidentität nicht ersetzen kann.

Die aktuelle SourceForge-Seite präsentiert sich immer noch als große Software-Entdeckungs- und Hosting-Plattform. Ihreöffentliche Homepagebehauptet Hunderttausende von Projekten und Millionen registrierter Benutzer unter dem Namen Slashdot Media. Diese zeitgenössischen Behauptungen sind kein Beleg für VAs aktuelle Operationen; VA Software existiert nicht mehr unter dem zugewiesenen Namen. Sie zeigen, dass das öffentliche Vermögen den speziellen Handel, der es schuf, überlebte.

Die Produktlinie überlebte auch den Verkauf. TeamForge-Dokumentation bleibt durch spätere Enterprise-Software-Verwaltung verfügbar. Das Überleben beweist nicht, dass jeder VA-Ära-Kunde blieb, noch dass alte Workflows reibungslos migrierten. Es zeigt, dass CollabNet das Produkt nicht nur kaufte, um es sofort zu schließen. Kunden erhielten einen fortlaufenden kommerziellen Pfad, während Maintainer einen fortlaufenden gehosteten Pfad erhielten. Die Pfade divergierten.

Diese Spaltung beantwortet die Qualifikationsfrage genauer als eine Liste von Akquisitionen. VA kontrollierte eine öffentliche Community-Umgebung, ein Enterprise-Produkt, Medieneigenschaften und eine kommerzielle Beziehung zwischen ihnen. Es besaß nicht die Software der unabhängigen Projekte, nur weil es sie hostete. Als die Vermögenswerte getrennt wurden, erbten Kunden Produktkontinuität vom Käufer; Maintainer erbten Dienstkontinuität vom umbenannten Verkäufer; spätere Eigentümer erbten das Publikum, die Archive und die Monetarisierungsspannungen.

Ein Beschaffungstest für den Handel

VA Software ist historisch, aber seine zwei Kontrollflächen bieten einen anspruchsvollen Test für jede heutige Entwicklerplattform. Der Test beginnt damit, sich zu weigern, nur zu fragen: „Wo ist der Code?“

Kartiere das gesamte Projekt, nicht das Repository.Ein Käufer oder Maintainer sollte Issues, Diskussionen, Release-Dateien, Dokumentation, Paketlinks, Konten, Berechtigungen, Webhooks, Statistiken und eingehende Adressen inventarisieren. SourceForge’s Geschichte zeigt, dass Download-Zahlen und Projektentdeckung operative Vermögenswerte sein können, selbst wenn sie wie Website-Dekoration aussehen. Ein Repository-Mirror schützt den Code, aber möglicherweise nicht das Projekt.

Trenne Betreiberkontrolle von Projekteigentum.Eine Open-Source-Lizenz kann Rechte am Code garantieren, während die Plattform Autorität über Konten, Ranking, akzeptable Nutzung, Werbung und Verfügbarkeit behält. Die relevanten Fragen sind, wer ein Projekt sperren, eine URL ändern, eine Download-Seite verändern oder die Zugriffsrichtlinie modifizieren kann, und welche Berufung existiert. VAs öffentliche Benutzer besaßen oder lizenzierten ihre Arbeit unter projektspezifischen Bedingungen; VA kontrollierte dennoch die Umgebung, durch die ein Großteil dieser Arbeit die Benutzer erreichte.

Führe einen Exit durch, bevor die Abhängigkeit vollständig ist.SFEE konnte Tracker-Artefakte und Berichte exportieren und integrierte sich mit etablierten Repositories. Das waren nützliche Sicherungen. Ein ernsthafter Test würde auch Rollen, Workflow-Zustände, Verknüpfungen, Dokumenthistorien und Diskussionen in einem anderen System rekonstruieren und dann messen, was verloren ging. Für eine gehostete Community würde die Übung Weiterleitungen, Release-Mirrors, Mailinglisten-Archive und eine Möglichkeit umfassen, Benutzer zu benachrichtigen. Portabilität ist ein beobachtetes Ergebnis, kein mit „Export“ beschriftetes Kontrollkästchen.

Bepreise die Betriebsbeziehung, nicht die anfängliche Lizenz.VAs Einreichungen teilen Softwareeinnahmen in Lizenzen, Wartung, Hosting und Dienstleistungen auf, während sein Handbuch die administrative Arbeit des Rollen- und Workflow-Designs offenlegt. Die Gesamtkosten umfassten Verkäuferzeit, Käuferzeit, Integration, Schulung, Upgrades und die Störung durch die Standardisierung von Teams. Dieselbe Logik gilt für einen kostenlosen öffentlichen Dienst: Die Rechnung mag null sein, aber Migrations- und Ausfallkosten sind es nicht.

Teste Kontrollbehauptungen gegen echte Berechtigungen.Ein Pilot sollte repräsentative vertrauliche Projekte und tatsächliche Jobrollen verwenden. Kann ein Auftragnehmer nur die vorgesehenen Anwendungen sehen? Gewähren kumulative Rollen unerwartete Rechte? Fehlen in einem Managerbericht Aufzeichnungen, auf die der Manager nicht zugreifen kann? Kann eine erforderliche Genehmigung über einen anderen Weg umgangen werden? VAs Dokumentation war spezifisch genug, um solche Tests zu ermöglichen; Marketing-Sprache allein war es nicht.

Verlange Beweise für Verfügbarkeit und Wiederherstellung.SourceForge.nets Skalierungsbehauptungen und DB2-Migration deuteten auf Ingenieurinvestitionen hin, aber kostenlose Benutzer erhielten dadurch keine Servicegarantie. Gehostete Enterprise-Käufer benötigten Vertragsbedingungen, Backup-Verantwortlichkeiten, Wiederherstellungsziele und einen getesteten Datenrückgabeprozess. On-Premises-Käufer benötigten Patch-Lieferung und Upgrade-Verfahren. „Hinter der Firewall“ beantwortete, wo der Server stand, nicht, wie der Dienst wiederhergestellt wurde.

Untersuche die Portfolio-Anreize des Betreibers.VA musste zwischen der öffentlichen Schmiede, dem Enterprise-Produkt, Medienseiten und dem Handel wählen. Bis 2006 waren die letzteren Geschäfte finanziell stark. Ein Kunde sollte fragen, welche Linie die Plattform finanziert, welche Linie um ihre Ingenieure konkurriert und ob Benutzeraktivität auch Werbeinventar ist. Quersubventionierung kann einen Dienst ermöglichen; sie kann auch seine Prioritäten schwer lesbar machen.

Schreibe für einen Kontrollwechsel.Die Übertragung von 2007 war relativ geordnet, weil Produktvermögenswerte und viele Mitarbeiter gemeinsam wechselten und eine Überweisungsvereinbarung die alten und neuen Eigentümer verband. Dennoch standen Kunden einem neuen Gegenüber gegenüber und Maintainer blieben bei einem anderen Unternehmen. Verträge sollten Abtretung, Support-Kontinuität, Zugang zu Daten, Kündigungsfrist, Übergangshilfe und das Schicksal vorausbezahlter Wartung regeln. Community-Projekte ohne Verträge benötigen ihren eigenen Notfallplan.

Unterscheide einen gemeinsamen Namen von einem gemeinsamen System.VAs beständigste Quelle der Verwirrung war das Branding. SourceForge.net, SFEE, OSDN-Medieneigenschaften, SourceForge, Inc. und spätere Eigentümer waren verwandt, aber nicht austauschbar. Eine Beschaffungsaufzeichnung sollte den rechtlichen Lieferanten, die Bereitstellung, die Produktversion, den Support-Anbieter und den Datenbetreiber identifizieren. Markenbekanntheit ist keine Provenienz.

Diese Tests sind kein Argument gegen gehostete Werkzeuge oder integrierte Suiten. SourceForge.net ermöglichte Projekte, die sich vielleicht keine zuverlässige Infrastruktur hätten leisten können, während SFEE Organisationen half, fragmentierte Entwicklungsarbeit zu verbinden. Die Tests sind ein Argument dafür, Bequemlichkeit mit Governance zu paaren. Abhängigkeit wird gefährlich, wenn sie schneller wächst als die Beweise über Exit, Kontrolle und Anreize.

Die bleibende Lektion des Unternehmens ist die Spaltung

VA Software scheiterte nicht daran, Wert im Open-Source-Workflow zu finden. Es fand mehrere Arten von Wert und entdeckte, dass sie zu verschiedenen Geschäften gehörten. Die öffentliche Schmiede machte Projekte leichter zu erstellen und zu finden. Ihre Community und das umliegende Mediennetzwerk versammelten ein Publikum, das Werbetreibende wollten. Das Enterprise-Produkt übersetzte Projektkollaboration in Berechtigungen, Berichte, Integration und bezahlten Support. ThinkGeek monetarisierte Affinität durch Waren. Jede Umwandlung funktionierte bis zu einem gewissen Grad; sie passten nicht alle bequem in eine operative Struktur.

Die folgenreichste Macht des Unternehmens war die Fähigkeit, den Ort zu definieren, an dem Softwarearbeit koordiniert und sichtbar wurde. Auf SourceForge.net bedeutete das Projektidentität, Entdeckung, Downloads und Community-Geschichte. In SFEE bedeutete es Rollen, Workflows, Querverweise und Management-Berichte. Eine Kontrollfläche hing von freiwilligem Vertrauen ab; die andere verkaufte vertragliche Kontrolle. Beide wurden wertvoller, als Benutzer mehr ihres Arbeitskontextes in sie hineinlegten.

Der Einnahmenhandel testete dieses Vertrauen. Die Schließung der Entwicklung der Schmiedeplattform schützte ein proprietäres Enterprise-Vermögen, schwächte aber die Zusicherung der Community, dass sie den Dienst reproduzieren konnte. Werbung finanzierte öffentliche Infrastruktur, machte aber Aufmerksamkeit zu einem Unternehmensvermögen. Enterprise-Wartung finanzierte Support, erhöhte aber die Sorge der Kunden über die Kontinuität des Anbieters. Keine dieser Entscheidungen war irrational. Zusammen ließen sie den gemeinsamen SourceForge-Namen Erwartungen tragen, die ein Unternehmen nicht mehr in Einklang bringen konnte.

Der Verkauf von 2007 löste den Widerspruch, indem er die Teile verteilte. CollabNet übernahm die Enterprise-Software und einen Großteil der Organisation, die ihre Kunden bediente. Das umbenannte SourceForge, Inc. behielt die gehostete Community, den Medienverkehr und den Handel. Forks führten die letzte freie Plattformcode weiter. Spätere Eigentümer erwarben die öffentliche Marke und ihr angesammeltes Publikum. Kein Nachfolger erbte den gesamten Handel.

Deshalb bleibt VA Software nützlich zu studieren. Seine Geschichte geht den heutigen dominanten Entwicklerplattformen voraus, legt aber ihre zentralen Fragen mit ungewöhnlicher Klarheit offen. Wer kontrolliert Projektidentität und Entdeckung? Welche Teile einer Software-Community sind portabel? Was erhält ein kostenloser Dienst im Austausch für Infrastruktur? Wie verwandelt eine proprietäre Workflow-Schicht Bequemlichkeit in Wechselkosten? Und wenn ein Betreiber sich selbst verkauft oder umbenennt, wer erbt die Verpflichtungen, von denen die Benutzer dachten, sie gehörten zur Marke?

Die Antwort ist nie nur „der Code-Host“. Es ist die juristische Person, der Dienst, das Produkt, die Menschen, die ihn unterstützen, die Community, die seinen Wert liefert, und die Vereinbarungen – oder das Fehlen von Vereinbarungen – die sie verbinden. VA Softwares Schmiede war mächtig, weil sie diese Elemente zusammenbrachte. Ihre Geschichte wurde lesbar, als sie auseinanderfielen.