[o1] Robin01
am 18.05. 11:04
+6
-
Finde ich gut. Das zeigt sehr gut, dass sich Open Source und Geldverdienen nicht ausschließen. Und ich mein echtes Geld und nicht nur Werbecash.
@Robin01: Richtig, siehe RedHat. Da wurde schon immer mit Freier Software Geld verdient. Zuerst über Fedora in der Community was dann später in der Enterprise Editionen übernommen wurde und auch zurück in den Upstream der Projekte zurückfliesst, wie zB. dem Linux-Kernel. Mittlerweile sind das Milliarden Umsätze.
na durch den kauf von github kann man die herde auch sanft in eine bestimmte richtung lenken und so eine entwicklung kontrollieren
@Blobbi.de: Passiert nur nicht. Deswegen wird GitHub ja weiterhin als eigenständiges Unternehmen geführt.
@Blobbi.de: Ich kann Dir garantieren, dass da nicht gelenkt wird. Es ist nicht mal möglich, als Microsoftler an GitHub Ressourcen zu kommen ;-)
Momentan setzt Microsoft erst mal alles daran, die GitHub-Produkte sauber anzugleichen. Denn da ist ein ziemlicher Wildwuchs zwischen GitHub Cloud, GitHub Enterprise Cloud und GitHub Enterprise Server. Und natürlich werden neue Funktionalitäten hinzugefügt, damit z.B. ein GitHub Actions alles das kann, was ein Azure Pipelines heute schon kann.
Momentan setzt Microsoft erst mal alles daran, die GitHub-Produkte sauber anzugleichen. Denn da ist ein ziemlicher Wildwuchs zwischen GitHub Cloud, GitHub Enterprise Cloud und GitHub Enterprise Server. Und natürlich werden neue Funktionalitäten hinzugefügt, damit z.B. ein GitHub Actions alles das kann, was ein Azure Pipelines heute schon kann.
@Blobbi.de: Wozu braucht man dazu Github? Die Lenkung von OpenSource-Projekten entsteht durch Diskussionen, Feature-Requests und vor allem den Commits. Wenn mir also eins Sorge bereiten würde, dann dass Microsoft Mitarbeiter dafür bezahlt OpenSource zu schreiben und ihnen erlaubt in ihrer Freizeit daran mitzuwirken.
Und trotzdem sieht man auch immer wieder die Nachteile, wenn z.B. große Projekte nicht mehr besonders viel Liebe erfahren und nicht mal mehr in der Lage sind, kleine Pull Request zur Fehlerbehebung anzunehmen. Da rege ich mich seit Monaten über IstanbulJS auf, denn da gibt es entweder gar keinen wirklichen Maintainer mehr oder aber die haben einfach keinen Bock mehr, etwas zu machen. Sonst wäre mein PR, der gerade mal eine handvoll Codezeilen ändert, gut getestet ist und einen wirklich nervigen Bug in der Generierung von Cobertura-Reports behebt, schon längst übernommen worden. Stattdessen wird man mit Ignoranz gestraft und prahlt gleichzeitig damit, dass das Projekt ja von 2,5 Mio. Projekten genutzt wird.
@HeadCrash: Das ist doch aber kein "open source"-Problem, oder? Ich mein, bei closed source Software hätte man höchstens einen Änderungswunsch einbringen können. Wenn dieser aber aufgrund von Inaktivität nicht gehört wird, würde man an der selben Stelle stehen.
Vielmehr ermöglicht open source ja sogar, einen Fork des Projekts zu erstellen, um die Änderung selbst einpflegen zu können. So erhalten Projekte ohne aktiven Maintainer die Möglichkeit auf eine Zukunft.
Vielmehr ermöglicht open source ja sogar, einen Fork des Projekts zu erstellen, um die Änderung selbst einpflegen zu können. So erhalten Projekte ohne aktiven Maintainer die Möglichkeit auf eine Zukunft.
@hurt: Jein. Natürlich könnte so etwas bei einem Closed Source Projekt auch passieren. Es dürfte aber nicht passieren, solange das eingesetzt Produkt noch im Support ist. Dann sollten Fehler immer behoben werden.
Und natürlich kann man forken. Aber das ist ja keine Lösung. Wenn man eine allgemeine Bibliothek oder ein Tool einsetzt, dann möchte man keine eigene Lösung bauen. Wo wäre da der Vorteil, die allgemeine Lösung zu benutzen. Man müsst ja jede Änderung in seinem Fork nachziehen. Da sehe ich viele dauerhaft geänderte Forks eher als Problem, denn plötzlich sprechen mehrere Menschen von Komponente A und meinen aber verschiedene Dinge.
Du hast natürlich recht, dass ein OSS-Projekt - zumindest in der Theorie - eher die Chance hat, von jemandem weitergeführt zu werden. Aber das setzt voraus, dass die bestehenden Maintainer das Projekt auch abgeben UND sich neue Maintainer finden. Da habe ich für beides schon Fälle gesehen, wo das eine oder andere nicht passiert und dann plötzlich eine weit verbreitete Komponente brachliegt.
Und natürlich kann man forken. Aber das ist ja keine Lösung. Wenn man eine allgemeine Bibliothek oder ein Tool einsetzt, dann möchte man keine eigene Lösung bauen. Wo wäre da der Vorteil, die allgemeine Lösung zu benutzen. Man müsst ja jede Änderung in seinem Fork nachziehen. Da sehe ich viele dauerhaft geänderte Forks eher als Problem, denn plötzlich sprechen mehrere Menschen von Komponente A und meinen aber verschiedene Dinge.
Du hast natürlich recht, dass ein OSS-Projekt - zumindest in der Theorie - eher die Chance hat, von jemandem weitergeführt zu werden. Aber das setzt voraus, dass die bestehenden Maintainer das Projekt auch abgeben UND sich neue Maintainer finden. Da habe ich für beides schon Fälle gesehen, wo das eine oder andere nicht passiert und dann plötzlich eine weit verbreitete Komponente brachliegt.
@HeadCrash: Wie Du richtig sagst, ist ein Fork eigentlich nur eine theoretische Möglichkeit. Bei einem größeren (!) Projekt in dem vielleicht mehrere Hundert Mannjahre Arbeit stecken, wird kein Externer mal eben einen Fork machen können. Forks sind nur für Mitarbeiter die in dem Projekt beiteiligt sind realistisch machbar. Aber da sind sie eine gute Möglichkeit. Bestes Beispiel ist Linux. Ein komplettes Linux zu forken ist vollkommen unrealistisch. Aber man kann auf die Basis, den Linux-Kernel, aufsetzen und dann einzelne Sachen darüber anders machen. Der Linux-Kernel wird inzwischen zu 90% von bezahlten Profis in Vollzeit entwickelt, nur noch 10% sind Hobbyentwickler die etwas beitragen. Und die Anzahl der Vollzeitentwickler sind über 1000. Wer glaubt, so etwas forken zu können, sollte sich dessen bewusst sein.
@HeadCrash: Aber das ist doch jetzt ein Problem der einzelnen Projekte und nicht von Github oder Microsoft... oder sehe ich da was grundsätzlich falsch?
@rallef: Es ist ein Problem von Open Source, das es ja theoretisch nicht geben sollte. Zumindest wenn man von der Idee ausgeht, dass jeder etwas beitragen kann/soll und natürlich die Projekte auch gewillt sind, solche Beiträge anzunehmen. Natürlich gibt es immer solche und solche Projekte und ich will auch gar nicht Open Source als solches schlecht machen. Es hat eben nicht nur Vorteile.
Und ja, so etwas könnte bei Closed Source auch passieren, der Frust wäre - zumindest für mich - nur ein anderer. Während ich mich bei Closed Source aufregen würde, dass ein Unternehmen offenbar nichts um seine Code-Qualität gibt, rege ich mich bei Open Source darüber auf, dass da offenbar jemand einfach nur zu faul ist, fünf Minuten zu investieren, um über ein wenig Code zu schauen und einen Butten zu drücken und damit den Aufwand desjenigen zunichtemacht, der sich die Mühe gemacht hat, das Problem zu beheben.
Und ja, so etwas könnte bei Closed Source auch passieren, der Frust wäre - zumindest für mich - nur ein anderer. Während ich mich bei Closed Source aufregen würde, dass ein Unternehmen offenbar nichts um seine Code-Qualität gibt, rege ich mich bei Open Source darüber auf, dass da offenbar jemand einfach nur zu faul ist, fünf Minuten zu investieren, um über ein wenig Code zu schauen und einen Butten zu drücken und damit den Aufwand desjenigen zunichtemacht, der sich die Mühe gemacht hat, das Problem zu beheben.
@HeadCrash: für mich sieht der Maintainer recht aktiv aus. Da wurde in den letzten Tagen, Wochen und Monaten fleißig PRs abgearbeitet.
@Robin01: Der Schein trügt. Es gab seit Januar zwölf bearbeitete PRs, von denen alleine fünf reine greenkeeper PRs waren. Da ging es also lediglich darum, dass der Automatismus eine Abhängigkeit aktualisiert hat. von den verbleibenden sieben PRs waren vier kleinere Fixes vom Maintainer (coreyfarrell) selbst selbst. Damit bleiben ganze drei echte PRs (mit echt meine ich in diesem Fall Contributions, die von außen kamen), die in den letzten fast fünf Monaten bearbeitet wurden.
Gleichzeitig sind noch sieben PRs offen und zieht man mal die beiden noch offenen greenkeeper PRs ab, dann bleiben fünf PRs, die zum Teil schon sehr alt sind (inkl. meinem, der aktuell der älteste ist), an denen nicht gearbeitet wird.
Was ich am wenigsten verstehe ist, dass der Maintainer offenbar selbst ja durchaus Zeit hat, ein paar Dinge zu machen, aber offenbar einfach keinen Bock hat, mal die Contributions anzuschauen.
Gleichzeitig sind noch sieben PRs offen und zieht man mal die beiden noch offenen greenkeeper PRs ab, dann bleiben fünf PRs, die zum Teil schon sehr alt sind (inkl. meinem, der aktuell der älteste ist), an denen nicht gearbeitet wird.
Was ich am wenigsten verstehe ist, dass der Maintainer offenbar selbst ja durchaus Zeit hat, ein paar Dinge zu machen, aber offenbar einfach keinen Bock hat, mal die Contributions anzuschauen.
@HeadCrash: eventuell überschätzt du die Brisanz und die Qualität deines Pull Requests ja auch ein wenig und der Maintainer hat wichtigeres zu tun. Just saying ...
@qmert: Es geht gar nicht um Brisanz, es geht um einen Qualitätsanspruch. Die Qualität meines PR ist gut. Dadurch gibt es tatsächlich überhaupt erst mal ein paar Tests, denn das Projekt ist absolut hemdsärmelig getestet.
Und ich kenne zig Unternehmen, die zigmal am Tag genau in diesen Fehler laufen. Vielen wird der nicht auffallen, weil sich kaum jemand seine Code Coverage Werte im Detail anschauen dürfte. Aber die, die genau hinschauen, ärgern sich, dass die Daten falsch sind.
Und zu guter Letzt ärgert mich, dass ich den Bug gemeldet habe und mit dem Hinweis abgespeist wurde, dass niemand im Team Ahnung von dem Teil des Codes hätte und man auf die Community angewiesen sei. Dann mache ich mir schon die Mühe, den Code zu analysieren, den Fehler zu isolieren und letztlich zu fixen und dann wird die Bemühung ignoriert. Das entspricht in meiner Vorstellung nicht gerade einem vorbildlichen Verhalten. Und wenn einem dann im Februar gesagt wird, dass aktuell viel los ist und man sich schnellstmöglich darum kümmern würde, man sich dann aber um alles andere kümmert, nur nicht um den PR, für den man Zeit zugesagt hat, dann wirft das wieder kein besonders gutes Licht auf das Projekt.
Und ich kenne zig Unternehmen, die zigmal am Tag genau in diesen Fehler laufen. Vielen wird der nicht auffallen, weil sich kaum jemand seine Code Coverage Werte im Detail anschauen dürfte. Aber die, die genau hinschauen, ärgern sich, dass die Daten falsch sind.
Und zu guter Letzt ärgert mich, dass ich den Bug gemeldet habe und mit dem Hinweis abgespeist wurde, dass niemand im Team Ahnung von dem Teil des Codes hätte und man auf die Community angewiesen sei. Dann mache ich mir schon die Mühe, den Code zu analysieren, den Fehler zu isolieren und letztlich zu fixen und dann wird die Bemühung ignoriert. Das entspricht in meiner Vorstellung nicht gerade einem vorbildlichen Verhalten. Und wenn einem dann im Februar gesagt wird, dass aktuell viel los ist und man sich schnellstmöglich darum kümmern würde, man sich dann aber um alles andere kümmert, nur nicht um den PR, für den man Zeit zugesagt hat, dann wirft das wieder kein besonders gutes Licht auf das Projekt.
@HeadCrash: immer locker bleiben viele Projekte sind hemdsärmlicher als sie von außen wirken, da ist aber auch bei vielen Closed Source Sachen so. Oft gibt es aber auf der anderen Seite viel unberechtigte Kritik von Leuten, die irgendwelche Bugs melden, die keine sind. Aber bei dir ist das nicht der Fall, deswegen Entschuldigung, das sieht schon so aus als hätte das Hand und Fuß und eine gute Qualität.
@qmert: Wie gesagt, es geht mir gar nicht um Qualität oder nicht. Ich bin für jede konstruktive Kritik dankbar. Ich ärger mich halt nur, wenn sich gar nix tut. Vielleicht auch einfach, weil ich aus der Branche komme und so was meinen Entwicklerstolz ankratzt ;-)
Und ja, es gibt sehr viel "schlechte" Qualität bei Software. Auf der einen Seite könnte man sagen, dass es kein Problem ist, solange sie korrekt funktioniert. Auf der anderen Seite vergleiche ich das immer mit einem Handwerker, der schlampig arbeitet. Da würde sich auch jeder drüber aufregen. Softwareentwickler (zumindest die mittelmäßigen und schlechten) sind bei so was aber leider extrem schmerzfrei. Das tut mir als Berater für Softwareentwicklung immer extrem weh, wenn man mit gestandenen Entwicklern großer Konzerne über die absoluten Grundlagen wie gutes Design, Testbarkeit und so einfache Dinge wie Unit Testing diskutieren muss, als wären es Weltwunder. :-/
Naja, steter Tropfen...
Und ja, es gibt sehr viel "schlechte" Qualität bei Software. Auf der einen Seite könnte man sagen, dass es kein Problem ist, solange sie korrekt funktioniert. Auf der anderen Seite vergleiche ich das immer mit einem Handwerker, der schlampig arbeitet. Da würde sich auch jeder drüber aufregen. Softwareentwickler (zumindest die mittelmäßigen und schlechten) sind bei so was aber leider extrem schmerzfrei. Das tut mir als Berater für Softwareentwicklung immer extrem weh, wenn man mit gestandenen Entwicklern großer Konzerne über die absoluten Grundlagen wie gutes Design, Testbarkeit und so einfache Dinge wie Unit Testing diskutieren muss, als wären es Weltwunder. :-/
Naja, steter Tropfen...