Die auf GitHub populären Frameworks und Sprachen der letzten 5 Jahre sind allesamt von Konzernen gelenkte Entwicklungen, die die Zukunft dieser Konzerne sichern und gegen disruptive Konkurrenten schützen soll.
Waren proprietäre Sprachen und Frameworks schon immer in allen Bereichen der Branchen präsent und verbreitet, so war dies fast immer auf Teilbereiche beschränkt: .Net auf Windows, Java für Enterprise-Anwendungen, Objective C für Macintosh. Dominierende OpenSource-Projekte der 1990er und 00er Jahre wie Perl, PHP, Python und Ruby waren allesamt „wirkliche“ OpenSource-Projekte einzelner Menschen und Unternehmen, ohne dass dort zwangsläufig eine absolute Dominanz ersichtlich war. Das lag natürlich auch an der auf (zugegeben sehr große) Teilbereiche der Software-Entwicklung. Wer Entscheidungen von Zend, der „PHP Company“ nicht mittragen wollte, hatte ausreichend Alternativen ohne nennenswerte Nachteile.
Mit der zweiten JavaScript-Welle änderte sich allerdings alles: Google dominierte damit den Interpreter (V8), die aktive Sprachentwicklung und den Browser. Was viele Menschen nicht verstehen wollten: Es ist eigentlich irrelevant, ob ein Unternehmen proprietäre Features baut, oder diese mit eigenen Leuten öffentlich als Standard definiert. Am Ende des Tages wurde das als de-facto oder „de-jure“ Standard beschlossen, was im Sinn der Konzerne war, namentlich bei JavaScript und HTML5 das, was Google wollte.
So war rückblickend die „Befreiung“ vom Internet-Explorer auch ein Pyrrhussieg. denn einerseits hat sich Google direkt (über Chrome) und indirekt (über die Beeinflussung von Mozilla) als neuer Platzhirsch der Standards etabliert. Aktuell arbeitet das Chrome-Team z.B. daran, die unliebsamen Adblocker ABP und uBlock Origin unbrauchbar zu machen: Es sollen Schnittstellen abgekündigt werden, die zwingend für ein aktives Adblocking notwendig sein sollen.
Auf der anderen Seite starb das Web mit der JavaScript-Welle, weil rudimentäre Tools wie selbstgeschriebene Suchmaschinen oder Text-Browser ohne JavaScript-Support und Client-Side-Rendering (das Google mit AngularJS gepusht hat) unbrauchbar wurden. Man hat so die Eintrittsbarriere in das profitable Kerngeschäft, nämlich eine durch Werbung finanzierte Suchmaschine, massiv erhöht und weiter die Marktanteile eigener Produkte zementiert.
Als drittes kommt dann die „Plattformisierung“ des Webs oben drauf: Content-Silos wie Facebook, YouTube oder Twitter töteten die ursprünglich verteilt angelegte Architektur des World Wide Webs. Statt einer Vielzahl von konkurrierenden und selbstverwalteten Alternativen gibt es im Web einzelne Monopolisten (YouTube, Whatsapp, Instagram, Facebook, Twitter).
Plattform-Modelle in Form von Betriebssystemen sind zwar uralt, aber erst seit Apple’s iOS gibt es einen harten Walled Garden. Konnte jeder Hobbyautor in den 1990ern Windows-Shareware entwickeln und vertreiben, so begann mit dem Apple Appstore der Untergang dieser freien Zunft: Nicht nur wird der Zugang irrational nach Gutsherrenart gewährt, sondern es wird auch noch großzügig Provision abkassiert.
Als ob diese beiden Beispiele schon nicht ausreichend, so hat sich dieser Trend auch auf Sytemsoftware ausgeweitet: Go ist das ideale Bespiel der geplanten Google-Dominanz. Zero dependency auf andere, existierende unabhängige OpenSource-Projekte, fast alles mittelbar zu 100% in der Hand von Google.
Wahrscheinlich erhofften sich Startups, die Go sehr früh eingesetzt haben, wie z.B. Docker und Hashicorp eine Partnerschaft oder einen Verkauf an Google, aber warum sollte Google Quellcode kaufen, der zu großen Teilen auf den Bausteinen der eigenen Entwicklung basiert und Nutzer bisher nicht exklusiv/hart an Google bindet?
Kubernetes orientiert sich z.B. nicht umsonst am Google-Architektur-Modell, kommt nicht umsonst mit Beispielen und „1st-class“ support für Googles Cloud-Services. Es geht hier darum, auch die gesamte Infrastruktur zu dominieren, wenngleich es hier mit Microsoft, IBM/Redhat und Amazon ebenfalls starke Konkurrenten gibt, die aber hier alle an einem Strang ziehen: Onpremise ist tot, verhafte die Kunden und melke sie bis zu ihrem Tod. Sie machen die Regeln, schreiben die Onboarding-Tools („OpenSource auf GitHub“) und liefern manchmal schon schlüsselfertigen Lösungen für die überschaubare jedoch alternativlose monatliche Zahlung von X$.
Am Ende steht die vollkommene Aufgabe der technischen Autonomie. Keiner soll mehr Software schreiben, verkaufen und betreiben können, ohne dass hierfür die Regeln und Preise von Google, Apple, Amazon oder Microsoft definiert werden.
Proprietäre Hardware, die sich diese Konzerne schon für ihre eigene Inhouse-Infrastruktur entwerfen und bauen lassen, stehen uns jedenfalls nicht zum Kauf offen, ja erfahren darüber auch so gut wie nichts. Wir müssen das verwenden, was auf dem Mainstream-Markt von Intel, AMD und den Mainboardherstellern angeboten wird. Stellt Apple nun wie schon lange erwartet auch macOS bzw. seine Macintosh-Linie von Intel/AMD64 auf proprietäre ARM/arm64 Prozessoren um, dann wird sicher auch ein anderer Player hier massiv Geld in die Hand nehmen und dies z.B. in der Cloud tun.
ARMs Patente und Architekturmodelle sind zwar gegen Geld lizenzierbar, doch das Salz in der Suppe sind die proprietären Erweiterungen und Designs, die Leistungsparameter und Energieverbrauch ausmachen. Diese zu Entwickeln und Umzusetzen kostet sehr viel Geld und erfordert Spezialisten-Know-How. Früher konnte deshalb ein Unternehmen nur wirtschaftlich überleben, wenn es durch den Verkauf der entwickelten (und produzierten) Chips einen Profit erzielt, also das „alte“ Modell eines Halbleiterherstellers (Intel, AMD).
Die oben angesprochenen Konzerne sind allerdings so vermögend, dass sie hier nicht mehr gezwungen sind, ihre Chips auch Dritten zugänglich zu machen. Es reicht eine kuratierte Software-Schnittstelle/ein SDK anzubieten und die Hardware dann in Form von Cloud-Produkten/Abos zu vermieten. Ohne Probleme wird z.B. Google ein paar Milliarden $ in Entwicklung und Produktion für Microchips investieren z.B. optimiert auf das eigene Tensorflow ML/KI-System zum exklusive Einsatz in der eigenen Cloud.
Somit werden wir dann alle endgültig zu Leibeigenen.
Mit Glück dürfen wir ein paar Brotkrumen aufsammeln, die uns die Großkonzerne überlassen, wenn wir unser gesamtes Arbeitsleben in von ihnen aus einer Hand kontrollierte Sprachen, Frameworks, Plattformen und Hardware investieren.
Und als Konsumenten zahlen wir natürlich auch dafür, dass Siemens, VW, Deutsche Bahn und sich diese proprietäre Hard- und Software in der Cloud mieten dürfen. So wie wir es seit 40 Jahren indirekt schon für SAP tun. Nur eben jetzt viel, viel umfänglicher.
Das Problem/der Benefit (je nachdem) ist, dass Software einfach skaliert. Ein Problem das man immer hat ist Distribution.. Viele würden vielleicht gerne ein Model 3 kaufen, aber es ist noch nicht verfügbar. Aber im Internet ist die beste Software, die beste Videoplattform, das beste Social Coderepo halt für alle weltweit verfügbar, und es gibt keinen Grund das zweitbeste zu nehmen. D.h. Programmierer sind eine enorm wertvolle Resource. Hast Du die besten und schaffst Du es nur 1% besser zu werden als die Konkurrenz, dann gewinnst du 90% des Kuchens (überspitzt formuliert). Github und Youtube sind wie McDonalds, die Du auch überall findest, nur werden sie jeden Tag etwas besser und hängen den Rest jeden Tag ein wenig mehr ab.
p.s. 1. Hast Du Ahnung und Lust etwas über das Verhältnis EU und Silicon Valley zu schrieben? Würde mich interessieren.. 2. Cooler blog 👍
1. Distribution geht auch wunderbar ohne Kubernetes, Docker und co. Man muss es halt nur richtig machen.
2. YouTube ist Monopolist, GitHub nicht. GitHub dient mittlerweile als Werbeplattform für Monopolisten, Astroturfing ist der „Fachausdruck“ für eine gekaufte Grassroots-Bewegung. D.h. auf GitHub wird etwas nicht populär, weil es vielen Leuten etwas bringt, sondern weil die besagten Konzerne ihren Code auch durch Veranstaltungen, Trainings etc. pushen. Ähnliches kann man auf Twitter beobachten wo eine ganze Horde an AWS-Mitarbeitern jedes noch so lahme neue Feature bewirbt. So gut wie keiner versteht, wie es *wirklich* funktioniert (tlw auch AWS-Mitarbeiter selbst nicht).
Der McDonalds-Vergleich hinkt, weil es auch noch 1000ende andere Fastfood-Ketten gibt und McDonalds keine absolute Marktmacht hat. Man ist der Marktführer, aber keiner geht jeden Tag zu McDonalds essen, wenn es nebenan noch die anderen populären Fastfood-Ketten gibt. Da ist viel mehr Konkurrenz und letztlich keine Abhängigkeit: Morgen geh ich eben dann halt zu KFC ohne bei McDonalds etwas zu verlieren zB Guthaben oder Investitionen in proprietäre Dinge.