Google überholt Apple bei Webkit-Entwicklung

Seit wann ist Quantität über Qualität entscheidend?

Seit die Leute nicht mit Statistiken umgehen können. :P

Hat das irgendwer behauptet?

Da sieht man wie gut ein Open-source-Entwicklungsmodell funktionieren kann, wenn man sich erstmal überwunden hat, Code freizugeben und Änderungen anderer zu akzeptieren.
Apple hat halt erstmal 2 Jahre alles unter Verschluss gehalten, um andere gezielt auszuschließen.

man muss dem ganzen eine richtung vorgeben sonst wirds ja nur irgendein kit...

und in der basisentwicklung brauchts halt einen anfang wo net jeder reinpfuscht.

die basis war aber schon da als apple angefangen hat

Wieso "unter Verschluss gehalten, um andere gezielt auszuschließen"?

Apple hat den Sourcecode seiner Änderungen an KHTML schon 2003 mit dem Mac OS X 10.3 Sourcecode publiziert (siehe WebCore auf http://opensource.apple.com) und Patches eingepflegt. Es stand jedem offen, auf dieser Basis eigene Releases zu produzieren.

Seit 2005 gibt es zusaetzlich ein CVS und einen Bugtracker für das WebKit Projekt, das dauert halt, so eine Infrastruktur aufzubauen und den Code so umzubauen, dass er allgemeiner verwendbar wird. Dass sie den Aufwand betrieben haben, ist ihnen wohl zu danken, oder? Oh, nein, stimmt, wenn man Apple irgendwas dankt ist man automatisch ein Fanboy...

bis das CVS für externe entwickler geöffnet wurde!

Quelle: http://www.linux-magazin.de/NEWS/Schr... Entwickler

Da ging es um eine Richtlinie zum Reviewen von Checkins. Das Repository gibt es schon seit 2005, es stand seit damals jedem offen, edit Rechte zu beantragen, siehe folgenden Blogeintrag:

http://webkit.org/blog/5/in... illa-news/

was sie da gepostet haben - da geht es um die verwendung von bugzilla!

hier:
"Historically, new WebKit committers and reviewers have been chosen through an internal Apple process." - und das hat sich erst 2007 geändert!

http://webkit.org/blog/146/... er-policy/

übrigens ... ich weiss eh, man darf nix "böses" über apple sagen, sonst sehen die apple-jünger rot.

Wie du richtig feststellst konnte schon 2005 jeder einen commit Zugriff beantragen.

Dass es eine Weile dauert, bis genug externe Leute am Projekt beteiligt sind, die sich eine Vertrauensbasis geschaffen haben um anderen Commit Zugriff geben zu koennen, sollte dir aber auch klar sein. Darum ging es in der Policy Änderung, nicht darum überhaupt Zugriff zu erlangen.

Beim Firefox Projekt ist das auch ähnlich abgelaufen. Erstmals haben auch die Projektgründer (übrigens war daran auch Dave Hyatt beteiligt) Entwickler ausgewählt, die mitentwickeln durften. Erst als diesen genug Vertrauen geschenkt wurde, durften diese andere für Schreibzugriff auf das Projekt auswählen.

Ebenso lief es beim Chromium Projekt.

es macht einen unterschied, ob ein committer oder reviewer in einem undurchsichtigen und willkürlichen prozess durch apple bestimmt wird, oder ob dies durch einen geregelten und dokumentierten prozess gesteuert passiert!

bis 2007 herrschte absolute willkür von seiten apples!

Dieser strenge Review Prozess am Anfang war notwendig, um das Projekt in geordnete Bahnen zu führen.

Firefox wäre auch nicht zu diesem Erfolg geworden, hätten sie es am Anfang nicht ähnlich betrieben:

"In practice, these statements resulted in effectively locking everyone but the Firefox team out of the Firefox source code. "

"We were unnecessarily harsh, and polarized opinions. We had been badly wounded by the Netscape experience and the disorganization that had followed. I don't think a lot of people understood that. It wasn't something we could easily communicate."

Quelle: http://weblogs.mozillazine.org/ben/archi... 09698.html

http://www.pro-linux.de/NB3/news/... ander.html

es ist wirklich ein unterschied, ob man die minimalanforderungen aufgrund einer lizenz erfüllt, oder ob man mit der "community" zusammenarbeitet!

Gute Politik ist es, Änderungen kontinuierlich einzupflegen, denn nur so können mehrere Teilnehmer gut zusammenarbeiten. Schlechte Politik ist es, gemeinsam mit Releases riesige und schwer einpflegbare Patches zur Verfügung zu stellen und ein Projekt zu forken ohne den Fokus auch nur in irgendeiner Art zu ändern.

Beim WebKit Projekt werden Änderungen kontinuierlich eingepflegt und das sowohl von Google, Nokia als auch von Apple.

Kann man auf dem Tracker des Projektes gut mitverfolgen:

http://trac.webkit.org/

Suche mal nach google, nokia und apple email Adressen. Die kommen in den Commits der letzten Tage ungefähr gleich oft vor.

Ich weiß nicht mehr wie ich's sagen soll, damit du es verstehst:
Anfangs wurde überhaupt NICHTS kontinuierlich eingepflegt, die bloße Existenz von WebCore wurde geheim gehalten. Dann nach einem Jahr plötzlich die Änderungen rauszudumpen, die vermutlich zehntausende Codezeilen umfassen, ist für den Upstream ziemlich mühsam, wenn nicht wertlos, weil man nichts mehr automatisch reinmergen kann.

Das Probleme wäre nicht entstanden, hätte Apple ab der ersten Änderung ein öffentliches Repo gehabt, vollkommen unabhängig davon, ob das geforkte KHTML/WebCore in einem brauchbaren Zustand gewesen wäre oder nicht.

Ich habe dich schon verstanden.

Die Änderung in einem unbrauchbaren Zustand zu veröffentlichen, halte ich aber für nicht besonders hilfreich.

Darauf hat Google mit Chrome und dem dazugehörigen Chromium Projekt auch verzichtet. Sie haben die Entwicklung auch einige Zeit unter Verschluss gehalten, bis der Code reif für die Öffentlichkeit war.

Nicht hilfreich für jemanden, das daraus einen fertigen HTML-Renderer kompilieren will.

Sehr wohl hilfreich für den Upstream, der sich wesentlich leichter tut, laufende Änderungen in die eigene Codebasis einzupflegen.

Um nichts anderes geht's mir. Da hätte sogar ein read-only Zugriff auf's Repo gereicht.

Das Problem mit dem Zurückmergen war aber nicht der Zeitpunkt der Veröffenlichung, sondern dass mit WebKit ein neues API geschaffen wurde, um die Entwicklung zu vereinfachen.

Auch nach öffnen des Repositories hat deshalb das KDE Projekt nicht direkt von WebKit profitiert. Das wird erst mit dem Qt port von WebKit möglich, der derzeit vom ehemaligen Trolltech / heutigem Qt Software als Teil von Nokia weitergetrieben wird.

Das ist schnee von gestern, auch von Seiten der KHTML Entwickler, wieso sollte man 3 Jahre alte Geschichten wieder ausgraben?

Ich glaube du willst mich veräppeln. Ein Repository und einen Bugtracker aufzusetzen ist eine Angelegenheit eines Nachmittags. Der Code war von Stunde 0 allgemein verwendbar.. es war schließlich KHTML-Code.

Apple wollte gezielt einen nicht mehr kompatiblen Fork kreieren. Nach 2 Jahren geschlossener Entwicklung war das Endergebnis ja kaum noch mit dem Upstream zu mergen.

Der korrekte Ansatz wäre gewesen, gleich am Anfang zu sagen: wir nehmen jetzt den KHTML-Code und bauen ihn um, hier ist das Repo, ihr könnt mitmachen, oder halt nicht.

Wir das Apple gemacht hat ist wirklich schäbig. Ein anderer Ausdruck fällt mir nicht ein. Aber passend zur Unternehmenspolitik, möglichst nichts über die Zukunft zu kommunizieren.

omg, ihr programmierer seit ja so schlau. na, dann will ich hoffen, dass die firmen, die ihr sicher alle besitzt und leitet, so viel erfolgreicher sind als die firmen, über die ihr die ganze zeit herzieht...

Hast du Ahnung von Softwareentwicklung? Falls ja, solltest du wissen, dass Repository und der Bugtracker nicht das Hauptproblem sind.

Das 2003 freigegebene WebCore hat im Vergleich zu KHTML dank David Hyatt schon sehr viele Verbesserungen im Vergleich zur KHTML Engine gebracht und enthielt eine neue JavaScript Engine.

Diesen neuen Code portierbar zu machen, dauert seine Zeit. Ebenso muss Dokumentation zur Entwicklungsumgebung geschrieben werden und Policies zur verteilten Entwicklung überlegt werden, damit die Qualität aufrechterhalten werden kann.

Sowas macht man nicht in einer Nachmittagsschnellaktion, wie von dir vorgeschlagen.

Google hat aus ähnlichen Gründen auch lange intern an Chrome entwickelt, bis das Projekt reif war.

Apple boykottieren!