'GitHub is populairder dan SourceForge'

Volgens onderzoek is GitHub de populairste dienst voor het hosten van software, en heeft het daarmee onder andere SourceForge en Google Code ingehaald. GitHub bestaat pas drie jaar, terwijl SourceForge al sinds 1999 online is.

GitHub is inmiddels de meest gebruikte softwarehostingdienst, becijferde RedMonk. Tussen januari en mei van dit jaar werden op GitHub 1,2 miljoen bijdragen geplaatst, tegen 625.000 op SourceForge en 288.000 op Google Code. CodePlex van Microsoft was verreweg het minst populair; daar werden slechts 50.000 bijdragen geplaatst.

GitHub en zijn concurrenten laten softwareontwikkelaars online samenwerken aan opensourceprojecten. Dat GitHub de populairste tool is, mag opvallend heten; de site bestaat pas sinds 2008, terwijl SourceForge zijn diensten al sinds 1999 aanbiedt. Ook Google Code en CodePlex bestaan langer: respectievelijk sinds 2005 en 2006. Bovendien biedt GitHub, zoals de naam al doet vermoeden, enkel ondersteuning voor Git, terwijl SourceForge naast Git ondersteuning voor svn en Mercurial heeft.

De populariteit van programmeertalen verschilt per platform. Op GitHub zijn Ruby, Python en Javascript de populairste talen. Ruby is op SourceForge juist de minst voorkomende van de onderzochte talen; daar zijn C++, Java en C het populairst. Op Google Code en CodePlex zijn respectievelijk Java en C# de meest voorkomende talen.

Dienst	Opgericht	Aantal bijdragen tussen januari en mei 2011
GitHub	2008	********** 1.153.059
SourceForge	1999	***** 624.989
Google Code	2005	** 287.901
Microsoft CodePlex	2006	* 49.839

Reacties (58)

[Verwijderd]

De populariteit van programmeertalen verschilt per platform. Op GitHub zijn Ruby, Python en Javascript de populairste talen. Ruby is op SourceForge juist de minst voorkomende van de onderzochte talen; daar zijn C++, Java en C het populairst. Op Google Code en CodePlex zijn respectievelijk Java en C# de meest voorkomende talen.

Hoe zo appels en peren vergelijken?

GitHub host de meeste "script" taal projecten.
Terwijl SourceForge de meeste "compileer" taal projecten host.
De projecten op SourceForge zijn in de meeste gevallen waarschijnlijk veel groter.

Ik kon het me niet voorstellen, want ik trek de meeste C(++) projecten nog steeds van SourceForge, om te packagen.

[Verwijderd]

Ik denk dat het punt meer zit in het feit dat je je project niet zomaar verhuist, zeker niet als er veel collaboration gaande is, en als het niet nodig is.

Ook kun je zien dat er op github meer gecommit word aan C dan op SF om het dan over compileer-taal-projecten te hebben. C++ is voor github in stijgende lijn binnen dat plaatje.

SF bestaat veel langer, maar github zal de stokjes gaan overnemen vermoed ik.

Likewise, it is clear that GitHub should be core to your developer relations strategy. This is clear enough that large vendors such as VMware have begun leveraging GitHub as their primary external repository [coverage], both for the visibility it affords and the attendant developmental benefits.

But that kind of usage is obvious; less so is the growing trend of using GitHub as a de facto development resume [example]. Rather than attempting to indirectly evaluate their coding ability via on site artificial problem sets, employers are increasingly evaluating their work product itself, publicly available on GitHub.

[Verwijderd]

Ik denk dat het punt meer zit in het feit dat je je project niet zomaar verhuist, zeker niet als er veel collaboration gaande is, en als het niet nodig is.

Ook kun je zien dat er op github meer gecommit word aan C dan op SF om het dan over compileer-taal-projecten te hebben. C++ is voor github in stijgende lijn binnen dat plaatje.

SF bestaat veel langer, maar github zal de stokjes gaan overnemen vermoed ik.


[...]

De hoeveelheid commits zeggen niet zoveel.

Gimp, Wiresharf, fwbuilder, navit, megaglest etc zijn allemaal projecten waar het grootste deel van de code al geschreven is.

Ik vermoed dat ze naast elkaar blijven bestaan.
Met GitHub als hoster die ook commerciële projecten host.
En SourceForge voor openprojecten.

Waarom zou iemand perse voor de een kiezen? Terwijl de ander ook perfect voldoet.

[yiNXs]

Die constatering dat de een meer script talen en de ander meer compileer talen bevat is niet meer is dan slechts dat: een constatering, daar moeten niet direct conclusies uit getrokken worden.

Het lijkt me heel sterk dat de een veel meer geschikt is dan de ander voor specifieke talen. Als dat zo was zou die kennis al lang algemeen bekend moeten zijn, want al die developers hebben per slot van rekening die keus ook ergens op moeten baseren, ze werken niet op een of ander onderbuik gevoel.

Met bovenstaande berichtgeving zie ik het makkelijk gebeuren dat iedereen nu, op basis van volg-gedrag, de conclusie gaat trekken dat je voor taal A naar de een en voor taal B naar de ander moet.

De werkelijke reden ervoor is gewoon veel simpler. Github is nieuw, en de drie genoemde script/interpreter talen zijn ook pas sinds kort populair. De compilatie talen daarentegen bestaan al veel langer, net als sourceforge, en die zijn daarom daar het meest voor komend.

[wackmaniac]

Het aantal bijdragen hoeft natuurlijk niet per sé iets te zeggen over de populariteit van een service. Hoeveel projecten zijn er in die periode gestart, dat lijkt mij een veel representatiever voor de populariteit van een service. Om GitHub nog zo "jong" is zullen er een boel projecten op staan die ook nog maar jong zijn en een jong project heeft doorgaans meer bijdragen dan een project dat al langer loopt.

[Keneo]

Ik denk dat het hier gaat om het totaal aantal projecten. En dus niet bijdragen, of commits, want dan zou je een spectaculair veel hoger cijfer moeten zien.

De reden dat github zoveel meer 'projecten' heeft is omdat het zoveel laagdrempeligger is.

Je maakt in een halve seconde een nieuw project aan, iemand die iets wil aanpassen kan zelfs via de webinterface een fork, change en pull request doen zonder ooit zijn browser te verlaten, in enkele clicks. Alles werkt supper smooth met ajax etc...
Deze fork die mischien slechts 1lijntje code wijzigt zal echter wel weer als nieuw project geteld worden op naam van de gebruiker die de wijziging aanmakte deze keer, ipv het originele project met de originle autheur.

Doordat het zo laagdrempelig is heeft iedereen wel een aantal zeer kleine projectjes. vb een 'project' van mij: https://github.com/jenstimmerman/scripts
Dit zijn slechts 2 files.

Voor zoiets zal je nooit naar google code of sourceforge grijpen, echter in github het aanmaken van een nieuw project een kwestie van 4keer klikken en wat code pasten, of een

git remote add origin [e-mail]:username/newrepo.git
git push origin master

Verder is er ook een social aspect aan github, je kan bvb je vrienden (of projecten) volgen en updates ontvangen.

[Reactie gewijzigd door Keneo op 22 juli 2024 19:54]

[Lord Daemon]

Het lijkt me wel dat het om het aantal commits gaat. Meer dan één miljoen nieuwe projecten tussen januari en mei van dit jaar zou juist een absurd hoog aantal zijn, toch? Terwijl een miljoen commits best veel is: de Linux-kernel heeft per versie (is denk ik drie maanden?) in de orde van grootte 10.000 commits, en dat is een zeer groot project.

[Xthemes.us]

Wel een aantal verrassingen bij deze cijfers voor mij.
Had niet verwacht dat java de populairste taal op Google Code was, er staan namelijk enorm veel javascript scripts op, vooral een hele hoop jquery plugins. En een webtaal lijkt me toch ook nauwer aansluiten op 'google'.

Dat GitHub groter is dan sourceforge vind ik ook vrij verbazingwekkend, lees wel over een hoop projecten (uit de Linux) wereld die hun svn naar git verhuizen maar had niet verwacht dat dit (al) de grootste zou zijn. Kreeg het zelf ook niet voor elkaar om gebruik te maken van Git, maar waarschijnlijk te vroeg geprobeerd want de documentatie was toen nog vrij magertjes waardoor ik op SVN ben blijven plakken.
Bedenk me net dat GIT dan ook bij verre het meest populaire version system is, in gebruiksaantallen zijn ze al de grootste, als je dan ook nog de GIT repositories van sourceforge bij optelt dan is het wel een enorm success.

Niet slecht gedaan door Linus dan, die heeft de basis van Git binnen no-time opgezet en nu is het al zo'n overweldigend succes. De google tech talk waar hij presenteert en Git uitlegt is trouwens aardig amusant

[nuuwnhuusk]

Android draait op Java, dit zal wel meespelen met het feit dat er op Google Code zoveel Java te vinden is.

[gimbal]

Had niet verwacht dat java de populairste taal op Google Code was, er staan namelijk enorm veel javascript scripts op, vooral een hele hoop jquery plugins. En een webtaal lijkt me toch ook nauwer aansluiten op 'google'.

Het kan helpen dat java.net best wel een rommel geworden is sinds Oracle de baas is en alles in een traag migratietraject heeft gegoten. Het lijkt erop dat de nieuwe java.net portal live is echter, dus wellicht dat er weer een verschuiving plaats gaat vinden de komende tijd.

[ZpAz]

Google's web-framework? (Ben de naam kwijt) werkt ook op basis van Java, als je bij hun in de cloud wil hosten zit je momenteel ook gebonden aan Java (volgens mij komt Python support er aan).

[YopY]

GitHub's populariteit kan ik zeer goed begrijpen. In tegenstelling tot de klassieke projecthostingsites biedt Github (en Git zelf) eigenlijk een social network voor softwaredevelopment. Bij Sourceforge en SVN mag je lokaal een checkout doen van een project, hacken en een patchfile opsturen en maar hopen dat het geaccepteerd wordt, of je mag een fork starten als een losstaand project.

Bij Github daarentegen maak je een fork aan op github zelf met één druk op de knop, je doet je wijzigingen, pusht ze naar Github, en iedereen kan het gelijk gebruiken. Weinig moeite en extra stappen vanuit de ontwikkelaar. De ontwikkelaars van het originele project kunnen de fork zelf binnenhalen en uittesten, en het zonder moeite weer samenvoegen met hun eigen project.

En wat misschien nog belangrijker is, je houdt het overzicht op je project en wat iedereen ermee doet, dankzij de overzichtelijke visualisatie. Bekijk dit project bijvoorbeeld, je kunt precies zien wie wanneer jouw project geforked heeft en waar die mee bezig is.

[Reactie gewijzigd door YopY op 22 juli 2024 19:54]

[Xenan]

Dat vind ik wel interessant. Op codeplex heb ik ook wel eens een fix gepost maar die werd nooit opgenomen, net als de tientallen fixes voor mij. Blijkbaar kan ik het gaan forken nar Github en zelf verder gaan met het project. Natuurlijk kan het ook zonder Github maar heel makkelijk is het niet.

[Typhoner]

Een min of meer gelijkaardige dienst als GitHub is Gitorious. Deze gebruikt ook Git als revisiesysteem, nodigt ook zeer sterk uit tot forken, etc. Enkele grote projecten als Qt, Amarok, XBMC, .. gebruiken Gitorious.

Het verschil zit 'm in het feit dat op GitHub een repository bij een gebruiker hoort. Als jij een projectje start, komt de repo ervan onder jouw gebruikersnaam te staan. Als mensen een fork maken, komt die dan weer onder hun naam, met een linkje naar het orgineel. Als jij dan een merge request doet naar de beheerder van een repo, stuur je in principe gewoon een privé-berichtje, wat ik eiegenlijk niet zo "sociaal" vind.

Bij Gitorious maak je echt een project aan, en alle clones vallen dan onder dat project (maar met andere eigenaars). Verder zijn merge requests daar publiek: de diff wordt grafisch weergegeven, en iedereen kan commentaar leveren. Het is dan ook mogelijk om de merge request aan te passen. Zoiets nodigt echt uit tot samenwerken. Persoonlijk vind ik Gitorious dan ook toffer.

[tszcheetah]

Het onderzoek maakt niet duidelijk wat voor projecten zijn gemeten. GitHub heeft voor zover ik weet daarbij één voordeel tegenover de rest: gesloten projecten.

Omdat bij GitHub het mogelijk is om een privé project te starten, is het een goede kandidaat voor bedrijven en particulieren om hun software te plaatsen. Je hoeft geen moeite te doen om de nodige infrastructuur op te zetten, terwijl je wel alle voordelen van Git hebt. Daarnaast hoeft je testprojectje of broncode dus niet openbaar te zijn, wat toch een drempel kan zijn. Voor zover ik weet is openbare code bij SF en Google Code wel verplicht, van CodePlex weet ik het niet.

Neemt niet weg dat, zeker voor nieuwe projecten, SourceForge toch aardig achter de feiten aanloopt tegenover GitHub en Gitorious bijvoorbeeld.

[Sebazzz]

Op CodePlex heb je ook Microsoft Team Foundation Server support, wat een complete projectserver is. Het is dus niet heel gek dat daar C# het populairst is

[MisterBlue]

Opvallend is wel dat het verschil tussen aantal C# commits op CodePlex en GitHub niet al te groot is: http://www.flickr.com/photos/sog/5791038010/.

Als het zo doorgaat heb je straks meer C# commits op GitHub dan op CodePlex.

[Ayporos]

Hmmm...

Ik vraag me af hoe deze cijfers relateren met closed-source / open-source software en closed-projects (zelf-hosted) en open-projects (door een van deze sites gehost).

Kan me namelijk voorstellen dat veel 'microsoft' (lees: C#/'professionele' code) nog wel eens closed-projects gehost zijn en dat dàt dit verschil veroorzaakt.

Het is dus belangrijk dat men beseft dat deze cijfers nìet representatief zijn voor "hoeveel wordt er met een bepaalde taal gecodeerd", maar enkel "hoeveel wordt er met bepaalde talen gecodeerd die op zo'n site gegooid worden".

+-90% van de 'servers' draait op Linux, maar op professionele (bedrijfs) servers draait dan weer vaker windows server.. ik vermoed dat zo'n zelfde soort verhouding ook wel eens op zou kunnen gaan m.b.t. het version controllen van projecten.

[awulms]

+-90% van de 'servers' draait op Linux, maar op professionele (bedrijfs) servers draait dan weer vaker windows server..

Volgens mij draait op professionele servers nog altijd vooral een commerciele unix variant, al is linux wel met een zeer serieuze inhaalslag bezig.

[Reactie gewijzigd door awulms op 22 juli 2024 19:54]

[Dreamvoid]

De trend is al een tijdje dat Windows *en* Linux marktaandeel winnen van de commerciele Unixen

[MisterBlue]

Kan me namelijk voorstellen dat veel 'microsoft' (lees: C#/'professionele' code) nog wel eens closed-projects gehost zijn en dat dàt dit verschil veroorzaakt.

Als een shop voor zijn closed-projects geinvesteerd heeft in Team Foundation Server, zal het eerder geneigd zijn om CodePlex te gebruiken voor code die het wil delen met de rest van de wereld.

Geen beschikking tot Team Foundation Server, dan blijkt GitHub dus het volgende alternatief

[Mikke8]

En ook heb je op SourceForge Bazaar
http://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar

[ride277]

Best gek, download regelmatig wat van sourceforge, maar eigenlijk nooit wat van GitHub, had er ook niet echt van gehoord.

[Gerco]

Het lijkt mij komen omdat GitHub het ontzettend simpel maakt om mee te werken aan software. Je klikt op de fork knop, maakt je wijzigingen en stuurt een pull request. De originele auteur hoeft dan alleen nog maar op ok te klikken om je aanpassingen te accepteren.

GitHub houdt bij welke forks er allemaal zijn en wat hun relatie tot elkaar is. Veel handiger dan patches via email en je hoeft niet op commit toegang tot 1 of andere repo te wachten om mee te kunnen doen.

[Reactie gewijzigd door Gerco op 22 juli 2024 19:54]

[kokx]

Beter nog, github maakt het zelfs nog gemakkelijk om aan software te werken die niet origineel op github gehost word. Je kan er gewoon elke git repository naar pushen. En met git kun je vrij veel repositories importeren.

Als voorbeeld hiervan, zijn er op github erg veel forks van de Kernel te vinden. Gewoon omdat github een mooie service is om jouw code te publiceren. En daarna kan iedereen gewoon bij jouw changes..

[MacWolf]

Voor iOS frameworks en libraries lijkt github "the place to be", haal eigenlijk vrijwel nooit ergens anders code vandaan. Gezien ontwikkeling voor iOS tegenwoordig toch wel erg groot is, lijkt me dat ook een aanzienlijke bijdrage te hebben geleverd aan de populariteit van github.

Edit: hmm, blijkbaar had ik bovenstaande toch verkeerd ingeschat. Objective-C staat op plek 11 qua populariteit. Zie: https://github.com/languages

[Reactie gewijzigd door MacWolf op 22 juli 2024 19:54]

[Wannial]

Ik ken enkel SourceFourge, daarnaast gebruik ik ook erg vaak filehippo, maar die staat niet in dit lijstje, van de andere wist ik het bestaan nieteens af..

[Anoniem: 282252]

Wannial,

als je niet van de andere wist dan ben je duidelijk geen programeur, filehippo lijkt wel een site om binaries te delen.

githib is bedoeld om sourcecode te delen met git, niets meer en niets minder. De wiki, website en issue tracking zijn zeer matig ivm SF.

SF is te laat in de gitboot gesprongen, en alhoewel ze momentel wel git ondersteunen, is de implementatie via de website ronduit slecht tov github.
De tracking software van SF is erg sterk voor een gratis product, zeker tov git waar je eigenlijk alleen issues hebt, en zelfs een pull-request is een issue, yuk....

Als SF git ondersteunde als github dat zou doen, en als SF nu eens wat sneller werdt, dan zou ik weer terug gaan naar SF.

Mijn Project: https://github.com/LibreCAD/LibreCAD

[Wannial]

Dat klopt, ik heb niets met het hele programmeren te maken.
Ik zie net dat ik sourcefourge met een andere site verwar in mijn hoofd, en dat ik daarom de filehippo er bij haal, mijn fout.

[Verwijderd]

Zelf ben ik ook tevreden gebruiker van GitHub. Voorheen had ik een eigen server waarop ik Git gebruikte, maar voor een paar tientjes per maand heb ik alles nu uitbesteed aan een partij wiens core-business het is.

Ook heeft GitHub goed gesnapt dat je beter één ding goed kan doen, dan drie dingen half. Git is in mijn ogen het beste DCVS dat er momenteel is, wat wellicht ook bijdraagt aan het succes van GitHub. De gebruiksvriendelijke interface, en duidelijke en heldere uitleg geeft mij meer vertrouwen dan een oude rot als sourceforge.

Vergelijk bijvoorbeeld eens de homepage van sourceforge.net en github.com als je niet ingelogd bent. Een wereld van verschil. Bij GitHub is een duidelijke focus op uitleggen wat het concept inhoudt, en wat de voordelen en mogelijkheden zijn. Bij sourceforge staat alleen een lijst met projecten van de maand.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:54]

[YopY]

Git is in mijn ogen het beste DCVS dat er momenteel is, wat wellicht ook bijdraagt aan het succes van GitHub.

En andersom ook, volgens mij - Git is deels zo bekend en populair vanwege GitHub.

[Verwijderd]

[...]


En andersom ook, volgens mij - Git is deels zo bekend en populair vanwege GitHub.

Ik denk dat GIT vooral bekend is dankzij Linuz en de Linux kernel.

Git is a distributed revision control system with an emphasis on speed. Git was initially designed and developed by Linus Torvalds for Linux kernel development. Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Git's current software maintenance is overseen by Junio Hamano. Git is free software distributed under the terms of the GNU General Public License version 2.

[Thundy]

Dat denk ik eigenlijk niet.

De linux kernel wereld is echt een héél stuk kleiner dan de software wereld die gebruik maakt van de (open source) projecten die via GitHub worden ontsloten.

Persoonlijk ken ik GIT ook via GitHub en niet andersom

[DeuTeRiuM]

Ik gebruik voornamelijk codebase, ook erg fijn! Zeker voor prive projecten. Het ticket systeem daar is uitgebreider en daarnaast heb je nog wat andere tools zoals timetracking.

SF.net is ook zo mega traag en de interface is erg onhandig. Zinkend schip, al enkele jaren.

[BtM909]

Vergelijk bijvoorbeeld eens de homepage van sourceforge.net en github.com als je niet ingelogd bent. Een wereld van verschil. Bij GitHub is een duidelijke focus op uitleggen wat het concept inhoudt, en wat de voordelen en mogelijkheden zijn.

Wat op zich logisch is omdat de een in '99 is begonnen en de ander in '08

De laatste is bezig geweest met zichzelf positioneren en wil je de grootste worden, dan moet je heel duidelijk maken wat jij wel doet (en eventueel anderen niet). Blijkbaar hebben ze dat kunstje heel goed uitgevoerd

[hr]

Het is idd mooi om te zien dat een markt als deze ook wordt "opengebroken" door jonge spelers die het spelletje EN snappen EN dit dus snel en goed grootbrengen.