opzetten open source project

beste higherlevelaars, 
  

na een tijdje absentie ben ik weer terug en wilde jullie collectieve kennis even aanspreken over het volgende. 
  

in ons bedrijf ontwikkelen en maken we hardware en eigen client software. dit is op embedded linux gebeurd in c#. alles draait en alle major bugs zijn onder controle maar is zeer beperkt en we denken dat de software ontwikkeling in eigen beheer onze commerciele kansen gaat limiteren terwijl wij vooral hardware willen verkopen maar wel de controle over de client software willen behouden. kortom we denken aan het opzetten van een open source project rondom onze hardware waarin onze ontwikkelaars en die van klanten en partners samen werken aan een snellere uitbreiding van de functionaliteit van onze client software en dus de functionaliteit van het product. zondermeer kan ik ook heel open zijn dat dit voor ons betekend dat deze ideeen ook voortkomen uit de beperkte resources van een startup, want beslissen wij niet open source te gaan moeten wij de gehele software ontwikkeling zelf financieren en daarvoor hebben wij niet de middelen immers die zijn voor een groot deel in de hardware gegaan. 
  

vragen: 

- is een open source strategie voor ons de juiste? 

- wie is eigenaar van de ip van het open source project? 

- wat moeten we doen om een dergelijk project op te zetten? 

- wat moeten we beschikbaar stellen? (broncode, tools en omtwikkelomgeving, hardware, etc) 
  

alvast bedankt voor jullie input. 
  

groet, 
  

ron 

ik denk dat ik wel een beetje input kan geven als eigenaar van een bedrijf wat draait op een open source product. even een beetje bias wegnemen: is open source voor mij een heilige graal? nee zeker niet! open source is voor mij zeker geen doel, maar gewoon een middel om je doel te bereiken. dat is ook meteen het belangrijkste advies wat ik je kan geven (maar dit is een beetje abstract natuurlijk). kijk of het bijdraagt aan het behalen van je doelstellinge. 
  

 

  

goed, dan iets concreter een aantal puntjes. 
  

- ga er niet vanuit dat het feit dat je iets open source maakt, je er geen tijd meer aan hoeft te besteden. open source ontwikkeling vereist ook energie en tijd. contributors komen niet zo maar aanwaaien. van de mensen die aan linux werken, wordt het meerendeel ook gewoon door een bedrijf betaald om dat te doen. in die zin moet open source geen uitweg zijn omdat je een gebrek aan resources hebt. het idee om partners en klanten er aan mee te laten werken, klinkt interessant. ik zou zeggen, werk samen met hun een strategie uit en betrek hun in je plannen. des te meer feeling zullen ze krijgen met de plannen en misschien gaan ze ook wel mee-investeren (resources committen that is). 
  

vragen: 

 

moeilijk te zeggen. nogmaals, ga niet je product open source maken omdat je gebrek aan resoruces hebt. open source lost hier niet van op! 
  

 

dat bepaal je zelf en is afhankelijk van wat je wil. je kunt bijvoorbeeld een stichting opzetten en hierin de code onderbrengen. alle committers moeten dan wel zorgen dat ze iets ondertekenen waarbij ze het ip overdragen of sharen. het is ook afhankelijk van de licentie die je kiest. grofweg zijn er twee soorten, de bsd-style licenties en de gpl licenties. de eerste zijn vriendelijk voor bedrijven, garanderen niets met betrekking tot de eigendoms rechten en iedereen kan het kopieren en ook weer closed source maken. bij gpl ligt dat anders en vaak vinden juridische afdelingen gpl software ook niet zo fijn (ligt wel weer een beetje aan wat voor pakket het is). lgpl zit er een beetje tussenin, maar ook dit wordt niet altijd door juridische afdelingen goedgekeurd. gpl en lgpl garanderen wel beter dat hetgeen open source is, ook open source blijft. wijzelf hebben gekozen voor een bsd licentie (asl in dit geval), omdat we vriendelijk willen zijn naar onze klanten en die hebben een hekel aan een andersoortige licentie. 
  

 

dat hangt af van wat je wil doen. voor wat betreft de code: ga naar sourceforge, maak een project aan en gaan met die banaan. boven elk bronbestand een copyright notice zetten, je spullen in het versie beheer systeem zetten, releases en klaar. website bouwen waarop je het promote misschien. als je de code onder wil brengen in een stichting moet je natuurlijk ook dat en een aantal andere juridische zaken regelen. 
  

 

broncode, that's it. tools hangt er een beetje vanaf. in principe hoef je niets. 
  



dank voor je reactie aleph, 
  
  

dank voor je antwoord. btw. heb ik jou niet gesproken op et moma event in amsterdam deze lente? 
  

het is zeker niet de bedoeling te denken dat we eraf zijn, wij zullen hier meer resources voor vrij moeten maken maar dit moeten financieren van hardware verkoop. het moet een middel zijn om onze hardware verkoop te versterken. dit is de belangrijkste reden. 
  

initiele gedachte was integratie trajecten te doen voor klanten en daarvoor een fee te vragen maar dit blijkt niet de goede strategie, een locale software partij is altijd betrokken bij de implementatie en daarmee willen wij niet concureren, sterker wij moeten deze enablen. wij verkopen wereldwijd. verder willen we met de ontwikkelingen die klanten/partners doen sneller de functionaliteit uitbreiden, omdat ik denk dat er paralel gewerkt gaat worden aan diverse funcionaliteiten extra aan de huidige client software omdat klanten op verschillende wijze onze producten inzetten. snelheid is een tweede reden. 
  

de participanten in het open source project werken voor de systeem integrators die in opdracht van de klanten een mobile ticketing of een mobile loyalty oplossing moeten realiseren. inspanningen worden betaald door klant en dragen bij aan onze client software. wij verdienen onze centjes door de marge op de hardware. ik ga zeker de mogelijke deelnemers in het project benaderen om input te geven op een mogelijk open source project. 
  

ook intern moet ik hiervoor akkoord krijgen en daarvoor zijn je overige antwoorden heel belangrijk. ik ga beide licentie vormen bestuderen, uiteindelijk is het zo dat onze client software alleen te gebruiken is met onze hardware dus zou een bsd wel passen maar er zijn strategische redenen om met de lgpl of gpl aan de gang te gaan. 
  

als ik het zo lees hebben eigenlijk alles klaar liggen om te beginnen incluis een sdk en compiler (embedded linux apparaat draait op een arm processor). binnen 2 weken hebben we ook een eigen server met daarop een demo server programma en de mogelijkheid de tools aan te bieden. 
  

groet, 
  

ron 



moma event, nee, dat ken ik niet... 
  

 

geen rare strategie. het open source maken van een stuk software kan een belangrijke marketing lever zijn. dit hebben wij ook meegemaakt. ons product is groot geworden doordat het open source was. realiseer je overigens wel dat je die marketing heel lang kan blijven gebruiken als je slim bent (zorg ervoor dat mensen het uitproberen omdat het gratis is, speel in op de grijpgrage early adoptor community). maar: je kunt nadat je het open source gemaakt hebt moeilijk weer terug. dit betekent dat je goed moet nadenken of je dit echt idd wel. terug naar closed source gaat de community of je gebruikersgroep je niet in dank afnemen (tenminste, dat is bij ons heel sterk zo). 
  

 

grappig, deel van onze organisatie dacht er ook zo over. ook wij zijn deze kant uitgegaan: product-georienteerd werken en de integratie aan andere partijen overlaten. wat je kan doen (als het interessant is) is met die integrators partneren. certificatie is een interessant propositie (een certified xyz integrator heeft altijd een streepje voor tov een niet certified xyz provider, waarbij xyz jouw product is). 
  

 

zeker doen. of je er nou wat mee doet of niet, het creeert in ieder geval goodwill! 
  

 

als de er naast jullie software niet veel andere software op de hardware komt te draaien (die met jullie software integreert), zit je met gpl of lgpl goed. als jullie software erg verweven is met extras die er bij ontwikkeld worden, dan is gpl sowieso een beetje uit den boze en over lgpl bestaan nog steeds veel twijfels. 
  

 

klinkt goed! mocht je nog hulp nodig hebben, laat maar weten. enneuh, hou ons op de hoogte van je ontwikkelingen. is altijd interessant! 
  



het was het mobile monday event, heb iemand gesproken van jteam. zal eens even in de berg kaartjes graven die ik heb. 

dank voor je antwoord, kom later terug op je antwoord. 
  

groet, ron 



aleph, 
  

ik ben even de kaartjes doorgegaan en het klopt ik ben leonard van jteam tegen het lijf gelopen op momo. 
  

we zijn de gpl licentie aan het bestuderen maar vragen ons af of dat niet teveel de ontwikkel community gaat afschrikken hieraan mee te werken (zoals jij al eerder aangeeft). we zoeken eigenlijk een tussenvorm waarin er wel kennisuitwisseling is, als men broncode wil uitwisselen de mogelijkheid er is maar men de kroonjuwelen voor zichzelf mag houden. ons beoogde open source project richt zich op thin client software draaiend op ons apparaat en zover mijn kennis gaat zullen de de kroonjuwelen meer liggen in het back office ontwerp dan op het thin client niveau. 
  

een bsd licentie en een open source community met een forumfunctie om oplossingen te delen (zonder alles te geven) lijkt ons het commerciele en technische doel ondersteunen. 
  

terug willen we niet, zonder de thin client software is het een domme doos met veel potentie, het open source project moet de drempel verlagen en gebruik makend van kennis die zich paralel ontwikkeld bij systeem integrators in verschillende markten sneller functioneel tot wasdom komen. 
  

dat die strategie nu zo zich ontwikkeld is logisch, we proberen de markt deel te laten zijn van de strategie vorming en de locale system integrators zijn een belangrijk schakel naar werkende installaties. dat idee om ze te certificeren spreekt ons erg aan. 
  

inmiddels zijn de eerste reacties binnen en die zijn allemaal positief, ik heb ze nu diverse vragen voorgelegd waar onder andere de licentievorm word voorgelegd. keep you posted. 
  

groet, 
  

ron 



ik heb voor een embedded linux project bij http://www.passievoortechniek.nl/ info aangevraagd. 

kreeg gistermiddag een (gratis) cd met opensource en prima uitleg. 
  

succes.. 
  
  



heren, 
  

de interne discussies gaan ook verder. dat we iets met open source gaan doen is duidelijk, klanten zijn enthousiast en intern zien we het ook geen obstakels en zien we ook geen redenen dit ooit terug te willen draaien. 
  

een van onze software mannen heeft slechte ervaringen met bsd livcenties en wees daarop op partijen die open source software van het net pakken, daar iets intellislimmerigs mee doen en het vervolgens met veel poehah verkopen als een innovatief stuk software. gpl zorgt in zijn ogen dat open source open source blijft. wat vinden jullie? 
  

groet, ron 



hey, 
  

de meningen verschillen altijd enorm over bsd versus lgpl. 
  

er zijn een aantal aspecten die je mee moet nemen en dan praat ik alleen maar over bsd klonen en lgpl (niet over gpl dus, want dan ben je nog jaren bezig met discussieren :) ). 
  

lgpl wordt vaak als problematisch gezien (door juridische partijen) omdat het als licentie an sich op meerdere manier uit te leggen valt en er (misschien wel alleen in nl hoor, dat weet ik niet) weinig rechtspraak over is wat als precedence (nederlands woord??) kan dienen. als de software geisoleerd draait en niet naast andere (door klanten te installeren) software pakketten draait, dan zou ik zeker niet terugdeinzen voor lgpl. dan heb je nl. weinig te vrezen van partijen die een dergelijke licentie niet aanstaat. moet jouw software ge-integreerd worden met andere software (als onderdeeltje bedoel ik dus, van een groter geheel), dan wordt het een ander verhaal en zou ik zelfs eerder voor bsd gaan. concreet heeft deze keuze ons een significant aantal fortune500 gebruikers en klanten meer opgeleverd dan als we voor de lgpl licentie hadden gekozen. 
  

daarnaast bestaat bij een bsd licentie inderdaad de kans dat men de software pakt, aanpast en het onder een andere licentie weer publiceert. dit mag bij een dergelijke licentie gewoon (forken heet het). dit zorgt echter voor een veiliger situatie voor een uiteindelijke klant. dit zou wat mij betreft alleen gelden als je software dus een onderdeel is (een boutje, of moertje bijvoorbeeld) van een groter geheel. 
  

de discussie kan denk ik lastig afgerond worden zonder overzicht over het hele plaatje overigens... 
  

overigens: leonard inderdaad, dat kan. dat is de directeur van jteam, het bedrijf wat ik oorspronkelijk heb opgericht. 



aleph, 
  

dank voor je heldere betoog. mijn zakenpartner is jurist en spit momenteel door de documenten behorende bij de gpl, lgpl en bsd licenties. onze software developer is een open source man in hart en nieren. strategisch lijkt de ex-jurist de gpl licentie het beste maar ik denk dat we daarmee system integrators afschrikken en dwingen of helemaal vanaf scratch te beginnen of naar de concurent te lopen. omdat onze software uiteindelijk alleen op ons appraat draait begin ik langzaam te denken dat de bsd licentie wel past, samen met een discussie board voor info inwisseling en met "certified system integrators" status aan die partijen die broncode terug geven aan de open source community en die concreet ook hardware aanschaffen. 
  

gedachte daarachter is dat ze met de "certified status" regionaal een streepje voor hebben als uiteindelijk klanten ons benaderen voor hardware en wij ze in contact kunnen brengen met de lokale "certified system ingrator". 
  

de discussie over "certified system integrators" noopt ons ook om goed na te denken over het value chain van onze oplossingen. naast "certified system integrators" komen er bij grotere volumes ook "installatie- en onderhoudspartijen" in beeld die bij calamiteiten het apparaat gaan services of swappen. verder hebben we partners die gespecialiseerd zijn in het genereren en distribueren van barcodes naar de telefoon (per sms/mms/wap push/etc). kans is groot dat deze partners ook "certified system integrators" gaan worden. hier ligt ook meteen het meest gevoelige punt, immers bij de partners van ons (wij hebben 2 hardware concurrenten dus keuze is beperkt) zitten lokale concurrenten en deze zullen nooit alles prijs willen geven hoewel bij deze partijen de kroonjuwelen vooral liggen bij hun back-end en wij maar een domme terminal (maar onmisbare schakel ;) ) fabriceren. voor hen is de keuze al- of niet certified te worden, een trategische voor hen. 
  

goed deze ideeen gaan we eens op papier zetten en intern bespreken voor we dit cristaliseren tot strategie. shieten maar als je nog meer gaten / problemen ziet. 
  

ik heb inmiddels ook even leonard gesproken. gewoon nieuwsgierig, ook hij had wel wat te vertellen over open source.