Hoe begin ik een open source project?

[Dentist]

Voor een project waar ik binnenkort mee wil starten, wil ik waarschijnlijk open source development gaan toepassen. Niet alleen omdat ik denk dat ik daarmee een hoop kosten kan besparen, maar vooral omdat ik ervan overtuigd ben dat een community van programmeurs/gebruikers heel veel nuttigs kan bijdragen aan het project. Nu zit ik echter met een aantal vragen aan programmeurs die al eerder met dit bijltje hebben gehakt.

1) Hoe kan ik ervoor zorgen dat een open source project in goede banen geleid wordt? Zijn er bepaalde best practices om een OS traject in te richten?

2) Wat is de afweging bij het ontwikkelen van een API tegenover een volledig open source project? Ik kan me voorstellen dat development met een API beter te controleren is, maar aanloopkosten met zich meebrengt. Wellicht zijn er meer pro/cons voor API vs. OS?

Eigenlijk ben ik op zoek naar voorbeelden van OS best practices, aan de hand waarvan ik het development traject kan inrichten.

[Hydra]

Euh, dit klinkt een beetje alsof je nog niet weet wat je wil gaan doen?

[Dentist]

Hoe bedoel je? Ik weet qua project exact wat ik wil gaan doen in termen van een eindproduct en aan welke eisen dat minimaal moet gaan voldoen. Ik weet alleen nog niet of ik een OS traject beheersbaar genoeg kan maken om de moeite waard te zijn.

[Verwijderd]

Dentist schreef op maandag 25 juni 2007 @ 18:15:
2) Wat is de afweging bij het ontwikkelen van een API tegenover een volledig open source project? Ik kan me voorstellen dat development met een API beter te controleren is, maar aanloopkosten met zich meebrengt. Wellicht zijn er meer pro/cons voor API vs. OS?

Uhm, als ik je goed begrijp beweer je hier dat open source projecten per definitie geen stable API hebben ? Nochtans hebben KDE, Qt, GTK+, Glib, JUnit, Struts en honderden andere libraries weldegelijk API-stability, of in ieder geval branches waarbinnen de API stable blijft. Bovendien heeft een programma als het een utility is niet persé API stability nodig. Een FTP/P2P client kan gerust bijna elke release van de ground up herschreven worden, een library zoals libtorrent dan weer niet.

Als je net met een project begint is het inderdaad beter een aantal releases te doen waarbij je expliciet vermeldt dat de API nog niet vastaat en je een en ander uitprobeert. Ben je zeker van je stuk over het publiek geëxporteerde deel van je plugin-architectuur/API, dan kan je een 1.0 release maken. Bij wijzigingen aan de API staat een verhoging naar 2.0 op het programma, enz.

Het puntje over "een hoop kosten besparen" mag je mijns inziens toch even herbedenken. Open Source heeft ook een hidden cost van het managen van een community (forums, mailing lists, bug reports en feature requests). Bovendien mag je zeker niet verwachten dat als je een berg code via anonymous CVS beschikbaar stelt dat er 'tig gurus ter hulp zullen schieten om fouten uit de code te halen en features bij te bouwen. Het duurt jaren eer een project voldoende mindshare heeft opgebouwd voor zoiets kan gebeuren. Wat voor een project heb je trouwens voor ogen ? Een 'tigste webframework in Java of PHP krijg je, tenzij je technisch uitblinkt en de zaken met een frisse kijk aanpakt van z'n leven niet meer van de grond.

Voor de rest: maak een leuke website, een blog waar je je project en de vooruitgang met veel superlatieven omschrijft, wat je ermee kan doen, hoe je problemen snugger hebt opgelost, royaal doorsprenkeld met code-stukjes . Maak je code beschikbaar met een distributed concurrent versioning system zoals bazaar of mercurial (wat de rage is heden ten dage in GNU/Linux-land). Zorg voor een goed plan, een roadmap met deadlines voor releases (in het begin om de X weken een getagde versie, later om de 2 à 3 maanden) en een bérg tutorials vol men screenshots/diagramma's. Vooral dat laatste is belangrijk. Je code mag nóg zo goed zijn, als niemand een high-level beeld kan krijgen van hoe het in mekaar zit en hoe je eenvoudig X of Y voormekaar krijgt (bij voorkeur in vergelijking met andere, reeds bestaande software op dat gebied) zal je projectje een stille dood sterven.

Met meer informatie over wat je precies van plan bent, hoeveel mensen er initiëel aan zullen werken en wat je verwachtingen zijn kunnen er meer tips gegeven worden, maar momenteel is het een beetje koffie-dik kijken.

[Dentist]

Verwijderd schreef op maandag 25 juni 2007 @ 19:15:
[...]

Uhm, als ik je goed begrijp beweer je hier dat open source projecten per definitie geen stable API hebben ?

Ehm, nee. Ik beweer dat ik grofweg 2 wegen naar Rome zie. Ofwel een gesloten development traject van de core-code met daar bovenop een API, waarmee gebruikers dan aan de slag kunnen, ofwel een compleet open development traject.

Het puntje over "een hoop kosten besparen" mag je mijns inziens toch even herbedenken. Open Source heeft ook een hidden cost van het managen van een community (forums, mailing lists, bug reports en feature requests). Bovendien mag je zeker niet verwachten dat als je een berg code via anonymous CVS beschikbaar stelt dat er 'tig gurus ter hulp zullen schieten om fouten uit de code te halen en features bij te bouwen. Het duurt jaren eer een project voldoende mindshare heeft opgebouwd voor zoiets kan gebeuren.

Ik ben me meer dan bewust van een aantal hidden costs van OS projecten, daarom vraag ik ook naar best practices, zodat ik een goede afweging kan maken. Ik kan me bijvoorbeeld voorstellen dat ik ipv 5fte's 3fte's aan het werk heb icm een open source community (en een halve om het proces in goede banen te leiden).

Wat voor een project heb je trouwens voor ogen ? Een 'tigste webframework in Java of PHP krijg je, tenzij je technisch uitblinkt en de zaken met een frisse kijk aanpakt van z'n leven niet meer van de grond.

Ehm.. een webframework, nee dank je. Het gaat om een zeer specifieke webapplicatie, die leuke dingen moet gaan doen voor gebruikers

Voor de rest: maak een leuke website, een blog waar je je project en de vooruitgang met veel superlatieven omschrijft, wat je ermee kan doen, hoe je problemen snugger hebt opgelost, royaal doorsprenkeld met code-stukjes . Maak je code beschikbaar met een distributed concurrent versioning system zoals bazaar of mercurial (wat de rage is heden ten dage in GNU/Linux-land). Zorg voor een goed plan, een roadmap met deadlines voor releases (in het begin om de X weken een getagde versie, later om de 2 à 3 maanden) en een bérg tutorials vol men screenshots/diagramma's. Vooral dat laatste is belangrijk. Je code mag nóg zo goed zijn, als niemand een high-level beeld kan krijgen van hoe het in mekaar zit en hoe je eenvoudig X of Y voormekaar krijgt (bij voorkeur in vergelijking met andere, reeds bestaande software op dat gebied) zal je projectje een stille dood sterven.

Thanks, daar heb ik wat aan. Wat je zegt is dat ik voornamelijk zelf de leiding moet nemen bij het ontwikkeltraject? Zijn er beproefde methoden waarmee ik ontwikkelaars kan stimuleren mee te werken?

Met meer informatie over wat je precies van plan bent, hoeveel mensen er initiëel aan zullen werken en wat je verwachtingen zijn kunnen er meer tips gegeven worden, maar momenteel is het een beetje koffie-dik kijken.

Ik ben van plan een webapplicatie te ontwikkelen die processen stroomlijnt tussen bepaalde clients. De webapplicatie is eigenlijk een soort middle layer die bepaalde objecten uit een database richting verschillende clients (ieder met hun eigen rol) stuurt en daar ter plekke dingen mee doet. Je kan het een beetje vergelijken met een constructie als Last.fm, alleen dan op een totaal ander vlak.

[Harm]

Dentist schreef op maandag 25 juni 2007 @ 19:38:
[...]

Ehm, nee. Ik beweer dat ik grofweg 2 wegen naar Rome zie. Ofwel een gesloten development traject van de core-code met daar bovenop een API, waarmee gebruikers dan aan de slag kunnen, ofwel een compleet open development traject.

Ik snap nog niet zo goed waarom je die twee uit elkaar haalt. Een stabiele api en opensourcedevelopment sluiten elkaar niet uit. Je kunt prima samen met een community een applicatie ontwikkelen, terwijl de api amper of juist veel verandert. Zolang jij maar helder en duidelijk communiceert over api-wijzigingen maakt het niets uit of je het ding in de openbaarheid van het oss-project of in de beslotenheid van je eigen toilet ontwikkelt.

Dentist schreef op maandag 25 juni 2007 @ 19:38:
[...]

Ik ben me meer dan bewust van een aantal hidden costs van OS projecten, daarom vraag ik ook naar best practices, zodat ik een goede afweging kan maken. Ik kan me bijvoorbeeld voorstellen dat ik ipv 5fte's 3fte's aan het werk heb icm een open source community (en een halve om het proces in goede banen te leiden).

De beste tip die ik voor je heb is dat je een paar weken andere opensourceprojecten zou moeten volgen. Meld je aan op een aantal interessante mailinglists van een bepaald project en lees mee. Zoek de wiki's op. Ga eens kijken op wat voor manier men code schrijft en hoe er gediscussieerd wordt. Check code uit, wijzig iets en ga die wijziging vervolgens toegevoegd laten krijgen. Door mee te doen, leer je snel genoeg op wat voor manier een oss-ontwikkelmethode werkt en vooral wat niet werkt. Dat is niet iets wat je uit boekjes kunt leren imho.

Dentist schreef op maandag 25 juni 2007 @ 19:38:
[...]

Thanks, daar heb ik wat aan. Wat je zegt is dat ik voornamelijk zelf de leiding moet nemen bij het ontwikkeltraject? Zijn er beproefde methoden waarmee ik ontwikkelaars kan stimuleren mee te werken?

Neem inderdaad zelf de leiding, communiceer veel naar buiten (weblog, mailinglist) en wees volledig open. Vergeet ook niet te melden dat je op zoek bent naar medeontwikkelaars en dat je hen graag wil helpen en bijstaan. De zaken die Hawk noemt zijn inderdaad erg waardevol.

[Dentist]

Harm schreef op maandag 25 juni 2007 @ 22:49:
[...]

Ik snap nog niet zo goed waarom je die twee uit elkaar haalt. Een stabiele api en opensourcedevelopment sluiten elkaar niet uit.

Dat begrijp ik, maar het verandert wel degelijk de basis van het project. Ik kan besluiten om een api uit te geven en dan gebruikers aan de slag laten gaan, nadat ik de applicatie inhouse heb ontwikkeld. Dan hoef ik helemaal niets te managen. Ik kan ook de applicatie én de api open source ontwikkelen, waarbij ik wel een boel user-input moet managen. Dat is nogal een verschil.

Je kunt prima samen met een community een applicatie ontwikkelen, terwijl de api amper of juist veel verandert. Zolang jij maar helder en duidelijk communiceert over api-wijzigingen maakt het niets uit of je het ding in de openbaarheid van het oss-project of in de beslotenheid van je eigen toilet ontwikkelt.

Duidelijk. Het gaat me alleen om het moment waarop ik een deel van de ontwikkeling uit handen geef en welk deel dat dan is (de applicatie, de api, helemaal niets).

[djc]

Begin eens met het lezen van Producing Open Source Software. Daarnaast lijk je er nogal gemakkelijk vanuit te gaan dat de developers ook daadwerkelijk geïnteresseerd zullen zijn in jouw project. Dat je er vanuit gaat dat je minder developers nodig hebt als je open source software ontwikkelt vind ik nogal een far cry. Externe developers gaan sowieso pas meewerken als jij een nuttig product benadert, en voordat je zo ver bent zal het nog wel even duren. Een belangrijk deel van de Open Source projecten wordt nog steeds aangestuurd door 1 lead developer, die aan het project begonnen is, waar andere devs slechts beperkte bijdragen doen.

[Dentist]

Manuzhai schreef op dinsdag 26 juni 2007 @ 09:16:
Begin eens met het lezen van Producing Open Source Software.

Thanks!

Daarnaast lijk je er nogal gemakkelijk vanuit te gaan dat de developers ook daadwerkelijk geïnteresseerd zullen zijn in jouw project. Dat je er vanuit gaat dat je minder developers nodig hebt als je open source software ontwikkelt vind ik nogal een far cry. Externe developers gaan sowieso pas meewerken als jij een nuttig product benadert, en voordat je zo ver bent zal het nog wel even duren. Een belangrijk deel van de Open Source projecten wordt nog steeds aangestuurd door 1 lead developer, die aan het project begonnen is, waar andere devs slechts beperkte bijdragen doen.

Opvallend dat iedereen allemaal aannames maakt, die ik zelf nog helemaal niet maak. Ik ga helemaal nergens makkelijk vanuit, ik stel gewoon een vraag, waarbij ik erachter probeer te komen wat de voor/nadelen zijn van een oss-project voor een businesscase. Ik zeg niks over het aantal developers dat ik nodig heb (hooguit op een conceptueel niveau dat ik zou kunnen begrijpen dat het aantal onder andere afhankelijk is van een keuze tussen open source en closed source).

Ik begrijp een heleboel dingen over open source / closed source & open development vs. closed development. Waar ik graag meer informatie over zou willen lezen, zijn best practices, om te kunnen toetsen of mijn waardering van de factoren die in mijn geval meespelen enigszins correct is.

[Confusion]

Ik heb nog geen ervaring met het ontwikkelen van een open source product, maar maak wel veel gebruik van open source producten en lurk op een hoop (dev) mailinglists. Een aantal opmerkingen naar aanleiding daarvan:

Mijn indruk is dat open source projecten het beste werken, en de beste producten voortbrengen, onder benevolent dictatorship, waarbij de dictator niet alleen een belangrijke functie als dirigent, klankbord en motivator, maar ook (vooral in het begin) code bij moet dragen en knopen moet doorhakken. Democratische beslissingsprocessen zijn te traag als je een beetje voortgang wilt.

Het niet hebben van deadlines lijkt noodzakelijk te zijn: je weet nooit wanneer vrijwilligers bij beginnen te dragen en hoeveel ze bijdragen, dus je kan eigenlijk alleen op de eigen input rekenen.

Als het product populair is, zal je hopen (foutieve) bugmeldingen en feature requests moeten verwerken. Daar moet je middelen voor hebben en een visie die zorgt dat het product geen aan elkaar hangende bundel requested features wordt.

[Alarmnummer]

Je moet verder ook rekening houden met de enorme hoeveelheid tijd die er in kan komen te zitten. Ik ben zelf ook bezig met een open source project, en naast mijn werk is dit een hele opgave.

Hoogstwaarschijnlijk kan ik het project (en vooral functionaliteit dat nu nog in de sandbox zit) binnenkort bij een klant gaan inzetten, dus dan hoef je niet 2 levens meer te leiden Maar je bent erg veel tijd kwijt als je alles op moet zetten (naast het ontwikkelen van de software zelf).

[Dentist]

Goed om zo eens wat ervaringen te horen.. Waar behalen jullie volgens jezelf de winst bij het open source ontwikkelen?

[ Voor 8% gewijzigd door Dentist op 26-06-2007 09:59 ]

[Hydra]

Dentist schreef op maandag 25 juni 2007 @ 18:22:
Hoe bedoel je?

Ik bedreep niet precies wat je bedoelde met het verschil tussen een API en een OS project, nu wel. Nevermind

Zelf denk ik dat het grootste voordeel aan een volledig OS project is, dat je meerdere mensen hebt die meewerken aan je code. Niet alleen maken vele handen licht werk, je hebt ook het voordeel dat meer mensen je code bekijken. "Many eyes make bugs shallow".

Volgens mij het is grootste 'probleem' mensen inspireren om mee te werken aan het project. Ik weet niet in hoeverre je idee al uitgewerkt is, maar een projectplan waarin duidelijk en enthousiast omschreven is wat je precies wil gaan maken is naar mijn idee een must. Je moet zo'n projectplan een beetje zien aan een bussiness-plan; je probeert je idee te verkopen door andere mensen enthousiast te maken.

Dentist schreef op dinsdag 26 juni 2007 @ 09:56:
Goed om zo eens wat ervaringen te horen.. Waar behalen jullie volgens jezelf de winst bij het open source ontwikkelen?

Je werkt aan een project samen met mensen die meewerken omdat ze het leuk vinden. Mensen die enthousiast zijn over iets werken volgens mij harder en beter dan mensen die op een project gezet worden omdat ze in loondienst zijn. Daarnaast is het een manier om 'grote' projecten in je eigen tijd te doen zonder dat je daarvoor tijd/geld vanuit je werk nodig hebt.

Het nadeel is vaak weer dat er weinig commerciele druk achter zit. Je kunt er bij open-source niet zonder meer vanuit gaan dat je software krijgt die bug-free is, en waar ook voldoende support achter zit als blijkt dat er grote bugs in zitten.

[djc]

Dentist schreef op dinsdag 26 juni 2007 @ 09:31:
Ik begrijp een heleboel dingen over open source / closed source & open development vs. closed development. Waar ik graag meer informatie over zou willen lezen, zijn best practices, om te kunnen toetsen of mijn waardering van de factoren die in mijn geval meespelen enigszins correct is.

Daarvoor moet je dat boek lezen, dat staat helemaal tjokvol met best practices. Verder ben ik het op vele punten met de post van Hydra hierboven eens, met name wat betreft het enthousiasmeren van developers en het verschil tussen intrinsieke motivatie en externe motivatie dat hij aanstipt (intrinsiek = omdat men het leuk vindt, extern = bijvoorbeeld geld).

[ Voor 22% gewijzigd door djc op 26-06-2007 12:03 ]

[Dentist]

Goed, dat zal ik binnenkort eens even doorlezen dan Dank voor de input.

Op dit moment zit ik met twee projecten, waarvan een (www.spelersmarkt.com) al draait en een ander nog niet. Boor beiden ben ik de afweging aan het maken om een deel open source te maken, maar zoals ik er nu tegenaan kijk, denk ik dat ik het 2e project lekker even met een eigen team van programmeurs ga opzetten, niet in de laatste plaats omdat daar een echte business achter komt te hangen...

Voor wat betreft spelersmarkt, dat ik binnenkort misschien wil gaan uitbreiden wat functionaliteit betreft, vraag ik me nog een beetje af of ik een API zou moeten maken of de code zou moeten vrijgeven... Suggesties?

[ Voor 6% gewijzigd door Dentist op 26-06-2007 12:15 ]

[FuzzyLogic66]

Ik ben redelijk nieuw in het hele open source gebeuren, ik gebruik wel vaak open source programma's enzo, draai sinds kort ook Ubuntu, dus ik heb er al veel ervaring mee, maar heb me er eigenlijk nog nooit eerder veel in verdiept. Sinds kort echter wel, en er viel me één ding zeer op.

Het is namelijk zo dat de hele opensource gebeuren voornamelijk (ik zeg voornamelijk, gelukkig niet helemaal) door programmeurs wordt beheerd. Zonder goede programmeurs kan een OS project natuurlijk niet slagen, maar het probleem is dat er (vooral bij kleine) opensource projecten eigenlijk geen (web)designers bij betrokken zijn. Naast het leveren van geweldige, stabiele en kwaliteitproducten is het ook belangrijk dat het project goed gepresenteerd wordt aan de publiek. Dit is niet zo van belang bij projecten die alleen voor devs zijn (bv. libraries etc.), maar voor producten die bedoeld zijn voor jan en alleman is dit ontzettend belangrijk.

Een goed voorbeeld hiervan is het programma Gimp. Het schijnt een geweldig design programma te zijn (ik weet het niet, ben nou eenmaal gewend aan Photoshop) en dat is het misschien ook wel, maar dat straal je absoluut niet uit met zo'n website. Een website voor een design programma hoort te laten zien wat het programma allemaal kan, het moet stimulerend zijn voor de bezoeker om het programma te gebruiken. Je moet door middel van uitdagende screenshots, effectjes en kleuren de gebruiker onbewust 'dwingen' om het programma te gebruiken. Pas dan kunnen ze ervaren hoe geweldig het product wel niet is.

Nog een voorbeeld is het boek waar eerder in dit topic naar verwezen was. Ik citeer het stukje over websites:

There is not much to say about setting up the project web site from a technical point of view: setting up a web server and writing web pages are fairly simple tasks, and most of the important things to say about layout and arrangement were covered in the previous chapter. The web site's main function is to present a clear and welcoming overview of the project, and to bind together the other tools (the version control system, bug tracker, etc.). If you don't have the expertise to set up a web server yourself, it's usually not hard to find someone who does and is willing to help out. Nonetheless, to save time and effort, people often prefer to use one of the canned hosting sites.

Waar hier op wordt ingegaan is wat voor inhoud de website moet hebben en over de technische gedeelte. Terwijl een goed en atractief ogende website ook heel belangrijk is. Veel OS software wordt in veel mindere mate gebruikt omdat het niet goed wordt gepresenteerd aan het grote publiek. Wat heel veel mensen willen is eye candy naast goede producten.

Het moraal van dit verhaal: betrek er ook een webdesigner bij. Want je zult vast een geweldig product ervan maken, maar jullie als programmeurs kunnen écht geen website produceren die de huisvrouw om de hoek aanspreekt om het te gebruiken.

[ Voor 24% gewijzigd door FuzzyLogic66 op 30-06-2007 02:46 ]