[opensource] Wie schrijft het?

[Precision]

Zoals de titel reeds vermeld, ben ik eens benieuwd naar hoeveel tweakers een opensource project steunen of zelf hebben gestart? Ik heb niet echt een idee waar het juist thuis hoort en als het hier niet thuis hoort m'n excuses. Maar ik ben eigenlijk vooral benieuwd naar wie een opensource project heeft of steunt en vooral waarom? Wat is de drijfveer? Want je weet dat er een hoop bs bijkomt van mensen die onterecht zeggen dat iets niet werkt terwijl ze de readme.txt niet hebben gelezen, etc.
Ik zelf schrijf plugins voor wordpress. Waarom? Omdat ik het zelf gebruik en mijn oplossingen - voor de in mijn ogen gebreken - graag deel met de community. Het is tof omdat er al een grote userbase is en je plugin dus sowieso minstens door 1 ziel wordt gebruikt. En het staat fijn op een cv.
Een verdoken vraag van mijn kant, *snip* (Als deze vraag niet mag, mod maar weg, had graag wel m'n topic gehad )

Zo werkt 't niet he? Als het niet mag, haal dan maar weg

[ Voor 36% gewijzigd door RobIII op 15-12-2010 23:37 ]

[Nick_S]

Ik kom meestal niet verder als het maken van patches voor bugs waar ik met m'n werk tegenaan loop. Ik heb het regelmatig, dat ik de ene dag m'n projectleider moet vertellen dat er een bug in een bepaald pakket zit, en dat dan de volgende dag op "magische" wijze er een nieuwe release is van dat pakket.

Of als dat niet lukt, dan bakken we zelf een versie met de patch, die we onder een eigen versienummer intern releasen. Wel de patch bij het issue indienen en in de gaten houden, zodat we zo snel mogelijk weer van onze versie af zijn.

Pakketten waar je dan aan moet denken, zijn bijvoorbeeld Jackrabbit (JCR RI), Hibernate (JPA implementatie), Spring Core (DI framework) en div. Maven plugins.

[Gerco]

Ik ontwikkel Sonic Message Manager. Ben ermee begonnen omdat ik iets beters wilde dan de JMS Test Client die bij SonicMQ wordt meegeleverd en omdat 1 van mijn klanten een soort voorloper van deze tool had laten maken in werktijd.

Ik ben toen van scratch begonnen in mijn eigen tijd en heb deze tool geschreven. Drijfveren zijn vooral eigen gemak (ik gebruik het zelf ook), respect van mijn collegas (zowel binnen als buiten mijn eigen bedrijf) en naamsbekendheid (op conferenties hoor ik met enige regelmaat: "Aha, ben *jij* dat?!").

Verder heb ik in het verleden weleens wat bugs opgelost in verschillende open source projecten (qmail, zabbix) en release ik wat tools en libraries als open source (o.a. Zabbix gerelateerd). Die schrijf ik omdat ik ze zelf nodig heb en alleen voor mezelf houden vind ik zonde. Verkopen is teveel moeite dus dan maar open sourcen, dan hebben anderen er misschien ook nog wat aan en het kost mij geen extra moeite.

[H!GHGuY]

ServerChecker (GPLv2) is mijn schrijfsel. Ik heb een tijdje terug de 4de versie op een SVN server gedumpt zodat anderen er aan kunnen verderwerken. Mijn prioriteiten zijn wat verschoven en dat zorgt dus dat ik er niet aan verder kan.

Er zit ook al wat code van mij in de Linux kernel en ik broed al langer op een idee voor de kernel, maar geraak er niet aan toe. Vanuit mijn werk ben ik ook veel bezig met OS (beide betekenissen van het woord) en ik heb me dan ook voorgenomen om wijzigingen te upstreamen waar mogelijk/nuttig.

[MsG]

Ik help regelmatig met vertalingen, omdat ik me er dood aan kan ergeren als iets slecht Nederlands is, maar in plaats van alleen maar te ranten kan ik ook bijdragen was mijn idee.

Ik vind de mindset van de meeste Open Source-software erg mooi. Ipv streven naar zoveel mogelijk winst met zo weinig mogelijk nieuwe features (zoals Adobe het het liefst zou zijn bijvoorbeeld) heeft men tot gezamenlijk doel om een goed product te maken. Het voelt voor mij als een wat dieper en minder egoïstisch doel dan domweg "winst genereren".

[RayNbow]

Precision schreef op woensdag 15 december 2010 @ 23:28:
Maar ik ben eigenlijk vooral benieuwd naar wie een opensource project heeft of steunt en vooral waarom?

Ik sleutel zo nu en dan aan Tribler...

Wat is de drijfveer?

...maar daar word ik dan ook voor betaald.


Voor de rest steun ik open source projecten voornamelijk door bugs te reporten als ik ze tegenkom (voorbeeld). De bugs zelf fixen gaat mij wat te ver (die tijd heb ik niet).

[EfBe]

Veel open source geschreven in het verleden en nog steeds:
* LLBLGen v1, SQL Server stored proc + call class (C#/VB.NET) generator. Source niet meer beschikbaar
* DemoGL, OpenGL/C++ demo system. Oude versie staat nog ergens op sourceforge
* HnD, ASP.NET / C# / SQL Server based forum en helpdesk systeem (wat we zelf gebruiken). Source op bitbucket: https://bitbucket.org/Solutionsdesign/hnd
* BCL Extensions. .NET 3.5+ extension method library. Source op Codeplex: http://bclextensions.codeplex.com/
* Algorithmia. .NET 3.5+ algorithm en datastructure library. Source op Codeplex: http://algorithmia.codeplex.com/

Waarom? De code is geschreven omdat het nodig was Waarom het gereleased is als open source is voor een deel marketing voor ons bedrijf en ons product LLBLGen Pro. De grootste drijfveer is echter het mogelijk maken voor anderen om voort te bouwen op wat ik heb gemaakt. Ik doe geen research aan een universiteit, maar zie dit wel als iets waarbij mensen, naast blog posts etc., dit kunnen gebruiken om hun kennis en kunde aan te vullen en te verbeteren. Zeker Algorithmia is zo opgezet: om .NET ontwikkelaars die nooit een algorithm book hebben gelezen, toch kennis te laten maken met bestaande algorithms zodat ze leren inzien dat problemen, veelal door de-compositie in kleinere algorithms, makkelijker op te lossen zijn dan ze denken.

[roy-t]

Voor Farseer Physics heb ik een uitgebreide starters tutorial gemaakt. Maar qua code heb ik (nog) niet bijgedragen aan OS. Dat vind ik overigens altijd erg moeilijk omdat vooral bij kleine projecten het heel erg moeilijk is om dingen met elkaar af te stemmen. Ik kan meestal niet 'zo even' op IRC hoppen om te vragen of ik dit en dat even kan doen. En wat de best-practices in het project zijn.

Op dit moment ben ik bezig met wat "public domain" code te upgraden naar XNA4.0, wat ook wel handig is, dit gaat natuurlijk terug naar de originele auteur.

[Sv3n]

Heb een aantal patches voor Hibernate (Java orm) en Wicket (Java web framework) gemaakt. Dit is eigenlijk alleen als ik zelf een bug tegenkom. Bij het schrijven van de testcase voor de bugmelding zie ik meestal ook wel gelijk de fix en submit ik die gelijk.

[djc]

Ik werk mee aan Mercurial, Python en Gentoo Linux, en heb fixlib gereleased (een Python library voor het FIX protocol). Ik werk over het algemeen aan dingen die ik zelf gebruik of nodig heb (voor eigen projecten of werk). Daarnaast vind ik het leerzaam om samen te werken met andere goede, gedreven ontwikkelaars, waarvan ik er eigenlijk in mijn directe omgeving maar heel weinig ken.

[djc]

roy-t schreef op donderdag 16 december 2010 @ 12:57:
Dat vind ik overigens altijd erg moeilijk omdat vooral bij kleine projecten het heel erg moeilijk is om dingen met elkaar af te stemmen. Ik kan meestal niet 'zo even' op IRC hoppen om te vragen of ik dit en dat even kan doen. En wat de best-practices in het project zijn.

Vooral bij kleine projecten zijn ze al blij als je een patch stuurt per mail die op een enigszins praktische manier het probleem oplost waar je tegenaan loopt. Als je vervolgens ook nog wil reageren op eventuele verbeterpunten aan die patch is het nog beter. Wees niet bang! Zou vooral niet beginnen met studeren op de best practices, juist niet bij kleinere projecten. Hou je alleen een beetje aan de coding style zoals je die tegenkomt in de omringende code.

[AtleX]

Ik heb ik de loop der tijd voor een aantal projecten patches ingestuurd of ideeën doorgegeven (PHP, verschillende PHP frameworks, AnkhSVN, Notepad++, etc.) en daarnaast heb ik zelf wat software of libjes als open source online gezet. De reden dat ik dat doe is eigenlijk dat ik veel open source software gebruik, een behoorlijk aantal mensen ken die het ontwikkelen en omdat ik er als gebruiker vaak invloed op uit kan oefenen wordt de drempel om er wat voor te doen ook een stuk kleiner.

[YopY]

Ik zou wel graag mee willen werken aan open source projecten, maar in de praktijk gebruik ik ze in mijn werk niet of nauwelijks, of zijn de projecten al te groot om nog bij te komen (heb ik het idee). De enige manier waarop ik er aan mee zou werken is als ik via mijn werk eraan werk, of als het iets is dat ik (of een vriend / kennis) zelf opstart.

Had wel graag gewild dat het CMS waar ik mee werk open source was, d'r zit zoveel in dat gefixed moet worden...

[NMe]

Ik heb ooit een keer een simpele filmdatabase gemaakt met wat klasgenoten waarvan de source vast nog wel ergens rondzwerft. Sowieso wordt het zaakje nog gebruikt en heeft iemand zelfs een mod gemaakt om het te laten werken voor Duitse wetsteksten.

Ik heb daarna wel geleerd dat open source een leuk idee is op papier, maar dat het in de praktijk gewoon niet goed genoeg werkt. Je kan niet goed even samen brainstormen. Veel projecten hebben niet echt een structuur of een fatsoenlijke chain of command, en maar al te vaak zie je bij de maker een mentaliteit van "het werkt voor mij en als jullie het anders willen zoeken jullie het maar uit". Om die reden zul je mij niet snel aan open source-software zien werken in mijn vrije tijd.

[Comp_Lex]

Ik ben de developer van Sokath (http://sokath.sourceforge.net/). Het domein van het programma is energie en klimaatverandering. Momenteel is het een simpele tool waarmee je de olieproductie, olieprijzen en benzineprijzen kan voorspellen voor verschillende gebieden in de wereld voor de komende decennia. Het wordt later uitgebreid met simpele klimaatmodellen, duurzame energie, etc.

[Anoniem: 12795]

Ik werk al jaren met MapWindow GIS (www.mapwindow.org), eerst als gebruiker, toen als bug melden/fixer en nu als release en configuratie manager: Ik probeer er voor te zorgen dat de verschillende programmeurs mekaar niet in de weg zitten, dat men zich houdt aan de coding styles en dat er regelmatig (geteste) releases worden vrij gegeven.
Het meeste doe ik in mijn vrije tijd, maar door mijn track record word ik inmiddels ook gevraagd om betaald specifieke bugs te fixen of enhancements toe te voegen.
Enigszins betaald heb ik net KLIC Maat (www.klicmaat.nl) ontwikkeld, die weer gebaseerd is op MapWindow.

Zoals al eerder genoemd, vind ik het community gevoel erg belangrijk. Je leert ook nieuwe mensen kennen van uit de hele wereld. Ik heb bijna dagelijks contact met mensen uit Amerika, Canada, Wit-Rusland en Maleisië.
We verwelkomen iedere nieuwe ontwikkelaar en we proberen met elkaar een goed product af te leveren.

Je komt ook nog ergens. Begin dit jaar ben ik gevraagd om op de 1e internationale conferentie van MapWindow in Orlando te komen presenteren. En ik heb al weer een uitnodiging voor april in Delft en juni in San Diego.

En zoals ook genoemd. Het staat ook goed op je CV. Inmiddels ben ik in de positie dat ik af en toe mag mee beslissen of iemand wordt aangenomen of niet. Als dan op de CV staat dat die persoon actief is in een Open-Source community, dan heeft die persoon bij mij een streepje voor.

[creator1988]

Ik heb FMSE geschreven, een framework voor het ontwikkelen van Ingame Scouts en Editors voor Football Manager 2011 (en 2010 en 2009). Wordt gebruikt door FMRTE, FMAssistant en nog een hoop meuktooltjes. In totaal zijn die applicaties een paar honderdduizend keer gedownload.

Anyhow, ik vind het vooral leuk om nieuwe tools te zien, en ik heb zelf geen zin om GUI's te schrijven. Vandaar dat ik het meer 'out in the open' heb gegooid. Maar qua contributers valt het me best tegen, er schrijven nu drie mensen (inclusief mij) semi-actief aan de code. Desondanks vind ik het wel prettig om helemaal los te kunnen gaan met AOP, MSIL injection, design patterns etc.

[JaWi]

Ik ben met de ontwikkeling van OpenBench Logic Sniffer client begonnen, omdat de originele client niet langer ontwikkeld werd, en er wel een hoop interesse in is. Daarnaast wilde ik mijn kennis van UI-programmeren, OSGi en bus protocollen wat verbeteren.

Verder probeer ik opensource projecten waar ik veel mee werk wel te voorzien van bugreports en/of fixes. Ik vind dat wel zo sociaal als je zonder (of met weinig) kosten gebruik maakt van het werk van anderen.

[user109731]

Ik heb een aantal patches ingestuurd naar projecten als PyPy en V8 (Chrome's JS engine). Momenteel draag ik vooral bij aan Mozilla's JS engine. Erg gaaf en leerzaam, en ik doe gelijk wat ervaring op.

Een eigen project in die richting leek me ook wel leuk, maar dat kost een hoop tijd en het is de vraag of het ooit iets word. Daarom richt ik me vooral op het verbeteren van bestaande projecten, dat houd het leuk

[ Voor 35% gewijzigd door user109731 op 16-12-2010 23:38 ]

[RobIII]

We dragen (op de zaak) actief bij aan Asterisk en Chan-SCCP middels patches, testing en bugreports (en een aantal deelnemers (coders) hebben we gratis voorzien van de juiste hardware om mee te testen; dat vind ik ook een leuke manier van bijdragen). Verder doe ik, prive, regelmatig aan bugreports en eventuele suggesties voor patches in vanalles en nog wat; als het me genoeg irriteert of me voldoende waard is om er eens voor te gaan zitten dan ben ik de lamste niet

[ Voor 23% gewijzigd door RobIII op 16-12-2010 23:48 ]

[WernerL]

Wel eens een bugje gereport, 1 keer een vertaling geschreven omdat ik het in het Nederlands wilde hebben en de enige vertaling brak was. Verder experimenteer ik veel en deel ik de code van alles wat ik schrijf op mijn blog. De drijfveer is om andere developers (hoop ik) dingen te kunnen leren die ik al begrijp. Laatste tijd trouwens weinig sourcecode gepost.. Maar die lever ik graag op aanvraag iig.

[ Voor 13% gewijzigd door WernerL op 17-12-2010 01:13 ]

[Freeaqingme]

NMe schreef op donderdag 16 december 2010 @ 15:29:
Ik heb daarna wel geleerd dat open source een leuk idee is op papier, maar dat het in de praktijk gewoon niet goed genoeg werkt. Je kan niet goed even samen brainstormen. Veel projecten hebben niet echt een structuur of een fatsoenlijke chain of command, en maar al te vaak zie je bij de maker een mentaliteit van "het werkt voor mij en als jullie het anders willen zoeken jullie het maar uit". Om die reden zul je mij niet snel aan open source-software zien werken in mijn vrije tijd.

Mag ik dat met je oneens zijn (is een retorische vraag, antwoord is irrelevant;))? Dat kan prima goed gaan. Wat er alleen vaak fout gaat is dat 1 iemand iets onder een FOSS licentie online zet, en er vervolgens geen tijd in stopt (ook niet als er patches aangedragen worden etc), en dat als het aantal developers/contributors groeit, er een zekere structuur ontbreekt, waardoor iedereen van alles en nog wat door elkaar doet, zonder een wezenlijk resultaat. Echter, is er wel een duidelijke structuur aanwezig dan kan het prima gaan. Bijvoorbeeld, ik contribute geregeld aan het alom geliefde Zend Framework. Als je een patch hebt ga je naar een component maintainer, die gaat naar het Community Review Team, en die gaan naar iemand van Zend. Iedereen weet precies waar 'ie naartoe moet Zeker als er een aantal mensen fulltime mee bezig is heb ik de indruk dat het over het algemeen wel goed gaat.

NMe schreef op donderdag 16 december 2010 @ 15:29:Om die reden zul je mij niet snel aan open source-software zien werken in mijn vrije tijd.

Ik weet niet of je in je vrije tijd wel (gratis) opensource software gebruikt, maar als je dat doet is 't natuurlijk wel aardig (lees: morele verplichting) wat terug te doen. Dat hoeft dan niet per se door code/patches te contributen, dat kan ook door unittests te schrijven, documentatie te schrijven, andere gebruikers in de community helpen, er over bloggen, of wat geld doneren.

[cariolive23]

NMe schreef op donderdag 16 december 2010 @ 15:29:
Ik heb daarna wel geleerd dat open source een leuk idee is op papier, maar dat het in de praktijk gewoon niet goed genoeg werkt. Je kan niet goed even samen brainstormen. Veel projecten hebben niet echt een structuur of een fatsoenlijke chain of command, en maar al te vaak zie je bij de maker een mentaliteit van "het werkt voor mij en als jullie het anders willen zoeken jullie het maar uit".

De betere projecten hebben hier echter geen last van, die hebben een uitstekende structuur en chain of command en er zijn tientallen tot honderden anderen waar je mee kunt brainstormen.

Slecht geleide projecten zullen óf verbeteren óf tot stilstand komen omdat er op een gegeven moment te weinig mensen die het willen gebruiken of er aan bij willen dragen. Niks bijzonders en heeft ook niks met de licentievorm te maken. Met open source en community software ontwikkeling is het project management alleen veel zichtbaarder voor de buitenwereld, ook dat is open. En slecht project management, daar hebben we in deze wereld geen gebrek aan, zie de vele mislukte IT-projecten.

[chris]

Ik heb veel open source code in Haskell geschreven, zie github voor een lijst van m'n projecten. In principe probeer ik zo veel mogelijk code te open sourcen, met uitzondering van zaken voor een klant. Github (en vergelijkbare sites) helpt heel erg met het makkelijk forken en patchen van projecten, heeft voor mij altijd erg goed gewerkt.

[EfBe]

[b][message=35215931,noline]Ik heb daarna wel geleerd dat open source een leuk idee is op papier, maar dat het in de praktijk gewoon niet goed genoeg werkt. Je kan niet goed even samen brainstormen. Veel projecten hebben niet echt een structuur of een fatsoenlijke chain of command, en maar al te vaak zie je bij de maker een mentaliteit van "het werkt voor mij en als jullie het anders willen zoeken jullie het maar uit". Om die reden zul je mij niet snel aan open source-software zien werken in mijn vrije tijd.

Het werkt inderdaad veelal met 1 persoon bouwt 1 feature en submit een patch. Het is niet dat een 'grand design' of 'visie' voorwaards gebracht wordt in een team. Dat is niet altijd nadelig, maar op den duur laat het veelal wel zn sporen na. Daarom is de meeste succesvolle open source software veelal door bedrijven gemaakt die open source developers in dienst hebben die full time aan de open source werken: Linux, Firefox, OpenOffice, Hibernate, JBoss, Eclipse...

[Creepy]

Voor archlinux in het verleden het 1 en ander gedaan (opzetten van 1 van de eerst versies van arch64, bugreportss (voornamelijk in het buildsysteem). Wat bugreports met mogelijke fixes voor FCK 2.x. En wat bugreports + fixes voor PSPMSX.

Echt bewust iets aan een opensource project bijdragen doe ik niet, maar als ik bugs e.d. tegenkom en ik kan relatief eenvoudig dat dan zelf fixen dan is dat terugsturen aan de daadwerkelijke devvers natuurlijk het minste wat je kan doen.

[NMe]

Ik zal op beide reacties die mij citeren alleen even opmerken dat er in mijn ervaring meer slecht geleide opensourceprojecten zijn dan goed geleide projecten. Daar komt helaas nog bij dat voor mij persoonlijk juist die kleinere projecten veel interessanter zijn omdat dat meer een niche-product is. Voor de grotere projecten zijn vaak mainstream-producten die toch echt beter werken in mijn ogen. Ik vind Windows nog steeds fijner dan Linux, Photoshop fijner dan de Gimp en Visio beter dan Dia. Let op: mening. Daar mag je het mee oneens zijn maar dat zal geen effect hebben op mijn mening.

Freeaqingme schreef op vrijdag 17 december 2010 @ 04:19:
[...]

Ik weet niet of je in je vrije tijd wel (gratis) opensource software gebruikt, maar als je dat doet is 't natuurlijk wel aardig (lees: morele verplichting) wat terug te doen. Dat hoeft dan niet per se door code/patches te contributen, dat kan ook door unittests te schrijven, documentatie te schrijven, andere gebruikers in de community helpen, er over bloggen, of wat geld doneren.

Morele verplichting uit het gebruik van opensourcesoftware? Het is spul dat iemand vrijwillig in zijn eigen tijd heeft gemaakt en beschikbaar heeft gesteld, de enige "verplichting" die ik voel is misschien wat geld doneren als ik het uiteindelijk vaak gebruik. Wat al die andere dingen betreft voel ik geen enkele verplichting. Het is software, geen sekte.

[FragFrog]

NMe schreef op zaterdag 18 december 2010 @ 13:52:
Morele verplichting uit het gebruik van opensourcesoftware?

Ergens kan ik me daar wel in vinden. Je gebruikt het werk wat anderen gratis voor jou beschikbaar maken, daar mag best wat tegenover staan. Het hoeft niet, maar het mag wel. Als iedereen die gebruik maakt van een OS project een handje meehelpt zouden veel van die projecten een stuk sneller gaan vermoed ik (mits uiteraard die bijdrages in goede banen geleid worden en van voldoende niveau zijn). Ik zou het nog geen morele verplichting willen noemen maar toch zeker wel 'the right thing to do'

Zelf heb ik een aantal projecten van mij OS gemaakt, niets echt noemenswaardigs (vooral websites: een blog en een MMO server homepage voor MuOnline). Daarnaast nog aardig wat gesubmit naar MaNGOS (Massive Network Game Object Server, maar in de praktijk een WoW server emulator), een MaNGOS GUI app gemaakt voor gamemasters & server admins, en een verdwaalde patch ingediend bij XBMC.

[NMe]

FragFrog schreef op zaterdag 18 december 2010 @ 15:17:
[...]

Ergens kan ik me daar wel in vinden. Je gebruikt het werk wat anderen gratis voor jou beschikbaar maken, daar mag best wat tegenover staan. Het hoeft niet, maar het mag wel. Als iedereen die gebruik maakt van een OS project een handje meehelpt zouden veel van die projecten een stuk sneller gaan vermoed ik (mits uiteraard die bijdrages in goede banen geleid worden en van voldoende niveau zijn). Ik zou het nog geen morele verplichting willen noemen maar toch zeker wel 'the right thing to do'

Dat is hetzelfde als je het mij vraagt.

Ik ben niet te beroerd om geld te doneren aan een project waar ik veel gebruik van maak, zeker als het goed onderhouden wordt. Maar ik ben natuurlijk zélf degene die bepaalt wanneer ik die grens bereik en hoeveel ik dan doneer.

[djc]

NMe schreef op zaterdag 18 december 2010 @ 13:52:
Ik zal op beide reacties die mij citeren alleen even opmerken dat er in mijn ervaring meer slecht geleide opensourceprojecten zijn dan goed geleide projecten. Daar komt helaas nog bij dat voor mij persoonlijk juist die kleinere projecten veel interessanter zijn omdat dat meer een niche-product is. Voor de grotere projecten zijn vaak mainstream-producten die toch echt beter werken in mijn ogen. Ik vind Windows nog steeds fijner dan Linux, Photoshop fijner dan de Gimp en Visio beter dan Dia. Let op: mening. Daar mag je het mee oneens zijn maar dat zal geen effect hebben op mijn mening.

Is IIS beter dan Apache of nginx, IE beter dan Firefox en Chrome? Ik begrijp goed dat je een paar slechte ervaringen hebt met matige leiders, maar dat je naar aanleiding daarvan meteen zegt dat open source in het algemeen "in de praktijk niet goed genoeg werkt" vind ik nogal een overdreven conclusie.

[NMe]

Zie je het woord "vaak" in mijn reactie?

[_JGC_]

Ik beheer zelf pakketjes voor Archlinux, en als ik daarbij dingen tegenkom die ik zelf kan fixen, rapporteer ik gewoon bugs en maak ik de patches daarvoor. Soms worden die patches meegenomen door upstream, soms blijven die patches gewoon 2 jaar in bugzilla hangen en wordt het vervolgens afgeschoten omdat de library inmiddels "obsolete" of "deprecated" is.

Laatst toen ik me verveelde Genius nog geport van gnome-vfs naar GIO/Gvfs, scheelde een hele hoop dependencies, en de ontwikkelaar heeft het gewoon meegenomen in de eerstvolgende release. Op zich is een beetje C pennen niet moeilijk, en vooral portwerk is vrij makkelijk: iemand anders heeft het denkwerk al voor je gedaan en je hoeft alleen maar functies te vervangen door functies in de nieuwe API die hetzelfde doen.

[FragFrog]

djc schreef op maandag 20 december 2010 @ 12:42:
[...]
Is IIS beter dan Apache of nginx, IE beter dan Firefox en Chrome?

Apache wordt beheerd door de Apache Foundation, Chrome wordt grotendeels beheerd door Google (en die hebben ook een aardig handje in de webkit development, samen met Apple - bekijk de lijst met reviewers / contributers maar) en voor Firefox is de Mozilla Foundation actief bezig wat ook niet bepaald een klein clubje is met een omzet van 90 miljoen per jaar.

Noem nu eens een succesvol OS project waar een of twee man zelf mee aan lopen te klieren zonder dat er een of andere instelling is die het project beheert en in goede banen leidt, zonder dat er een of andere foundation is die actief ontwikkelaars inhuurt en betaalde professionals gebruikt om het project te leiden. Ze zijn er wel, maar het merendeel sterft een vroege dood na een jaar of twee als de hoofdontwikkelaar(s) bezig gaat / gaan met andere dingen en niemand het stokje overneemt.

Software development moet van twee kanten komen: van de ene kant moet er code geleverd worden en van de andere komt er aansturing (in de vorm van project management, requirements, bugtracking, etc). De code is er altijd wel in OS projecten, de aansturing daarentegen wil nog wel eens mank lopen. In de praktijk heb je dan toch meer nodig dan alleen een stel programmeurs als je succesvol wilt zijn

[ Voor 3% gewijzigd door FragFrog op 20-12-2010 14:21 ]

[Janoz]

NMe schreef op zaterdag 18 december 2010 @ 13:52:
Ik zal op beide reacties die mij citeren alleen even opmerken dat er in mijn ervaring meer slecht geleide opensourceprojecten zijn dan goed geleide projecten.

There, fixed it for ya.

[Soultaker]

FragFrog schreef op maandag 20 december 2010 @ 14:19:
Noem nu eens een succesvol OS project waar een of twee man zelf mee aan lopen te klieren zonder dat er een of andere instelling is die het project beheert en in goede banen leidt

Voorbeelden te over; BusyBox en SQLite schieten me zo te binnen. Maar wat is je punt? Dat allerlei bedrijven en individuën zich bemoeien met succesvolle open-source projecten? Dat is niet zo gek natuurlijk; open-source software leent zich daar bij uitstek voor, en als er veel verschillende gebruikers zijn, zijn er ook veel verschillende wensen voor verbeteringen.

Ze zijn er wel, maar het merendeel sterft een vroege dood na een jaar of twee als de hoofdontwikkelaar(s) bezig gaat / gaan met andere dingen en niemand het stokje overneemt.

Dat geldt voor álle projecten. Die worden ook vaak met een klein team gestart, slaan dan meestal niet aan, en verdwijnen dan met stille trom van het toneel. Open-source projecten zijn daarmee niet anders.

[Casmo]

Ik werk zelf al een aantal jaar met CakePHP. Heb zelf nooit aanpassingen gecommit maar wel documentatie toegevoegd of uitleg gegeven in hun help (d.m.v. comments).

Zelf ben ik lange tijd bezig met een browser game (zie signature). Deze heb ik sinds December 2010 Open Source gemaakt. https://github.com/Casmo/Naxasius-Game-Engine. Ook gebaseerd op CakePHP Framework.

Ik moet zeggen dat ik er enthousiast was toen ik mijn code openbaar maakte. Ik voel nu ook wel de drift om dit vaker te doen. :-)

[FragFrog]

Soultaker schreef op maandag 20 december 2010 @ 17:56:
Maar wat is je punt? Dat allerlei bedrijven en individuën zich bemoeien met succesvolle open-source projecten?

Dat zonder ingehuurde projectleiding nagenoeg alle OS projecten falen en dus wederom opgaat dat je weinig succesvolle OS projecten ziet als niet in elk geval de projectleiding gewoon door een professioneel bedrijf of stichting wordt gedaan.

De projectleiding van SQLite wordt trouwens gedaan door SQLite consortium waarvan Hipp, Wyrick & Company, Inc de administratie regelt zo te zien. Wederom een voorbeeld hoe nagenoeg elk succesvol OS project niet kan bestaan zonder backing van een bedrijf / organisatie. De enige uitzondering hierop die ik ken is Calibre, maar dat wordt ook bijna volledig door een student in z'n uppie geschreven en zodra die ermee stopt verwacht ik ook niet dat het project nog lang zal blijven bestaan.

Soultaker schreef op maandag 20 december 2010 @ 17:56:
Dat geldt voor álle projecten. Die worden ook vaak met een klein team gestart, slaan dan meestal niet aan, en verdwijnen dan met stille trom van het toneel.

Er is een verschil tussen een ontwikkelaar die opstapt omdat hij wat anders wil doen en een project wat niet aanslaat en daarom maar afgestoten wordt. Ik kom genoeg OS projecten tegen waaraan al lang niet meer wordt ontwikkeld ondanks dat het een goed en nuttig project is. Als een bedrijf een product maakt en een ontwikkelaar stapt op huren ze iemand anders in om het werk voor te zetten. Als een OS project ontwikkelaar opstapt is er niemand die een ander inhuurt om door te gaan

[ Voor 26% gewijzigd door FragFrog op 20-12-2010 18:13 ]

[Freeaqingme]

Het kan natuurlijk ook precies andersom zijn. Iedereen die een succesvol FOSS project beheerst, richt er op een gegeven moment een foundation/whatever voor op om alles netjes te regelen. Uiteindelijk was Linus in eerste instantie ook gewoon een studentje... (hoewel je je kan afvragen of Linux het ultieme voorbeeld van een goed geleid project is).

[Soultaker]

FragFrog schreef op maandag 20 december 2010 @ 18:10:
De projectleiding van SQLite wordt trouwens gedaan door SQLite consortium waarvan Hipp, Wyrick & Company, Inc

Ik was al bang dat je daar mee zou komen omdat je de geschiedenis achter SQLite blijkbaar niet kent. (Ik hoopte eigenlijk dat je dat ik je niet de les zou hoeven lezen, maar daar gaan we.) SQLite is door één developer in z'n vrije tijd ontwikkeld. Hij had géén backing van commerciële bedrijven. Pas met versie 2 werd SQLite echt populair, en toen is ook commerciële interesse ontstaan, omdat SQLite zó goed was dat bedrijven het commercieel wilden gebruiken en zelfs bereid bleken te zijn om te betalen om bepaalde features en bugfixes snel doorgevoerd te krijgen.

De "SQLite Consortium" is dus gewoon een stichting die Richard Hipp opgericht heeft om wat geld te vangen van commerciële partijen (waar dan weer aandacht van developers tegenover staat) maar SQLite was een goed uitgewerkt en succesvol project vóór er commerciële interesse was. Er is dus geen sprake van dat externe projectleiding nodig was, of commerciële backing, om het project van de grond te krijgen en het succesvol te maken.

Natuurlijk kan niemand onbeperkt tijd besteden aan een open-source project zonder op de een of andere manier centen binnen te krijgen om de huur en de boterhammen mee te betalen. Vandaar dat het logisch is dat veel succesvolle projecten uiteindelijk ondersteuning vanuit het bedrijfsleven krijgen, of zelf een commerciële tak opzetten (denk aan RedHat bijvoorbeeld) want met vrije code publiceren alleen verdien je geen geld.

Er is een verschil tussen een ontwikkelaar die opstapt omdat hij wat anders wil doen en een project wat niet aanslaat en daarom maar afgestoten wordt.

In welke zin? Closed-source software wordt echt niet ad infinitum onderhouden hoor (was het maar zo!) In beide gevallen geldt dat als de ontwikkelaar er z'n brood niet mee kan verdienen, hij er mee ophoudt. Het enige verschil is dat gediscontinueerde open-source projecten zichtbaarder zijn omdat de broncode beschikbaar blijft voor eenieder die er wat mee wil doen.

Als een bedrijf een product maakt en een ontwikkelaar stapt op huren ze iemand anders in om het werk voor te zetten. Als een OS project ontwikkelaar opstapt is er niemand die een ander inhuurt om door te gaan

Dat werkt juist precies op dezelfde manier: in beide gevallen is er ofwel een geïnteresseerde partij die de ontwikkeling overneemt, óf niemand heeft er interesse meer in en dan sterft het project een zachte dood. Je doet nu net alsof commerciële projecten nooit gediscontinueerd worden... het moet niet gekker worden.

Het verschil met open-source software is dat je als gebruiker niet afhankelijk bent van de oorspronkelijke ontwikkelaar om een project voort te zetten.

[FragFrog]

Soultaker schreef op maandag 20 december 2010 @ 18:47:
Dat werkt juist precies op dezelfde manier: in beide gevallen is er ofwel een geïnteresseerde partij die de ontwikkeling overneemt, óf niemand heeft er interesse meer in en dan sterft het project een zachte dood. Je doet nu net alsof commerciële projecten nooit gediscontinueerd worden... het moet niet gekker worden.

Dus jij wilt serieus beweren dat commerciele projecten net zo vaak gediscontinueerd worden als OS projecten? Jij denkt serieus dat een OS project evenveel kans van slagen heeft als een commercieel project?

Nee, dan heeft het weinig nut er verder over te praten.

Overigens is volgorde volslagen irrelevant: of het project er nu eerst was of de stichting, feit is dat bij een langlopend project zo'n stichting or organisatie moet bestaan om het project te leiden als de originele developers ermee stoppen. Dat al die developers die denken dat ze het ook wel zonder kunnen debet zijn aan de tienduizenden projecten op SourceForge waaraan al jaren niemand meer gewerkt heeft, ondanks in veel gevallen een goed idee en veel potentie. Nee, je hoeft me niet de les te lezen, maar ik zou het waarderen als je niet op mijn posts reageert zonder ze ook te begrijpen

[ Voor 9% gewijzigd door FragFrog op 20-12-2010 19:00 ]

[Sardaukar]

FragFrog schreef op maandag 20 december 2010 @ 18:59:
[...]

Dus jij wilt serieus beweren dat commerciele projecten net zo vaak gediscontinueerd worden als OS projecten? Jij denkt serieus dat een OS project evenveel kans van slagen heeft als een commercieel project?

Er is natuurlijk wel een groot verschil tussen wanneer een commercieel project geslaagd is en wanneer een open source project geslaagd is. Dat is niet objectief met elkaar te vergelijken.

Ik heb een klein Powershell scriptje geschreven om Team Foundation Server repositories te kunnen importeren in Git. Te vinden op GitHub.

Dit heb ik geschreven omdat ik dit zelf nodig heb. Voor mij is het project geslaagd omdat mijn probleem is opgelost. Ik heb het ergens neergezet waar iedereen erbij kan. Patches die binnenkomen verwerk ik.

Is mijn projectje geslaagd? Voor mij wel.

[Soultaker]

FragFrog schreef op maandag 20 december 2010 @ 18:59:
Dus jij wilt serieus beweren dat commerciele projecten net zo vaak gediscontinueerd worden als OS projecten? Jij denkt serieus dat een OS project evenveel kans van slagen heeft als een commercieel project?

Dat lijkt me lastig te kwantificeren, want op de lange termijn zijn vrijwel alle softwareprojecten defunct.

Ik denk dat het vrij vaak voorkomt dat ontwikkelaars bij commerciële bedrijven tooltjes schrijven voor intern gebruik, die na een tijdje niet meer onderhouden, en die dan niet meer gebruikt worden. Zijn die geslaagd of gefaald? En maakt het dan nog uit of de broncode tussendoor op SourceForge of GitHub gezet is? Want dat is feitelijk natuurlijk het enige verschil tussen open of closed source voor dat soort tools.

(Zie ook Sardaukar's voorbeeld.)

Overigens is volgorde volslagen irrelevant: of het project er nu eerst was of de stichting, feit is dat bij een langlopend project zo'n stichting or organisatie moet bestaan om het project te leiden als de originele developers ermee stoppen.

Helemaal niet, want SQLite is en was prima bruikbaar zoals hij gereleaset was. Natuurlijk zorgt externe financiëring voor langetermijnsupport; dat is één van de redenen dat commerciële bedrijven er überhaupt geld in stoppen, maar dat zegt niet dat het project anderzins niet bruikbaar was geweest.

Vind je dan ook dat bijvoorbeeld de hele Windows 95 serie is gefaald omdat Microsoft het niet meer support (en niemand anders kan/mag dat doen)? Naar mijn mening was dat een vrij succesvol project, maar als het enige criterium is of het project nú nog supported is, dan moet ik blijkbaar constateren dat het een flop was.

[djc]

FragFrog schreef op maandag 20 december 2010 @ 14:19:Apache wordt beheerd door de Apache Foundation, Chrome wordt grotendeels beheerd door Google (en die hebben ook een aardig handje in de webkit development, samen met Apple - bekijk de lijst met reviewers / contributers maar) en voor Firefox is de Mozilla Foundation actief bezig wat ook niet bepaald een klein clubje is met een omzet van 90 miljoen per jaar.

Noem nu eens een succesvol OS project waar een of twee man zelf mee aan lopen te klieren zonder dat er een of andere instelling is die het project beheert en in goede banen leidt, zonder dat er een of andere foundation is die actief ontwikkelaars inhuurt en betaalde professionals gebruikt om het project te leiden. Ze zijn er wel, maar het merendeel sterft een vroege dood na een jaar of twee als de hoofdontwikkelaar(s) bezig gaat / gaan met andere dingen en niemand het stokje overneemt.

Je draait oorzaak en gevolg om.

Als een open source-project groter wordt is het vaak handig om het onder te brengen in een stichting zodat het makkelijker wordt voor geinteresseerde partijen om geld te doneren. Mercurial (waar ik zelf aan meewerk) is een VCS dat met een groepje van een stuk of 7 actieve developers een product ontwikkelt dat gebruikt wordt door Sun/Oracle en Mozilla. Na enige tijd hebben we Mercurial ondergebracht bij de Software Freedom Conservancy, die beheren onze fondsen (maar doen niets aan development).

Mozilla is wel begonnen bij Netscape, maar er is inderdaad een stichting (en later ook een bedrijf, respectievelijk de Mozilla Foundation en de Mozilla Corporation) omheen opgezet om de fondsen die binnengehaald werden effectief om te zetten om de producten te verbeteren (zowel ingehuurde developers -- die overigens meestal al actief waren voordat ze werden ingehuurd -- als infrastructuur). De Linux-kernel is een ander voorbeeld van een nogal succesvol product. Je kan wel zeggen dat ontwikkeling nu grotendeels betaald wordt door Red Hat, IBM en Google, maar dat is pas gekomen nadat het een succes werd. De Apache HTTP server was er al voor de Apache Foundation, enzovoorts.

Dat je weinig kleine succesvolle projecten kunt vinden betekent wellicht dat kleine succesvolle projecten snel groter worden! Bijvoorbeeld Redis, Ruby on Rails, Django, Ruby en Python zelf, etc.

[Bryan Tong Minh]

Ik werk mee aan MediaWiki. Voor mij mijn eerste grote open source project. Ik moet zeggen dat het best wel gaaf is om jouw code op een top 5 website te zien draaien (helaas met deployment slechts enkele malen per jaar). Verder probeer ik meestal kleine scripts die ik schrijf open source te maken onder het mom van "daar hebben anderen nog wat aan".

[Hillie]

Ik ben het eens met de mensen die stellen dat er geen enkele morele verplichting aan het gebruik van open source hangt. Eergisteren nog wel $5 naar de maker van Exact Audio Copy gepaypald, maar dat gebruik ik al zo lang. Misschien had ik al eens gedoneerd een paar jaar terug, staat me niet meer bij, maar ik vind het het waard.

Kwam er daarna wel achter dat het supportforum lijkt te bestaan uit arrogante Duitsers. Och ja.


Even wat anders: Er zijn nogal wat profi codeklopperts hier (yours truly hoort er ook bij), kopen jullie je software legaal? M'n oude PCtje had het begeven, toen ik de nieuwe samen ging stellen heb ik er meteen een Win7 DVDtje bijbesteld, en twee weken terug is m'n Photoshop ook binnengekomen. Kost wat, maar ik verdien goed bij een softwarebedrijf, dus dan vind ik het krom om een...uhmm... "evaluatiekey" te regelen.

[H!GHGuY]

Hillie schreef op woensdag 22 december 2010 @ 06:23:
Ik ben het eens met de mensen die stellen dat er geen enkele morele verplichting aan het gebruik van open source hangt. Eergisteren nog wel $5 naar de maker van Exact Audio Copy gepaypald, maar dat gebruik ik al zo lang. Misschien had ik al eens gedoneerd een paar jaar terug, staat me niet meer bij, maar ik vind het het waard.

Kwam er daarna wel achter dat het supportforum lijkt te bestaan uit arrogante Duitsers. Och ja.


Even wat anders: Er zijn nogal wat profi codeklopperts hier (yours truly hoort er ook bij), kopen jullie je software legaal? M'n oude PCtje had het begeven, toen ik de nieuwe samen ging stellen heb ik er meteen een Win7 DVDtje bijbesteld, en twee weken terug is m'n Photoshop ook binnengekomen. Kost wat, maar ik verdien goed bij een softwarebedrijf, dus dan vind ik het krom om een...uhmm... "evaluatiekey" te regelen.

Sinds ik werk koop ik wel de meeste software. Dat heeft overigens het negatieve effect dat ik gewoon minder software koop/gebruik of gratis varianten zoek. Netto levert het de bedrijven dus weinig op.

[AtleX]

Ik heb een hoop software (Windows 7, Visual Studio 2008 Professional en natuurlijk een miljoen tooltjes) legaal. Veel andere programma's heb ik vervangen door gratis alternatieven. Voor Nero gebruik ik inmiddels CDburnerXP, Photoshop heb ik nooit gebruikt maar Paint.net voldoet tot nu toe prima, mijn betaalde VisualSVN licentie heb ik de deur uit geknikkerd en vervangen door AnkhSVN, etc. Ik doneer regelmatig aan de gratis tools die ik gebruik. Per jaar heb ik daar een 'budget' van 100 dollar voor wat ik aan het einde van het jaar doneer aan de tools die ik dat jaar het meest heb gebruikt.

[Remus]

offtopic:
Ik zie niet helemaal in wat deze discussie over opgeleide <> self-taught programmeurs toevoegt aan een discussie over opensource.

Ik zelf doe nog bar weinig aan opensource. Naast voltijds baan + reistijd en een deeltijd studie besteed ik mijn tijd liever aan een sociaal leven. Ik heb wel eens (kleine) patches geschreven voor Jaybird (Firebird SQL JDBC driver). Daarnaast ben ik momenteel bezig met het afronden van een bachelor, het eindresultaat van mijn project zal als opensource beschikbaar gesteld worden.

Ik wil in de toekomst meer tijd aan opensource te doen, gewoon omdat het me wel leuk lijkt. Grote vraag is alleen wanneer ik de mogelijkheid+zin heb om tijd vrij te maken.

[HawVer]

Ik heb een guicontrol voor .net windows forms geschreven:

http://guifreaks.net/index.php?action=feat2



Op het moment staat dit op een erg laag pitje en wel omdat

1. Arrogantie van bepaalde gebruikers. Fix dat, doe zus, doe zo, waarom heb je die bug nog niet gefixt, help mij eens even snel.

Can you please quick reply/upload new version please.

2. Gaat veel tijd inzitten en de returns uit commerciele applicaties zijn blijven steken bij 50,- in totaal. Te weinig ROI als je ziet hoeveel tijd er in zit. Ik weet hoeveel commerciële gebruikers ik heb omdat je per commerciële licentie een aanvraag moet indienen. De control wordt best actief gebruikt. Misschien denk ik wel te goed over 'een community'. De kwaliteit van mijn control is beter dan menig commercieel variant.

Als het gaat om tijd vs. geld dan werkt open source gewoon niet. Ik heb ook nog een tijdje een principe geprobeerd met doneer een feature, maar dat loopt ook niet. Als iemand een idee heeft hoe je open source kan vermarkten dan hou ik mij aanbevolen. Want voor niets doe ik het niet. Ik ben geen communistische arbeider.

3. Vermoedelijk plagiaat van mijn sourcecode: http://www.olassistant.com/

Ik ben nu bezig met een commerciële variant

[ Voor 13% gewijzigd door HawVer op 29-12-2010 08:47 ]

[EfBe]

djc schreef op dinsdag 21 december 2010 @ 10:41:
[...]
Je draait oorzaak en gevolg om.

Als een open source-project groter wordt is het vaak handig om het onder te brengen in een stichting zodat het makkelijker wordt voor geinteresseerde partijen om geld te doneren. Mercurial (waar ik zelf aan meewerk) is een VCS dat met een groepje van een stuk of 7 actieve developers een product ontwikkelt dat gebruikt wordt door Sun/Oracle en Mozilla. Na enige tijd hebben we Mercurial ondergebracht bij de Software Freedom Conservancy, die beheren onze fondsen (maar doen niets aan development).

Mozilla is wel begonnen bij Netscape, maar er is inderdaad een stichting (en later ook een bedrijf, respectievelijk de Mozilla Foundation en de Mozilla Corporation) omheen opgezet om de fondsen die binnengehaald werden effectief om te zetten om de producten te verbeteren (zowel ingehuurde developers -- die overigens meestal al actief waren voordat ze werden ingehuurd -- als infrastructuur). De Linux-kernel is een ander voorbeeld van een nogal succesvol product. Je kan wel zeggen dat ontwikkeling nu grotendeels betaald wordt door Red Hat, IBM en Google, maar dat is pas gekomen nadat het een succes werd. De Apache HTTP server was er al voor de Apache Foundation, enzovoorts.

Dat je weinig kleine succesvolle projecten kunt vinden betekent wellicht dat kleine succesvolle projecten snel groter worden! Bijvoorbeeld Redis, Ruby on Rails, Django, Ruby en Python zelf, etc.

Jij gaat net als sommige anderen in deze thread voorbij aan wat FragFrog wil zeggen (denk ik), namelijk dat om een groter project succesvol voort te zetten moet je het team ook als team laten werken, je moet een richting hebben waarin het project zich beweegt, features die op die richting liggen moeten worden ontworpen, veelal met meerdere mensen binnen het team, er moet dus veel coordinatie plaatsvinden. Verder moet er veelal veel tijd gestoken worden in allerlei aspecten van het bouwen en beheren van de software.

Bijna alle non-corporated funded OSS wordt gebouwd volgens het principe van "wil je iets, stuur me dan maar een patch', of door 1 persoon die in zn vrije tijd wat code klopt. Het patch-driven development principe werkt totaal niet voor grote projecten: je komt nauwelijks vooruit, het is afhankelijk van wat men aandraagt, belangrijke wijzigingen zijn afhankelijk van de inzet van vrijwilligers en er is geen deadline/planning wanneer die dit opleveren, immers ze zijn niet je werknemers.

Om een groter project in goede banen te leiden kun je niet afhankelijk zijn van derden die 'wellicht' een bug patchen of een nieuwe feature aandragen: uberhaupt is het twijfelachtig of iemand een feature bouwt die precies in de richting van waarheen het project moet gaan. Wat er gebeurt is dat men de projectwerkzaamheden consolideert in een groep en zorgt dat de voortgang gewaarborgd is: bv door full time developers, een hechte kern van developers die bv dicht bijelkaar wonen of anderzinds dagelijks contact hebben, zodat richting, feature planning, wie doet wat, welke feature beinvloedt welke andere features etc. etc. allemaal makkelijker verloopt.

Wanneer een projectje klein is, en door 1 persoon behapt kan worden, dan zie je geen problemen. Maar zodra een projectje groter wordt, er een serie bugs staan te wachten alvorens nieuwe dingen in de code kan worden gebouwd, men moet besluiten wat te doen na de initiele release... dan wordt het kritiek en gaat bijna alle OSS software naar de slachtbank. De reden is simpel: niemand heeft zin om ellenlange lijsten bugs te fixen, men wil nieuwe dingen bouwen, immers, dat is niet saai. Ook wanneer de code niet optimaal geschreven is (bv zonder enige comments WAAROM de code zo is zoals ze is, design docs of anderzinds enige documentatie), is bugfixing nog naarder werk dan het al was. Na verloop van tijd is inbouwen van nieuwe dingen overigens ook geen fun meer, tenzij je dingen wilt breken en backwards compatibility je een worst zal zijn. Dan begint het spenderen van je vrije tijd aan dit soort projecten op 'werk' te lijken en haakt menigeen (ik durf wel te zeggen: bijna iedereen) af.

Een groep full-time developers, die betaald wordt om bugs te fixen, nieuwe dingen te bouwen binnen een vastgesteld kader, die kan dit wel, botweg omdat het hun werk is. De uitzondering die na zn baan nog tot 11-en OSS zit te schrijven om een idealistische reden daargelaten.

Ik zie je punt dan ook niet mbt 'de stichting of bedrijf is bedoeld om makkelijker geld te doneren', want daar is die constructie helemaal niet voor. Je kunt geen full-time developers betalen vanuit donaties alleen, wat is de motivatie om al dat geld op te branden? Immers je geeft het resultaat van wat je investeert weg.

Je voorbeeld mbt netscape is overigens fout. Andreesen is al vrij snel een bedrijf begonnen om de browser een commercieel succes te maken en dan met name via de webserver die Netscape verkocht (het was ook geen open source). De linux kernel lijkt ontwikkeld door een gezellige groep mensen, maar het is gewoon hardcore commerciele software, met het enige verschil dat de code beschikbaar is. Linux wordt al jaren ontwikkeld door developers die full time bezig zijn met linux kernel development, en daar gewoon voor betaald worden. Immers, het is de enige manier om ervoor te zorgen dat je wijzigingen kunt doorvoeren die als team gedragen worden.

En voordat iemand met zn naieve blik gaat beweren dat patch-driven development best werkt: nee, dat werkt voor geen meter: patches om een klein bugje te fixen: soit. Patches die lappen code refactoren en nieuwe features daardoor mogelijk maken en/of nieuwe features aandragen die bv meerdere subsystemen wijzigen... no way. Je krijgt dus een poliepenstructuur van code en dat valt binnen de korste keren in elkaar. Je krijgt features aangeleverd die nodig zijn voor de submitter, maar wellicht voor 90% van de gebruikers irrelevant, en andersom: naar werk dat wel relevant is voor 90% van de users blijft liggen omdat niemand het wil doen. Mooi voorbeeld is de linq provider van NHibernate. Dat is gewoon erg veel werk (lees: 8-10 maanden minimaal, full time). Nu hebben ze een 'linq provider' in 3.0 die veel dingen niet doet, gewoon omdat de enige persoon die zich daar toch voor heeft ingezet niet zoveel tijd had. Iemand anders had wel veel tijd maar geen zin om een linq provider te maken dus bedacht 'yet another query system', wat 1) ook weer niet 100% dekkend is en 2) niet standaard.

Bij een bedrijf-backed OSS project heb je dit veel minder: het voortbestaan van het project is van belang, niet wat de committers nodig hebben op die dag.

[cariolive23]

EfBe schreef op woensdag 29 december 2010 @ 09:49:
[...]
Bij een bedrijf-backed OSS project heb je dit veel minder: het voortbestaan van het project is van belang, niet wat de committers nodig hebben op die dag.

Je noemt veel goede punten daar waar het aankomt op het projectmanagement, maar hier sla je imho de plank mis: Een bedrijf geeft geen moer om "het project", een bedrijf moet inkomsten genereren. Daar kan "het project" een middel bij zijn, het zal zeker geen onbetwist doel zijn. Een bedrijf heeft ook altijd de keuze om de licentie aan te passen en dan is het zomaar over en uit met "het project" zoals je dat kende.

PostgreSQL is een voorbeeld van een project dat door een kleine groep mensen wordt geleid en waar een grotere groep mensen en bedrijven nog weer omheen zit. Hier komen zowel tijd als geld van beschikbaar, wat weer wordt ingezet voor specifieke doelen. PostgreSQL heeft zelfs als beleid dat geen enkel bedrijf een te grote invloed mag krijgen, dat is een te groot risico voor de continuïteit van het project: Bedrijf stopt de bijdrages en het project blijft geamputeerd achter. PostgreSQL heeft dit al eens meegemaakt met Great Bridge LLC in 2001 en dit willen ze niet nogmaals meemaken.

Goed projectmanagement is uiteraard van het allergrootste belang, het maakt daarbij echter niet uit of het nu om open source of closed source software gaat.

[YopY]

quote: EfBe

En voordat iemand met zn naieve blik gaat beweren dat patch-driven development best werkt: nee, dat werkt voor geen meter: patches om een klein bugje te fixen: soit. Patches die lappen code refactoren en nieuwe features daardoor mogelijk maken en/of nieuwe features aandragen die bv meerdere subsystemen wijzigen... no way.

Nee, geloof ik ook niet; dat soort dingen moet gedaan kunnen worden door mensen met commitrechten, dat werkt veel vlotter dan met losse patches. Immers, als ik 'patch-driven development' juist begrijp (uit de naam alleen) dan gaat dat als:

* Iemand dient een bugreport / ticket in met de opmerking 'dat en dat werkt suboptimaal'
* Iemand dient daarvoor een patch in
* Iemand met commitrechten neemt de patch en bekijkt / test deze lokaal
* Indien goed: comitten / verwerken / ticket sluiten. Indien fout: opmerking, terug naar stap 2.

Terwijl het bij iemand met commitrechten veel directer is, ticket, aantal commits, klaar.

* YopY maakt ook een losse opmerking om te doen alsof hij erbij hoort.

[Sardaukar]

EfBe schreef op woensdag 29 december 2010 @ 09:49:
[...]
En voordat iemand met zn naieve blik gaat beweren dat patch-driven development best werkt: nee, dat werkt voor geen meter: patches om een klein bugje te fixen: soit. Patches die lappen code refactoren en nieuwe features daardoor mogelijk maken en/of nieuwe features aandragen die bv meerdere subsystemen wijzigen... no way. Je krijgt dus een poliepenstructuur van code en dat valt binnen de korste keren in elkaar.

Je boodschap is wel erg zwart-wit gesteld.

Als tegenvoorbeeld: ontwikkeling van Git loopt via de Git mailinglist waarbij patches worden aangedragen maar ook nieuwe features worden besproken en samen uitgewerkt. Hier zie ik dus wel degelijk dat ingrijpende wijzigingen worden doorgevoerd.

En volgens mij kunnen we stellen dat Git een redelijk succesvol project is

Toegegeven: dingen als een roadmap, etc. hoef je niet te verwachten.

[EfBe]

YopY schreef op woensdag 29 december 2010 @ 11:28:
[...]
Nee, geloof ik ook niet; dat soort dingen moet gedaan kunnen worden door mensen met commitrechten, dat werkt veel vlotter dan met losse patches. Immers, als ik 'patch-driven development' juist begrijp (uit de naam alleen) dan gaat dat als:

* Iemand dient een bugreport / ticket in met de opmerking 'dat en dat werkt suboptimaal'
* Iemand dient daarvoor een patch in
* Iemand met commitrechten neemt de patch en bekijkt / test deze lokaal
* Indien goed: comitten / verwerken / ticket sluiten. Indien fout: opmerking, terug naar stap 2.

Terwijl het bij iemand met commitrechten veel directer is, ticket, aantal commits, klaar.

Nee, patch-driven-development komt neer op:
- je kijkt naar de issues die aangedragen zijn
- je wacht op patches voor die issues
- applied die patches.

Je gaat dus niet zelf kijken wat mensen nodig hebben, een grotere visie ontwikkelen en daarop je features baseren. Een stuk software bouwen zonder dat je direct met 'de klant' praat vereist dat je verder kijkt dan wat degenen die de moeite hebben genomen een issue te filen aandragen.

cariolive23 schreef op woensdag 29 december 2010 @ 10:41:
[...]
Je noemt veel goede punten daar waar het aankomt op het projectmanagement, maar hier sla je imho de plank mis: Een bedrijf geeft geen moer om "het project", een bedrijf moet inkomsten genereren. Daar kan "het project" een middel bij zijn, het zal zeker geen onbetwist doel zijn. Een bedrijf heeft ook altijd de keuze om de licentie aan te passen en dan is het zomaar over en uit met "het project" zoals je dat kende.

Het project is de manier waarop het bedrijf geld verdient. Daarom betaalt het bedrijf ook de developers om aan het project te werken. IBM betaalt bv vele linux kernel developers omdat ze een inmense services afdeling hebben die daar vele miljoenen euros mee verdient. IBM is dus gebaat bij het voortbestaan van Linux en wel in de richting waar ze zelf wat mee kunnen.

Zeggen dat 'het bedrijf geen moer geeft om het project' lijkt me dan ook onzin, immers: het bedrijf bestaat omdat het project er is, en het project bestaat omdat het bedrijf er is.

PostgreSQL is een voorbeeld van een project dat door een kleine groep mensen wordt geleid en waar een grotere groep mensen en bedrijven nog weer omheen zit. Hier komen zowel tijd als geld van beschikbaar, wat weer wordt ingezet voor specifieke doelen. PostgreSQL heeft zelfs als beleid dat geen enkel bedrijf een te grote invloed mag krijgen, dat is een te groot risico voor de continuïteit van het project: Bedrijf stopt de bijdrages en het project blijft geamputeerd achter. PostgreSQL heeft dit al eens meegemaakt met Great Bridge LLC in 2001 en dit willen ze niet nogmaals meemaken.

Nobel, maar toch zal postgresql consessies doen aan degene(n) die van vitaal belang zijn voor het betalen van de rekeningen. De database engine wordt maar door een paar mensen geschreven, wat duidt op fulltime development. Die rekening moet ergens van betaald worden en degenen die dat doen willen daar wel wat voor terug (of ze moeten zo vrijgevig zijn dat ze niet meer weten wat ze met het geld moeten). Bij postgresql zijn de bedrijven om de DB heen gebaat bij het voortbestaan van de DB, maar niet in iedere richting. M.a.w.: als een belangrijke speler een pakket features wil hebben zal daar toch hoe dan ook beter naar gekeken worden dan wanneer John Sixpack uit Bubbaneck county, Missouri iets roept.

Is allemaal niet erg overigens, het is gewoon realistisch. De tijd dat mensen nog in Raymond's bazaar model geloofden zonder rekening te houden met wie toch die flatscreen ging betalen ligt gelukkig grotendeels achter ons.

Sardaukar schreef op woensdag 29 december 2010 @ 11:38:
[...]
Je boodschap is wel erg zwart-wit gesteld.
Als tegenvoorbeeld: ontwikkeling van Git loopt via de Git mailinglist waarbij patches worden aangedragen maar ook nieuwe features worden besproken en samen uitgewerkt. Hier zie ik dus wel degelijk dat ingrijpende wijzigingen worden doorgevoerd.
En volgens mij kunnen we stellen dat Git een redelijk succesvol project is
Toegegeven: dingen als een roadmap, etc. hoef je niet te verwachten.

Het werkt omdat er maar 1 ding telt: Linus moet er tevreden mee zijn. Dus feitelijk wat git development inhoudt is een VCS maken voor Linus als enige klant. Let wel: features waar Linus op tegen is of totaal niet in is geinteresseerd krijgen echt geen hoge prioriteit. Dat anderen daar tijd in steken is uiteraard leuk voor de eindgebruikers, maar er is geen globale visie van 'zo gaan we het doen, en zo lossen we de problemen op voor mensen die dingen doen die wij niet zullen doen'. Dom voorbeeld: als Linus vindt dat versioning van binaries totaal irrelevant is, komt het er echt niet in, want waarom daar tijd aan besteden als iets anders ook tijd nodig heeft. (geen idee of dit een real-life voorbeeld is, ik gebruik geen git maar mercurial & svn)

[ Voor 66% gewijzigd door EfBe op 29-12-2010 14:07 ]

[cariolive23]

EfBe schreef op woensdag 29 december 2010 @ 13:54:
Het project is de manier waarop het bedrijf geld verdient.

Dat kan ook wanneer ze het project ineens closed source maken, die vrijheid heb je als eigenaar.

Zeggen dat 'het bedrijf geen moer geeft om het project' lijkt me dan ook onzin, immers: het bedrijf bestaat omdat het project er is, en het project bestaat omdat het bedrijf er is.

Het bedrijf zal ook blijven bestaan wanneer ze het project uitgeven met een closed source licentie.

Nobel, maar toch zal postgresql consessies doen aan degene(n) die van vitaal belang zijn voor het betalen van de rekeningen.

En dat is nu nét datgene wat ze proberen te vermijden: te afhankelijk worden van één bedrijf.

Bij postgresql zijn de bedrijven om de DB heen gebaat bij het voortbestaan van de DB, maar niet in iedere richting.

Precies. Niet ieder bedrijf zal in iedere richting mee willen, maar zij kunnen dan eventueel forken. Wat met PostgreSQL al diverse malen is gedaan. Ook kun je onderdelen die je zelf niet nodig hebt, gewoon links laten liggen en niet gebruiken: het zal maar zelden in de weg zitten. Goed overleg, wat met goed projectmanagement ook gebeurt, is dus ook hier gewenst.

M.a.w.: als een belangrijke speler een pakket features wil hebben zal daar toch hoe dan ook beter naar gekeken worden dan wanneer John Sixpack uit Bubbaneck county, Missouri iets roept.

Lijkt me een kwestie van ervaring en credits, misschien is John Sixpack wel de hedendaagse Ted Codd. Bedrijven kunnen al credits en ervaring hebben verzameld waardoor er beter naar hun voorstellen wordt geluisterd maar dat is dan ook het enige verschil.

[Sardaukar]

EfBe schreef op woensdag 29 december 2010 @ 13:54:
[...]
Het werkt omdat er maar 1 ding telt: Linus moet er tevreden mee zijn. Dus feitelijk wat git development inhoudt is een VCS maken voor Linus als enige klant. Let wel: features waar Linus op tegen is of totaal niet in is geinteresseerd krijgen echt geen hoge prioriteit. Dat anderen daar tijd in steken is uiteraard leuk voor de eindgebruikers, maar er is geen globale visie van 'zo gaan we het doen, en zo lossen we de problemen op voor mensen die dingen doen die wij niet zullen doen'.

Onzin.

Linus is al lange tijd geen maintainer meer van Git. In die tijd ging je verhaal nog wel op in de zin dat hij een behoorlijke stempel drukte op het ontwerp. Niet zo heel vreemd: Git is ontstaan vanwege het wegvallen van Bitkeeper en de wens van Linus om toch op die manier (DVCS) te blijven werken.

Sinds 2005 is Git in het beheer van Junio Hamano en is de werkwijze zoals ik deze eerder heb beschreven. Features worden in de mailinglist besproken en er wordt gezamenlijk actie op ondernomen, of niet als men de feature niet nodig acht. En dat gebeurt vanuit de Git community, niet vanuit één persoon (Linus).

[ Voor 0% gewijzigd door Sardaukar op 29-12-2010 16:45 . Reden: typo ]

[Freeaqingme]

In dat opzicht is Git vergelijkbaar met PHP, en nog een miljoen andere softwareprojecten, en dat is jammer. Ieder (FOSS) project zou mijns inziens moeten beginnen met een roadmap, zodat iedereen weet wat voor kant je met z'n allen op gaat.

[Sardaukar]

Freeaqingme schreef op woensdag 29 december 2010 @ 17:21:
In dat opzicht is Git vergelijkbaar met PHP, en nog een miljoen andere softwareprojecten, en dat is jammer. Ieder (FOSS) project zou mijns inziens moeten beginnen met een roadmap, zodat iedereen weet wat voor kant je met z'n allen op gaat.

"Every good work of software starts by scratching a developer's personal itch" - The Cathedral and the Bazaar. Goed leesvoer met betrekking tot deze discussie, maar dat terzijde.

Ik heb zelf een - heel klein - open source projectje. Ontstaan uit persoonlijke jeuk

Waarom zou ik daar van te voren al een roadmap voor neer moeten leggen? Ik zie daar de noodzaak niet van in.

[Freeaqingme]

Sardaukar schreef op woensdag 29 december 2010 @ 19:46:
[...]
Waarom zou ik daar van te voren al een roadmap voor neer moeten leggen? Ik zie daar de noodzaak niet van in.

Zolang het solo is en jij daar blij mee bent moet je daar zeker geen roadmap voor neerleggen. Echter, wanneer je vraagt aan anderen of ze mee willen helpen aan je project, vind ik het een heel normale zaak dat je weet welke kant het op gaat.

[EfBe]

Sardaukar schreef op woensdag 29 december 2010 @ 16:45:
[...]
Onzin.
Linus is al lange tijd geen maintainer meer van Git. In die tijd ging je verhaal nog wel op in de zin dat hij een behoorlijke stempel drukte op het ontwerp. Niet zo heel vreemd: Git is ontstaan vanwege het wegvallen van Bitkeeper en de wens van Linus om toch op die manier (DVCS) te blijven werken.

En nog steeds, trust me. Linus maintained ook geen grote delen van Linux meer, maar dat betekent niet dat hij achter de schermen een grote vinger in de pap heeft. Het was slechts een voorbeeld trouwens, er wordt al teveel ge-oh-ed over git, en dit topic gaat er niet over.

Sinds 2005 is Git in het beheer van Junio Hamano en is de werkwijze zoals ik deze eerder heb beschreven. Features worden in de mailinglist besproken en er wordt gezamenlijk actie op ondernomen, of niet als men de feature niet nodig acht. En dat gebeurt vanuit de Git community, niet vanuit één persoon (Linus).

Maar hoe bepaalt men of een feature nodig is of niet. Dat is de essentie van het gehele verhaal. Ik doe al vele jaren product development en architectuur en daar heb je hele andere constraints dan wanneer je maatwerk levert voor een klant: de klant is er immers niet, die kun je niet even 'vragen' of hij dit of dat nodig heeft. Bij OSS en bij closed source moet je bij product development verder kijken dan wat de groep/het team vindt wat nodig is: je moet jezelf verplaatsen in degene waarvoor je het feitelijk maakt.

Bij commerciele software zijn dat je betalende klanten, maar bij OSS, wie zijn het? veelal komt het erop neer dat men in de groep zelf kijkt wat men nodig heeft. Maar dat is nu juist _niet_ wat men moet doen en wat ik probeerde duidelijk te maken.

Sardaukar schreef op woensdag 29 december 2010 @ 19:46:
[...]

"Every good work of software starts by scratching a developer's personal itch" - The Cathedral and the Bazaar. Goed leesvoer met betrekking tot deze discussie, maar dat terzijde.

Oh dear... Zoals ik hierboven zei:

De tijd dat mensen nog in Raymond's bazaar model geloofden zonder rekening te houden met wie toch die flatscreen ging betalen ligt gelukkig grotendeels achter ons.

Kennelijk niet. Die out of context quote is an sig wel waar, maar het gehele Bazaar gelul is onzin, immers, wie gaat de rekening betalen? Het idee dat al die duizenden kloppertjes over de gehele wereld savonds en in het weekend hun vrije tijd opofferen om en masse open source software te maken met zn allen is op papier met een naive met bier doordrenkte blik nog wel met enig enthousiasme te begroeten, maar dat neemt niet weg dat datzelfde idee van totaal alle realiteitszin ontbeert.

Ik heb zelf een - heel klein - open source projectje. Ontstaan uit persoonlijke jeuk
Waarom zou ik daar van te voren al een roadmap voor neer moeten leggen? Ik zie daar de noodzaak niet van in.

Jouw kleine projectje is het onderwerp niet. Daarvan staat sourceforge, github, codeplex en bitbucket vol mee. Het zijn de projecten die langer leven dan wanneer de jeuk weg is, wanneer anderen het gaan gebruiken en aanpassing behoeft. Wanneer je features moet gaan inbouwen die jezelf geen ene reet interesseren maar wellicht je gebruikers wel. DAT is de essentie van de discussie.

[ Voor 31% gewijzigd door EfBe op 29-12-2010 21:42 ]

[Gomez12]

EfBe schreef op woensdag 29 december 2010 @ 21:16:
[...]
Wanneer je features moet gaan inbouwen die jezelf geen ene reet interesseren maar wellicht je gebruikers wel. DAT is de essentie van de discussie.

Dat en deels het niet afhankelijk kunnen zijn van anderen omdat er geen verplichtingen zijn.

Ik heb in een ver verleden voor een OS-projectje eens aangeboden om een gedeelte te herschrijven, van te voren duidelijk gecommuniceerd dat dit ongeveer 1 maand zou kosten en dat ze niets in de core moesten aanpassen. Zie ik na 2 weken opeens een nieuwe versie verschijnen met core wijzigingen die niet strookten met mijn aanpassingen, ik hoofd-dev aangesproken en die zei doodleuk dat ze vaker mensen kregen die zeggen 1 maand bezig te zijn en dan nooit meer iets te horen, en dit was een leuke toevoeging die makkelijk in te bouwen was. Toen had ik echt zoiets van : Zeg dat dan gewoon als je schijt hebt aan de mensen die je willen helpen

[Sardaukar]

EfBe schreef op woensdag 29 december 2010 @ 21:16:
[...]

Kennelijk niet. Die out of context quote is an sig wel waar, maar het gehele Bazaar gelul is onzin, immers, wie gaat de rekening betalen? Het idee dat al die duizenden kloppertjes over de gehele wereld savonds en in het weekend hun vrije tijd opofferen om en masse open source software te maken met zn allen is op papier met een naive met bier doordrenkte blik nog wel met enig enthousiasme te begroeten, maar dat neemt niet weg dat datzelfde idee van totaal alle realiteitszin ontbeert.

Zucht. De reden dat ik the Cathedral and the bazaar aanstipte is omdat ik het goed leesvoer vind voor mensen in deze discussie. Maar fijn dat jij het boek even kon samenvatten als 'gelul'.

Als jij bovenstaande conclusie trekt na het lezen van dat boek, begrijp ik je (negatieve) reactie. Wat ik er vooral aan heb over gehouden is het contrast tussen twee ontwikkelings methodes.

The essay contrasts two different free software development models:

• The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC are presented as examples.
• The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.

[Sardaukar]

Freeaqingme schreef op woensdag 29 december 2010 @ 20:59:
[...]
Zolang het solo is en jij daar blij mee bent moet je daar zeker geen roadmap voor neerleggen. Echter, wanneer je vraagt aan anderen of ze mee willen helpen aan je project, vind ik het een heel normale zaak dat je weet welke kant het op gaat.

De meeste projecten gaan niet aan anderen vragen of ze mee willen helpen.

Als het project goed genoeg is komen mensen zich vanzelf wel melden. (Misschien wel met features die jij niet voorzien had in je roadmap).

[roy-t]

Sardaukar schreef op woensdag 29 december 2010 @ 19:46:
[...]


"Every good work of software starts by scratching a developer's personal itch" - The Cathedral and the Bazaar. Goed leesvoer met betrekking tot deze discussie, maar dat terzijde.

Ik heb zelf een - heel klein - open source projectje. Ontstaan uit persoonlijke jeuk

Waarom zou ik daar van te voren al een roadmap voor neer moeten leggen? Ik zie daar de noodzaak niet van in.

Dat vind ik echt een ontzettend onware quote. Wat moet een developer nu bijvoorbeeld met een programa zoals Photoshop? Toch is dat een goed stuk software (ofzo). Nee die quote is veel te kortzichtig.

Verder kan ik me wel goed vinden in het "goede open-source projecten worden geleid door een bedrijf/consortium" of dat een gevolg of een oorzaak is weet ik niet.

Een positieve uitschieter is trouwens Farseer XNA, een OS 2D physics engine die wel redelijk ontwikkeld wordt, maar er is dan ook een vrij kleine scope.

[djc]

EfBe schreef op woensdag 29 december 2010 @ 09:49:
Jij gaat net als sommige anderen in deze thread voorbij aan wat FragFrog wil zeggen (denk ik), namelijk dat om een groter project succesvol voort te zetten moet je het team ook als team laten werken, je moet een richting hebben waarin het project zich beweegt, features die op die richting liggen moeten worden ontworpen, veelal met meerdere mensen binnen het team, er moet dus veel coordinatie plaatsvinden. Verder moet er veelal veel tijd gestoken worden in allerlei aspecten van het bouwen en beheren van de software.

Ik ben het er niet mee oneens dat je een bepaalde vorm van structuur in een team moet hebben om verder te komen met wat grotere projecten, maar ik ben het er wel mee oneens dat dat alleen maar kan door vanuit een bedrijf te werken, of met full time funded developers.

EfBe schreef op woensdag 29 december 2010 @ 09:49:
Bijna alle non-corporated funded OSS wordt gebouwd volgens het principe van "wil je iets, stuur me dan maar een patch', of door 1 persoon die in zn vrije tijd wat code klopt. Het patch-driven development principe werkt totaal niet voor grote projecten: je komt nauwelijks vooruit, het is afhankelijk van wat men aandraagt, belangrijke wijzigingen zijn afhankelijk van de inzet van vrijwilligers en er is geen deadline/planning wanneer die dit opleveren, immers ze zijn niet je werknemers.

Om een groter project in goede banen te leiden kun je niet afhankelijk zijn van derden die 'wellicht' een bug patchen of een nieuwe feature aandragen: uberhaupt is het twijfelachtig of iemand een feature bouwt die precies in de richting van waarheen het project moet gaan. Wat er gebeurt is dat men de projectwerkzaamheden consolideert in een groep en zorgt dat de voortgang gewaarborgd is: bv door full time developers, een hechte kern van developers die bv dicht bijelkaar wonen of anderzinds dagelijks contact hebben, zodat richting, feature planning, wie doet wat, welke feature beinvloedt welke andere features etc. etc. allemaal makkelijker verloopt.

Ik weet niet precies wat jij met patch-driven development bedoelt. Als dat is dat de developer niet luistert naar bugs die gerapporteerd worden zonder patch erbij, dan schaalt dat inderdaad niet naar grotere groepen. Maar in mijn ervaring nemen veel projecten bugs zonder patches ook serieus. Jij doet alsof het onmogelijk is voor een groep om zichzelf te organiseren, of voor een begaafde developer om een groep om hem heen te leiden, dat daar een soort van bedrijf voor nodig is. Ik ken genoeg projecten waaruit blijkt dat dat pertinent niet waar is.

EfBe schreef op woensdag 29 december 2010 @ 09:49:Wanneer een projectje klein is, en door 1 persoon behapt kan worden, dan zie je geen problemen. Maar zodra een projectje groter wordt, er een serie bugs staan te wachten alvorens nieuwe dingen in de code kan worden gebouwd, men moet besluiten wat te doen na de initiele release... dan wordt het kritiek en gaat bijna alle OSS software naar de slachtbank. De reden is simpel: niemand heeft zin om ellenlange lijsten bugs te fixen, men wil nieuwe dingen bouwen, immers, dat is niet saai. Ook wanneer de code niet optimaal geschreven is (bv zonder enige comments WAAROM de code zo is zoals ze is, design docs of anderzinds enige documentatie), is bugfixing nog naarder werk dan het al was. Na verloop van tijd is inbouwen van nieuwe dingen overigens ook geen fun meer, tenzij je dingen wilt breken en backwards compatibility je een worst zal zijn. Dan begint het spenderen van je vrije tijd aan dit soort projecten op 'werk' te lijken en haakt menigeen (ik durf wel te zeggen: bijna iedereen) af.

Een groep full-time developers, die betaald wordt om bugs te fixen, nieuwe dingen te bouwen binnen een vastgesteld kader, die kan dit wel, botweg omdat het hun werk is. De uitzondering die na zn baan nog tot 11-en OSS zit te schrijven om een idealistische reden daargelaten.

Natuurlijk faalt veel open source software, of ontgroeit het nooit een stadium waarin het maar voor een paar mensen interessant is. Maar dat is niet erg: ook als het maar voor een paar mensen nuttig is is het nuttige software, en het kan zomaar gebeuren dat andere mensen ermee verder gaan omdat het ook voor hun nuttig is. Bovendien denk ik dat je de impact van de uitzonderingen (wellicht ondersteund door een grotere groep developers die vanuit hun gewone werk kleinere features of bugfixes bijdragen) onderschat.

EfBe schreef op woensdag 29 december 2010 @ 09:49:
Ik zie je punt dan ook niet mbt 'de stichting of bedrijf is bedoeld om makkelijker geld te doneren', want daar is die constructie helemaal niet voor. Je kunt geen full-time developers betalen vanuit donaties alleen, wat is de motivatie om al dat geld op te branden? Immers je geeft het resultaat van wat je investeert weg.

Je voorbeeld mbt netscape is overigens fout. Andreesen is al vrij snel een bedrijf begonnen om de browser een commercieel succes te maken en dan met name via de webserver die Netscape verkocht (het was ook geen open source). De linux kernel lijkt ontwikkeld door een gezellige groep mensen, maar het is gewoon hardcore commerciele software, met het enige verschil dat de code beschikbaar is. Linux wordt al jaren ontwikkeld door developers die full time bezig zijn met linux kernel development, en daar gewoon voor betaald worden. Immers, het is de enige manier om ervoor te zorgen dat je wijzigingen kunt doorvoeren die als team gedragen worden.

Ik heb het niet over het begin van Netscape. Ik heb het over het begin van Mozilla: eerst als project binnen Netscape, toen met een zakje geld van Netscape doorgestart, en later met eigen inkomsten vanuit met name Google. Mozilla opereert vanuit idealistische principes en heeft een nogal heftige open source cultuur, waarin elke contributor op gelijke voet opereert, al worden sommigen er ook nog voor betaald worden (omdat geld geven nou eenmaal een goede manier is om de tijd van contributors te richten). Mozilla is een open source-project met een stichting en een bedrijf om het geld dat binnenkomt te verdelen.

En ja, Linux-bijdragen worden vooral ontwikkeld vanuit bedrijven, maar het is niet zo dat er een commercieel bedrijf kernel development organiseert (en zo lijk jij het wel voor te willen stellen). Linus wordt momenteel betaald door een stichting, individuele developers worden grotendeels betaald door bedrijven, maar binnen de kernel-community is het beslisproces niet commercieel gedreven. En aan dat proces wordt richting gegeven door Linus, die vooral wordt gedreven door zijn eigen motivatie (hij is zo'n uitzondering, die jij van de hand doet als irrelevant) en die ook nog geld kan verdienen met zijn eigen interesse.

EfBe schreef op woensdag 29 december 2010 @ 09:49:
En voordat iemand met zn naieve blik gaat beweren dat patch-driven development best werkt: nee, dat werkt voor geen meter: patches om een klein bugje te fixen: soit. Patches die lappen code refactoren en nieuwe features daardoor mogelijk maken en/of nieuwe features aandragen die bv meerdere subsystemen wijzigen... no way. Je krijgt dus een poliepenstructuur van code en dat valt binnen de korste keren in elkaar. Je krijgt features aangeleverd die nodig zijn voor de submitter, maar wellicht voor 90% van de gebruikers irrelevant, en andersom: naar werk dat wel relevant is voor 90% van de users blijft liggen omdat niemand het wil doen. Mooi voorbeeld is de linq provider van NHibernate. Dat is gewoon erg veel werk (lees: 8-10 maanden minimaal, full time). Nu hebben ze een 'linq provider' in 3.0 die veel dingen niet doet, gewoon omdat de enige persoon die zich daar toch voor heeft ingezet niet zoveel tijd had. Iemand anders had wel veel tijd maar geen zin om een linq provider te maken dus bedacht 'yet another query system', wat 1) ook weer niet 100% dekkend is en 2) niet standaard.

Nou, ik ken wel projecten waar refactoren in patches gewoon gebeurt en succes heeft, en waar geen poliepenstructuur ontstaat. Misschien zijn dat de grote uitzonderingen, maar ik denk dat dat wel meevalt.

Ik vraag me af in hoeverre jouw beeld van open source gekleurd is door het MS-ecosysteem waar je volgens mij vooral mee bezig bent, en in hoeverre dat ecosysteem anders is dan het POSIX-ecosysteem op deze punten.

[roy-t]

djc schreef op donderdag 30 december 2010 @ 11:04:
En ja, Linux-bijdragen worden vooral ontwikkeld vanuit bedrijven, maar het is niet zo dat er een commercieel bedrijf kernel development organiseert (en zo lijk jij het wel voor te willen stellen). Linus wordt momenteel betaald door een stichting, individuele developers worden grotendeels betaald door bedrijven, maar binnen de kernel-community is het beslisproces niet commercieel gedreven. En aan dat proces wordt richting gegeven door Linus, die vooral wordt gedreven door zijn eigen motivatie (hij is zo'n uitzondering, die jij van de hand doet als irrelevant) en die ook nog geld kan verdienen met zijn eigen interesse.

Ik vraag me af in hoeverre jouw beeld van open source gekleurd is door het MS-ecosysteem waar je volgens mij vooral mee bezig bent, en in hoeverre dat ecosysteem anders is dan het POSIX-ecosysteem op deze punten.

Ik snap niet hoe jij kunt denken dat als de ontwikkeling van Linux vooral gedreven wordt door bedrijven, dat de beslissing waar aan te werken niet komt uit die bedrijven. Als ik als IBM een groepje developers heb die aan de Linux kernel werken, dan geef ik ze echt wel een doel mee. Dat doel zal komen uit de strategie die IBM heeft met Linux. De patches van deze full-time-door-IBM-betaalde-Linux-Developers zullen gewoon geaccepteerd worden zolang het iets beter maakt/toevoegd. Soms zal dit niet gebeuren maar IBM zal dan in zijn eigen locaties die patches wel toepassen, waardoor de hele OS community er niet beter van wordt, maar IBM zelf wel.

Verder snap ik niet wat je bedoelt met MS ecosysteem. Bedoel je gewoon het algemene closed-source ecosysteem? Sowieso doet MS tegenwoordig wel veel voor OS, maar goed om het daar nu weer te gaan over hebben

[cariolive23]

EfBe schreef op woensdag 29 december 2010 @ 21:16:
Maar hoe bepaalt men of een feature nodig is of niet.

Goede vraag, maar dit is niet iets wat specifiek bij open source hoort. Ook voor closed source software zal ieder project deze vraag moeten beantwoorden. Kijk naar de markt, kijk naar de trends en luister naar de gebruikers (bv. op congressen, forums of mailinglists). Niks bijzonders dus.

Bij OSS en bij closed source moet je bij product development verder kijken dan wat de groep/het team vindt wat nodig is: je moet jezelf verplaatsen in degene waarvoor je het feitelijk maakt.

Exact! Geen enkel verschil tussen open source en closed source, kennen dezelfde uitdagingen.

Bij commerciele software zijn dat je betalende klanten, maar bij OSS, wie zijn het?

Vervang "betalende klanten" door "gebruikers" en je hebt het antwoord: De gebruikers. En dat geldt zowel voor closed source als voor open source, daar zit geen enkel verschil in.

veelal komt het erop neer dat men in de groep zelf kijkt wat men nodig heeft. Maar dat is nu juist _niet_ wat men moet doen en wat ik probeerde duidelijk te maken.

Dat is niet meer dan een aanname waarbij je (blijkbaar) ook aanneemt dat men niet wil luisteren naar de gebruikers. Er zijn vast en zeker projecten waar men deze fout maakt, dat gebeurt tenslotte ook bij closed source software: Menig bedrijf gaat hierdoor over de kop. Wat weer vergelijkbaar is met het stoppen van een open source project.

Dat het ene project anders is georganiseerd dan het andere project en dat bij het ene project open source wordt geproduceerd en bij het andere project closed source, so be it. Dit zegt echter helemaal niets null noppes nada over kwaliteit, stabiliteit of wat dan ook. Ik verbaas me iedere keer weer dat er mensen zijn die denken dat kwaliteit e.d. te maken heeft met "anders zijn". Het ene pakket zal nooit beter zijn dan het andere pakket "omdat het anders is". Kom met meetbare kwaliteitseisen, dan hebben we het ergens over.

[bobo1on1]

Ik werk mee aan XBMC, en heb mijn eigen projectje boblight: http://code.google.com/p/boblight/
Ik pruts graag met het een en ander in mijn vrije tijd, en daar is open source bij uitstek zeer geschikt voor, bij problemen kun je in de code van alle libraries graven die je gebruikt, en je kunt je eigen oplossingen met anderen delen.

Wat mij opvalt bij XBMC is de grote userbase, de Dharma release was in 3 dagen meer dan 100.000 keer gedownload.