Opzetten OSS project

Nadat over tijd toch wel duidelijk is geworden dat een ontwikkelaar van een OSS project er geen energie in meer wil steken, wil ik een huidig project herschrijven en uitgeven onder de GPL. De oude code is onduidelijk, erg buggy, en een rewrite is zeer waarschijnlijk sneller. Het geeft ook de mogelijkheden de tekortkomingen van de oude software te verbeteren, en nieuwe nuttige features toe te voegen. De community achter de software hunkert naar een nieuwe versie.

Ondertussen had ik een tool geschreven, die inmiddels 90% af is. Die code ga ik gebruiken als basis voor de nieuw op te zetten software (hier is al rekening mee gehouden in het ontwerp van de code, omdat ik zoiets al aan zag komen).

Het zal erop neerkomen dat ik de ontwikkelaar wordt die de kar van het project gaat trekken. De community heeft aangegeven wel te willen helpen waar mogelijk. Mijn taak zal dus niet alleen het schrijven van code worden, maar meer een soort van projectmanager. Er zijn een hoop zaken om de software heen die ook gedaan moeten worden. Bijvoorbeeld het schrijven van documentatie, UI design, testen, handleiding, wiki, forum, website, en ga maar door. Als ik die zaken andere mensen kan laten doen die dat graag willen, dan is dat alleen maar winst.
Ik ga de community faciliteren door ontwerp documentatie te schrijven, die uit de doeken doet hoe ik het allemaal voor ogen zie. Dus UI sketches, data model documentatie, format van de handleiding, architectuur van de applicatie, zo'n beetje alle ideeën die rondzwerven in mijn gedachten over deze app. Het idee is dan dat anderen weten hóé ze kunnen helpen door de docs te lezen.

Ik heb totaal geen ervaring met het opzetten van een open-source project. Ik weet dat er een hoop websites zijn, zoals freshmeat, sourceforge, codeplex, waar je dit soort projecten kan opzetten en onderhouden. Ik heb alleen nul ervaring met dergelijke websites als committer. De zaken die ik nodig denk te hebben om succesvol het project te laten lopen, zijn:

• Source control repository
• Wiki
• Forum
• Bugtracking
• Webspace voor aanverwante zaken
• Applicatieserver (met de custom written server-side software)
• .NET 3.5 ondersteuning (zover als dit relevant is)

Wat ik graag wil weten, is welke ervaringen jullie als committer hebben met verschillende OSS project hosting websites. Voor mij zijn er twee opties: Ik ga naar een externe site (zoals freshmeat) of ik zet het op op mijn eigen server (met goede hardware + verbinding). Dat laatste is mogelijk, en heeft het voordeel dat ik 100% controle heb. Maar zorgt wel voor (redelijk wat) meer werk. Wat raden jullie aan? Zeer waarschijnlijk gaat de server-side software er wel op draaien, aangezien het lastig is om dat op een OSS site te zetten. Houdt in gedachten dat het project geschreven is in C# 3.0, .NET 3.5.
Ook zou ik graag willen weten of jullie nog tips hebben met betrekking tot het opzetten/onderhouden van een OSS project. Wat zijn de do's en don'ts? Waar moet ik rekening mee houden?

_{Rechtvaardiging:
Er zijn al een paar clonen van de software te vinden op het net, het is zeker geen unieke software in die zin. Het punt waar deze software uniek in gaat zijn is de UI die het bied. .NET 3.5 geeft ongekende mogelijkheden met betrekking tot het snel en effectief ontwerpen van goede UI's. Alle andere klonen zijn echt inferieur aan wat ik in gedachten heb op het gebied van UI.}

Freshmeat is geen oplossing omdat die voor unix projecten is.

Sourceforge is een redelijke start, echter die heeft wat problemen met uptime door de jaren heen. heeft echter geen .NET hosting, maar staat toe een gedeelte op eigen server te hosten:

* Source control repository --> keuze uit svn(cvs opvolger) en cvs
* Wiki --> staat op sf, maar denk na over eigen site....
* Forum --> erg basaal forum is of sourceforge. aardig om te starten.
* Bugtracking --> sourcefoge bugtracking si een soort forum, aardig om te beginnen, ligt eraan hoe gestuctueerd je dit gaat oppakken en wat het nivo van gebruikers is.
* Webspace voor aanverwante zaken --> sf geeft onbeperkte php webruimte, wel traag. downloads diene te gebeuren via file releases. (ook onbeperkt)
* Applicatieserver (met de custom written server-side software) --> geen .net, wel php met database.
* .NET 3.5 ondersteuning (zover als dit relevant is) -> (geheel) niet op sf.net

Echter je bent op sf niet verplicht alles te gebruiken. File releases + versie control + wiki sou je b.v. op sf kunnen starten en de rest op eigen server.

Do en don't: bouw een dikke huid op. Er zullen een aantal mensen komen die van alles eisen, weinig bijdragen. Je zult veel gescheld horen op de software, en weinig complimenten voor wat wel goed gaat. Heb een lange adem, tussen een werkend stuk software en een stabiel getweakt systeem zit een lange tijd (reken op een jaar)

Sourceforge is leuk, maar de enorme traagheid van de site en van SVN maakt het nogal onbruikbaar. Ik zit over het algemeen te committen met 1 of 2 KB/sec, en dat is langzaam. Je ziet ook dat een hoop grotere projecten alleen nog hun filehosting van de releases door Sourceforge laten doen, en zelf SVN, een bugtracker en de website hosten.

Misschien is het toch handig als ik wat specifiekere informatie geef over de applicatie. Het gaat om een spel, een digitale versie van het bekende bordspel Kolonisten van Catan. De concurrenten, er zijn er 5-6, hebben allen een hele gare 2D interface (op de Microsoft versie na, en de versie die ik ga verbeteren). Mijn doel is om het spel zó vorm te geven, dat je een daadwerkelijke representatie van een bordspel ook op je scherm ziet. In 3D, met duidelijke UI.
Omdat het een spel is, komen er zaken bij kijken als content en artwork. Deze kunnen nogal wat ruimte op de server in nemen.
De tool die ik al had geschreven stelt je in staat een eigen bord te ontwerpen waar je dan vervolgens op kan spelen. All data structuren/3D klasses kan ik hergebruiken voor de game.

Waarom wil ik dit project doen?
Ik wil meer van het .NET 3.5 framework leren kennen. Ik wil oefenen in het schrijven van netwerk code, het maken van 'compelling UI's'. Ik wil design patterns kunnen beheersen (in de zin dat ik niet alleen weet waar een pattern voor nodig is, maar ook waaneer je hem gebruikt). Verder wil ik zelf een gehele applicatie kunnen ontwerpen. Ook wil ik ervaring opdoen in het maken van een game, dat heb ik al sinds ik 10 was op de MSX-2 van mijnnouders als doel gehad . Verder wil ik me ontwikkelen op het gebied van project management, wat erbij komt kijken en hoe je zaken regelt.
Een OSS project zelf opstarten met een levendige community erachter lijkt me hiervoor erg geschikt .

Da's het mooie van open-source. Start gewoon een project, bouw het tot een eerste alpha en ga dan pas naar je gebruikers luisteren. In het begin is het gewoon belangrijk dat je voornamelijk je version control op orde hebt, dat achteraf wijzigen is namelijk behoorlijk lastig. Zorg voor een leuke website, gooi bij de eerste release een forum open en dan terwijl je doorontwikkeld een beetje de gebruikersfeedback in de gaten houden.

Je zou ervoor kunnen kiezen om pas later een bugtracker te maken, maar ik doe dat altijd al bij het starten van een project. Ik houd daar namelijk zelf ook mijn bugs en taken in bij, wat erg handig voor je administratie is. Ook voorkom je zo dat anderen bugs gaan submitten die al op je lijstje staan.

Probeer trouwens niet alle feature requests van je gebruikers in te bouwen. Natuurlijk is het erg leuk om iedereen tevreden te stellen, maar dat lukt je toch niet. Ook moet je voor sommige requests dusdanig hacken in je code dat het niet altijd mogelijk is om het netjes te doen. Maak gewoon voor jezelf een soort roadmap waarop je je visie van het spel vermeld en wat het allemaal moet kunnen. Dan kan je altijd nog per request bepalen of je het in gaat bouwen of niet. Als je het niet doet, communiceer dat dan ook naar je gebruikers. Open communicatie wordt bijzonder op prijs gesteld.

[edit]
En nog een toevoeging, let op de kosten. In het begin kan het heel leuk zijn om meteen een dure VPS te nemen met een dikke website, SVN, etc. erop. Maar mocht je product toch minder populair zijn dan je dacht is dat alleen maar zonde van het geld. Probeer zo lang mogelijk van goede gratis diensten gebruik te maken, en vergeet niet dat je aan OSS best wat geld mag verdienen. Als het goed gaat lopen kan het best lonen om donaties te gaan vragen.

AtleX wijzigde dit bericht 27-06-2008 19:59 (14%)

quote:

Probeer trouwens niet alle feature requests van je gebruikers in te bouwen.

Ik heb zelf denk ik de meeste features in gedachten. De community wil graag dezelfde client als ze al hadden, alleen dan zonder bugs. Dat zal dus voornamelijk een gevecht tegen mezelf worden .

Over de kosten: Ik heb al een eigen server met een dikke verbinding. Dat kost me geen rooie cent, en ik kan er alles op hosten. Wellicht zal alleen de applicatieserver, wanneer het live gaat, geld kosten. Maar ook die kan ik hosten op mijn eigen verbinding, en ik kan er misschien nog wat ads op kwijt.

quote:

Maak gewoon voor jezelf een soort roadmap waarop je je visie van het spel vermeld en wat het allemaal moet kunnen. Dan kan je altijd nog per request bepalen of je het in gaat bouwen of niet.

Zoiets heb ik inderdaad al in de planning.

quote:

Als je het niet doet, communiceer dat dan ook naar je gebruikers. Open communicatie wordt bijzonder op prijs gesteld.

Goed punt, communicatie is een van mijn slechtere kanten in software ontwikkeling. Zeker met een OSS project lijkt me dit ontzettend belangrijk.

quote:

In het begin is het gewoon belangrijk dat je voornamelijk je version control op orde hebt, dat achteraf wijzigen is namelijk behoorlijk lastig.

Hoe bedoel je dit? Is toch gewoon het opzetten van een (SVN) source repository? Of zie ik hier iets over het hoofd? Wat zijn de speerpunten bij het opzetten hiervan?


Overigens is één van mijn eigen doelen 100% cleane code op te leveren. Geen rare hacks, alles volgens het boekje. Alles voorspelbaar en logisch. Nu weet ik dat dat eigenlijk een utopie is, zeer weinig software projecten hebben dergelijke code. Maar het zou toch mogelijk moeten zijn om de meeste code clean te houden.

Ruudjah wijzigde dit bericht 27-06-2008 20:15 (10%)

quote:

Ruudjah schreef op vrijdag 27 juni 2008 @ 20:13:
Hoe bedoel je dit? Is toch gewoon het opzetten van een (SVN) source repository? Of zie ik hier iets over het hoofd? Wat zijn de speerpunten bij het opzetten hiervan?

De structuur van je repository is erg belangrijk. Een veel gemaakte fout is alles gewoon in de root gooien, maar als je dan wilt gaan branchen heb je al een probleem. Een veel gebruikte structuur is:

-root
   -Tags
   -Trunk
   -Branches

De trunk is gewoon je werkmap zal ik maar zeggen. Daar staat gewoon altijd de laatste versie. Tags zijn releases en andere speciale versies, en in Branches gooi je de verschillende branches die je weer terug kunt mergen naar je trunk.

quote:

Overigens is één van mijn eigen doelen 100% cleane code op te leveren. Geen rare hacks, alles volgens het boekje. Alles voorspelbaar en logisch. Nu weet ik dat dat eigenlijk een utopie is, zeer weinig software projecten hebben dergelijke code. Maar het zou toch mogelijk moeten zijn om de meeste code clean te houden.

Als je vooraf goed nadenkt over je ontwerp kom je een heel eind. Tip, gebruik een whiteboard, voor 10 euro heb je al een kleintje en als je de lijst eraf haalt kan je er meerdere tegen elkaar aan hangen. Op papier een ontwerp opzetten vind ik persoonlijk niet prettig, je kan niet eenvoudig iets weghalen of toevoegen. Ook begin ik niet meteen op de computer, dan ga ik al teveel nadenken over details. Nogmaals, dit is wel mijn eigen werkwijze, misschien vind jij iets anders veel prettiger.

Houd er trouwens rekening mee dat je ontwerp niet eeuwig meegaat, "uitbreidbaar" en "onafhankelijk van elkaar" klinkt leuk in het begin maar je loopt hoe dan ook ooit tegen dingen aan die niet mogelijk zijn binnen je ontwerp. Wees dan bereid het aan te passen en je code te refactoren. Hacken binnen je bestaande ontwerp is niet slim, de leesbaarheid en onderhoudbaarheid van je code gaan hard achteruit.

[en weer een edit]
Cleane code is ook voorzien van commentaar, en niet achteraf toegevoegd waardeloos commentaar maar goed commentaar. Trust me, daar help je jezelf echt mee.

AtleX wijzigde dit bericht 27-06-2008 20:27 (4%)

Als je besluit het op je eigen server te zetten, kijk dan ook eens naar Trac. Die bevat een wiki, source control browser (met timeline etc.), ticket systeem (voor bugs bijvoorbeeld), etc. En met plugins kun je bijvoorbeeld allerlei zut nog doen (ik had hem automatisch na elke commit m'n sourcecode laten compileren).

code:

-root
   -Tags
   -Trunk
   -Branches

Zoiets heb ik al in gedachten. alleen dan wél met zinvolle namen . Ik ben namelijk 100% vóór verbosity . Goed dat je het nogmaals even onder de aandacht brengt.

quote:

Tip, gebruik een whiteboard, voor 10 euro heb je al een kleintje en als je de lijst eraf haalt kan je er meerdere tegen elkaar aan hangen. Op papier een ontwerp opzetten vind ik persoonlijk niet prettig, je kan niet eenvoudig iets weghalen of toevoegen. Ook begin ik niet meteen op de computer, dan ga ik al teveel nadenken over details. Nogmaals, dit is wel mijn eigen werkwijze, misschien vind jij iets anders veel prettiger.

Bedankt voor de tip . Mijn gehele kamer is en whiteboard, ik kan echt niet meer zonder zo'n ding. Ik heb denk ik een goede 20m2 whiteboard, moet genoeg zijn dunkt me . Daarnaast heb ik nog een interactief whiteboard (wii+beamer) en een Irex Iliad waar ik op kan krabbelen. Dus wat dat betreft zit het wel pluis.

Over de code heb ik niet echt nagedacht, ik ben gewoon gestart met coden. dat heeft geresulteerd in driemaal het compleet herschrijven van de core componenten (.NET 2.0 begonnen, herschreven, nu dus WPF). Momenteel zie ik het erg rooskleurig in wat betreft het ontwerp. Het lijkt logisch te zijn, lijkt te kloppen met een hoop theorieen die wijzen op papier hebben gezet. Nu nog hopen dat het een architectuur is die meegaat waarvoor het ontworpen is . Door het driemaal herschrijven en herdenken van de architectuur ligt er nu iets wat denk ik een eind gaat komen. Ik heb speciaal aandacht besteed aan het zo duidelijk mogelijk maken van deze architectuur (KISS). Een inspringende coder moet binnen 15 minuten kunnen begrijpen hoe het feest in elkaar zit. Ik denk dat de huidige code, in combinatie met het commentaar en de (technische) documentatie hier wel voor kan zorgen. De vraag is natuurlijk hoe dat in toekomst blijft, maar ik verwacht hier niet al te veel problemen.

quote:

Cleane code is ook voorzien van commentaar, en niet achteraf toegevoegd waardeloos commentaar maar goed commentaar. Trust me, daar help je jezelf echt mee.

25% van alle regels code (échte LOC dus, geen whitespace of curly braces) is momenteel commentaar. Niet slecht denk ik zelf, een hoop code die ik tegenkom op mijn werk of andere projecten halen de 10% soms niet eens . En ik zei al, ik ben vóór verbosity, dus ik denk en hoop dat het commentaar ook nog eens verhelderdend werkt. Ik wilde eigenlijk met de Literate Programming methode werken. Echter is hier nauwelijks een ecosysteem rond op gang gekomen, dus ik hoop dat dat over een paar jaar anders is.

Trac ken ik als systeem, en werkt erg aardig. Een groot nadeel vind ik dat er geen WYSIWYG editor beschikbaar is, waardoor het toch weer een hoop tijd vergt om de informatie te presenteren zoals ik het graag wil (het blijft, net als hier op GoT, toch altijd kloten met de speciale syntax. Bericht posten, checken, aanpassen, checken, etc....). Momenteel neig ik het meeste naar een MOSS2007 systeem met SVN voor sourcecontrol op mijn eigen server gehost. Hier moet ik alleen nog een hoop code voor MOSS schrijven, omdat MOSS hier dus eigenlijk niet voor gemaakt is. Overigens vind ik het een erg sterk punt van TRAC dat ze het systeem simpel, maar doeltreffend (pragmatisch) hebben gehouden. Dat werkt dan wel weer in het voordeel van mijn productiviteit. Maar TRAC heeft nogal wat ruwe kantjes die me toch al best wat tijd hebben gekost. MOSS2007 heeft deze minder, en heeft een WYSIWYG editor. Maar ik ben eigenlijk nog op zoek naar een beter systeem dan MOSS of TRAC.

Ik zou niet voor een eigen server gaan voor de repository, wiki en aanverwante zaken. Met google code en google groups kom je al een heel eind. Kijk anders ook naar Github.

Mijn motivatie om niet zelf te hosten is, dat je je wil concentreren op het sturen van je project en niet op beheren van de infrastructuur. Wees zuinig met je energie. Het hoeft er in eerste instantie niet gelikt uit te zien, het moet gewoon werken.

Een open source project is echt succesvol als het ook zonder de oprichter verder kan gaan. Probeer daarnaar te streven, zelf de grote lijnen uitzetten en bewaken, maar het uitnodigend houden voor anderen om mee te doen.

quote:

Ruudjah schreef op zaterdag 28 juni 2008 @ 01:20:
code:

-root
   -Tags
   -Trunk
   -Branches

Zoiets heb ik al in gedachten. alleen dan wél met zinvolle namen . Ik ben namelijk 100% vóór verbosity . Goed dat je het nogmaals even onder de aandacht brengt.

Uh... ho Die namen zijn conventie, zinvoller als dit krijg je ze niet Altijd die structuur aanhouden op de root, anders heb je je eerste overtreding op je eigen adagium 'alles volgens het boekje' al gescoord.

Zoals hierboven al is gemeldt is een goede communicatie met je gebruikers wenselijk echter moeten ze de ontwikkeling niet in de weg zitten. Sta voor suggesties open en motiveer de community om bij te dragen maar uiteindelijk doe jij het werk en ben jij de benevolent dictator.

Misschien heb je iets aan How Open Source Projects Survive Poisonous People (And You Can Too)

Ik ben een beetje partijdig (ben zelf developer), maar ik kan je het DVCS Mercurial aanraden. Distributed Version Control Systems maken communicatie met andere developers een stuk makkelijker, zijn in veel opzichten sneller en beter in het bijhouden van diverse branches (met name het mergen ervan). In tegenstelling tot git werkt Mercurial ook goed op Windows-systemen, en het is een stuk sneller dan Bazaar en Subversion.

Verder is er een goede Mercurial plugin voor Trac, een wiki + bug tracker + repository browser die ik al jaren gebruik (evenals vele andere projecten) en die erg goed werkt (is ook net een nieuwe versie van uit).

Bedankt voor de tip. Sinds jouw tip was ik niet bekend met het DVCS concept. Het ziet er aardig uit, en er zijn ook GUI tools voor beschikbaar. Maar ik denk dat het werken met een DVCS een nieuwe leercurve met zich meebrengt. Bovendien is version control niet mijn sterkste punt, ik heb al vaak genoeg ruzie met SVN. Laat ik dat eerst onder controle hebben. Bovendien zijn andere developers ook al vaak bekend met SVN.

Ik denk dat mijn huid redelijk dik is op de meeste punten, alhoewel ik denk ik op een paar gebieden wel mijn zwaktes heb. Ik denk dat ik miosschien eerst een SWOT voor mezelf maak, dat ik in ieder geval goed voorbereid het slagveld op ga.

quote:

Uh... ho Die namen zijn conventie, zinvoller als dit krijg je ze niet Altijd die structuur aanhouden op de root, anders heb je je eerste overtreding op je eigen adagium 'alles volgens het boekje' al gescoord.

Hmm, dan wordt dit een afweging tussen 'volgens het boekje' en 'logisch'. Want als ik mijn eigen (wijze?) logica toepas, dan zou ik op andere namen komen. Toch zie ik deze structuur inderdaad vaak terug.

quote:

Met google code en google groups kom je al een heel eind. Kijk anders ook naar Github.

Heb jij zelf hier ervaringen mee? Zo ja, zou je hie misschien over kunnen uitwijden? Dat word gewaardeerd!

quote:

Een open source project is echt succesvol als het ook zonder de oprichter verder kan gaan. Probeer daarnaar te streven, zelf de grote lijnen uitzetten en bewaken, maar het uitnodigend houden voor anderen om mee te doen.

Dat geld voor eigenlijk de meeste, zo niet alle ICT projecten. De beste developer is degene die zich misbaar kan maken . Die leveren namelijk werk wat door iedereen voortgezet kan worden.

quote:

Het hoeft er in eerste instantie niet gelikt uit te zien, het moet gewoon werken.

Eensch.

Overigens begin ik steeds meer naar SVN te neigen, onder andere door boven genoemde argumenten. Ik ken de tools en processen, net als veel anderen. Deze beslissing is nog niet gemaakt, maar het gaat lastig worden om een beter alternatief te vinden denk ik.
Verder ben ik dus nog wel steeds op zoek naar een beter alternatief voor TRAC en MOSS2007. Ik ga zeker kijken naar Github en Google code.

Edit:
Als test naar de "new project" pagina van Google code gegaan. Stomverbaasd lees ik het volgende:

quote:

Your project's name must consist of a lowercase letter, followed by lowercase letters, digits, and dashes, with no spaces. The project name will be part of your project's URL and cannot be changed later.

You gotta be kidding me! Hoppa, actie één met Google Code wordt dan verbosity direct maar naar de /bin dumpen. Wat een apen daar zeg... Geloof je toch niet!

Ruudjah wijzigde dit bericht 28-06-2008 17:16 (18%)

Opensource projecten hebben eigenlijk altijd een lowercase pakket-naam met dashes in plaats van spaces. Heb je weleens een tarball uitgepakt? Dat wordt altijd een directory met een lowercase naam van het project en een versienummer erachter.

quote:

Ruudjah schreef op zaterdag 28 juni 2008 @ 17:10:
Hmm, dan wordt dit een afweging tussen 'volgens het boekje' en 'logisch'. Want als ik mijn eigen (wijze?) logica toepas, dan zou ik op andere namen komen. Toch zie ik deze structuur inderdaad vaak terug.

Ik kan je uit eigen ervaring sterk aanraden NIET eigenwijs te zijn in dit geval. Conventies zijn er niet voor niets, ze helpen anderen je project sneller te doorgronden. En misschien wel even belangrijk: bepaalde tools gaan er vanuit dat de conventies gevolgd worden. Goede tools zijn natuurlijk configureerbaar, maar de vraag is of je je druk wilt maken over tools of over je project...

quote:

You gotta be kidding me! Hoppa, actie één met Google Code wordt dan verbosity direct maar naar de /bin dumpen. Wat een apen daar zeg... Geloof je toch niet!

Verbosity is een 'view' concept, de project ID een 'model' concept Het is wel jammer dat in de huidige opzet bij Google Code de ID zoveel nadruk krijgt, inderdaad.

Ja, en ik heb er nogal een grote allergie van opgebouwd. Waarom moet je een naam bedenken als cvs-fgh-1.2.4-ext-win32.tar.gz? Dat haalt bij mij het bloed onder de nagels vandaan. Alsof ze express de naam willen coderen. Net als onzinnige afkortingen in code, zoals ptr. Waarom niet gewoon Pointer? Goedemorgen! We hebben allemaal IDE's met intellisense tegenwoordig, zelfs Eclipse haalt dat soort geintjes uit. Afkortingen zijn helemaal niet meer nodig. Dat een bedrijf als Google dit zelfs eist is IMHO tot aan het belachelijke aan toe. Maar goed, ik zal ermee moeten leren leven

quote:

Ik kan je uit eigen ervaring sterk aanraden NIET eigenwijs te zijn in dit geval. Conventies zijn er niet voor niets, ze helpen anderen je project sneller te doorgronden. En misschien wel even belangrijk: bepaalde tools gaan er vanuit dat de conventies gevolgd worden. Goede tools zijn natuurlijk configureerbaar, maar de vraag is of je je druk wilt maken over tools of over je project...

Dankuwel. Dat is een sterk argument om deze conventie aan te houden. Waar kan ik een RFC indienen?

Ruudjah wijzigde dit bericht 28-06-2008 18:00 (29%)

Google heeft nu in feite het ID en de naam één ding gemaakt. Aan het ID zitten meestal technische restricties (bij SourceForge is het bijvoorbeeld heel lang zo geweest dat de naam moest voldoen aan de restricties van een Unix gebruikersnaam). De naam is vrije tekst (of zou dat moeten zijn).

M.b.t. die bestandsnamen: je wilt heel veel informatie kwijt in een naam die (ook weer vanwege technische restricities) niet te lang kan worden. Ik ken ook een aantal projecten die elke release "Project Naam.zip" geven, er daar wordt ik dan weer gek van: welke versie is het, had ik deze nou al geupdate of is dit de Linux versie terwijl ik de Windows versie moet hebben... En iets als "Concurrent Versions System - version 1.2.4 for Microsoft Windows operating systems on 32-bit x86 architectures (in GNU-ZIP-compressed Tape ARchive format)" is weliswaar verbose, maar niet echt handig in Windows Explorer

M.b.t. tot variabelenamen in code ben ik het met je eens: verbosity is goed (zolang er geen informatie gedupliceerd wordt in de variabele naam).

Herko_ter_Horst wijzigde dit bericht 28-06-2008 18:16 (12%)

Kijk ook eens naar dit boekje. Ik heb het zelf (nog) niet, maar wil hem toch binnenkort eens aanschaffen.

Er schijnt veel in te staan met precies datgene wat jij ook vraagt

Voor school projecten gebruik ik altijd:

http://www.assembla.com/

Krijg je SVN + Trac + admin tools

Het is gratis, ik weet niet of dit heel geschikt is voor een groot opensource project, maar mijn ervaring is iig positief, kijk er eens naar

Even een vraagje tussendoor: waarom ben je van plan de GPL te kiezen als licentie?

Zonder het antwoord af te wachten kan ik wel een reden verzinnen: hij wil de projectmanager zijn van het project, en anderen laten bijdragen aan het project. In dat geval is het handig dat andere mensen de source kunnen aanpassen, maar ook moeten teruggeven aan jou, zodat het project wordt voortgeholpen. Dat is waarom Linus Torvalds de GPL ook gebruikt: hij wil de wijzigingen van anderen kunnen gebruiken.

Je hebt met een game dan ook een ander doel dan OSS projecten die er vooral voor gemaakt zijn om door anderen gebruikt te worden, zoals libraries of databases. In dat geval wil je een wat minder restrictieve licentie om zoveel mogelijk developers je code te kunnen geven.

Het is ook de perfecte bescherming tegen malicious forks ten opzichte van bijvoorbeeld een BSD-licentie. Als iemand forkt, en iets interessants doet, terwijl jij gewoon nog met je project bezig bent, kan je zijn aanpassingen makkelijk weer mergen. Pas als jij zelf geen interesse meer hebt in het project zal het project doodbloeden.

De GPL is niet de enige licentie die die uitwerking heeft. Het ging mij erom erachter te komen of de TS bewust voor de GPL heeft gekozen (en niet uit een soort "default" gedrag).

Wat DOT zegt klopt helemaal, en ik kan er nog wat aan toevoegen. Omdat Kolonisten van Catan een handelsmerk is van Mayfair, kan ik de naam al niet gebruiken. Artwork is beschermd door middel van auteursrecht, dus ook dat kan ik niet gebruiken. In principe kan Mayfair de regels van het spel niet patenteren/copyrighten/*insert andere beschermingsmethode voor IP*. Toch kan ik me voorstellen dat Mayfair een probleem gaat krijgen met de software, omdat het in feite voortborduurd op Catan. Een OSS project is nu eenmaal een stuk lastiger kapot te procederen, dan bijvoorbeeld commerciele code of een bedrijf.

Daarnaast speelt ook mee dat GPL bekend is, iedereen (--> ontwikkelaars) weet ruwweg de voorwaarden.

Maar het belangrijkste argument is voor mij dat ik iets wil creeëren dat de tand des tijds doorstaat: Een GPL-ed project doet dat namelijk. Iets wat je released onder de GPL kan je over 100 jaar nog steeds tegenkomen, terwijl dit voor andere licenties een stuk lastiger is. Ik verwacht overigens dat over tijd het .NET 3.5 spec ook wel geimplementeerd gaat worden door het Mono project, dus dan is het beste tegenargument voor dit punt ook verworpen.

Edit: Assembla ziet er gelikt uit, en het lijkt er erg op alsof de developers van het systeem daar het goed begrepen hebben. WYSIWYG wiki editor (redelijk belangrijk IMHO), SVN, optioneel Trac, het zou wel eens een winnaar kunnen worden. Ik ga de genoemde alternatieven eerst bekijken.

Graag nog wat specifiekere informatie over de hosters, als jullie er ervaringen mee hebben. De volgende zaken ben ik benieuwd naar:

• Snelheid
• Beschikbaarheid
• User interface (WYSIWYG, uitontwikkeld, logisch, etc)
• Support respons
• Geschiktheid voor klein OSS project
• .NET/ C# support (als dit relevant is)

quote:

De GPL is niet de enige licentie die die uitwerking heeft. Het ging mij erom erachter te komen of de TS bewust voor de GPL heeft gekozen (en niet uit een soort "default" gedrag).

Ik heb niet een zeer bewuste keuze gemaakt voor de GPL. Het was min of meer 'default' gedrag, alhoewel ik wel een duidelijke voorkeur heb voor GPLv3 ipv GPLv2 (om persoonlijke redenen). Wèl heb ik bewust voor open-source gekozen.
De keuze voor GPL staat overigens nog niet 100% vast, omdat ik nog een aantal andere ideeën heb over de toepassing van de software. Als deze niet compatible zijn met de licentie, dan ga ik de licentiekeuze heroverwegen. Hier moet ik nog even flink de letter van de licentie induiken, alsmede de ideeën op papier uitdrukken.

Ruudjah wijzigde dit bericht 28-06-2008 19:36 (38%)

quote:

Ruudjah schreef op vrijdag 27 juni 2008 @ 19:50:
Omdat het een spel is, komen er zaken bij kijken als content en artwork. Deze kunnen nogal wat ruimte op de server in nemen.

Houd er dan rekening mee dat de repository vrij snel een paar GB groot kan worden en dat er daardoor een aantal hosted oplossingen af kunnen vallen. Als voorbeeld; de artists hier presteren het om ongeveer 1GB per week aan data te produceren tijdens een relatief (erg) klein project / team.

PrisonerOfPain wijzigde dit bericht 28-06-2008 19:43 (4%)