Opzetten OSS project

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 99% gewijzigd door Ruudjah op 02-12-2009 00:06 ]

[leuk_he]

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)

[AtleX]

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.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 98% gewijzigd door Ruudjah op 02-12-2009 00:06 ]

[AtleX]

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.

[ Voor 14% gewijzigd door AtleX op 27-06-2008 19:59 ]

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 108% gewijzigd door Ruudjah op 02-12-2009 00:06 ]

[AtleX]

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.

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.

[ Voor 4% gewijzigd door AtleX op 27-06-2008 20:27 ]

[XiN-eViL]

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).

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 100% gewijzigd door Ruudjah op 02-12-2009 00:06 ]

[MisterBlue]

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.

[curry684]

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.

[Coju]

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)

[djc]

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).

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 116% gewijzigd door Ruudjah op 02-12-2009 00:06 ]

[Verwijderd]

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.

[Herko_ter_Horst]

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...

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.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 127% gewijzigd door Ruudjah op 02-12-2009 00:06 ]

[Herko_ter_Horst]

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).

[ Voor 12% gewijzigd door Herko_ter_Horst op 28-06-2008 18:16 ]

[mithras]

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

[KnEuTeR]

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

[Herko_ter_Horst]

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

[Verwijderd]

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.

[Herko_ter_Horst]

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).

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 137% gewijzigd door Ruudjah op 02-12-2009 00:07 ]

[PrisonerOfPain]

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.

[ Voor 4% gewijzigd door PrisonerOfPain op 28-06-2008 19:43 ]

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 96% gewijzigd door Ruudjah op 02-12-2009 00:07 ]

[Jogai]

sf.net is natuurlijk wel veel bekender, maar je kan misschien daar een soort mirror draaien die doorverwijst naar je echte site. Heb je direct een extra mirror voor je releases.