De open source-beweging heeft ons de laatste jaren een aantal interessante verschijnselen gebracht binnen de softwareontwikkeling, waarvan naast transparantie, de actieve participatie van een community een van de belangrijkste is.
Waar open source zich onderscheidt van propietary software is het vrij beschikbaar hebben van de broncode. Dit impliceert een zekere mate van transparantie die veelal ontbreekt bij propietary software. Deze transparantie is een van de factoren die bij open source een community aantrekt. Allemaal gesneden koek voor een ieder die zich met open source bezighoudt.
Het aardige is nu dat er de laatste tijd hybride vormen van softwaredevelopment in de markt opduiken. Er ontstaan initiatieven waarbij veel energie wordt gestoken in de facilitering van een community, leden kunnen discussiëren met ontwikkelaars en hebben inspraak in prioriteiten, bovendien is vaak de prijsstelling bijzonder acceptabel. Het enige echte onderscheid tussen deze hybride vorm en open source is dat de broncode niet vrij beschikbaar is. En ondanks dat zie je dat de community net zo goed werkt als bij echte open source. Handleidingen ontstaan binnen de community, er vinden hele zinnige discussies plaats over nieuwe features en er worden uigebreide beta-trajecten doorlopen. Een vraag die bij mij dan ook opkomt is de volgende: hoe belangrijk is het voor het succes van open source dat de broncode vrij beschikbaar is? Wie antwoordt?
Reacties
Deze vraag is een aantal jaren geleden gesteld en uitvoerig beantwoord in "The Cathedral and the Bazaar".
Kun je enkele succesvolle organisaties noemen die het hybride model aangangen dat je beschrijft?
Een voorbeeld van dit hybride model is Xara LX dat een deel van de bronkode niet vrij gaf. Het projekt loopt nu nog op een laag pitje.
Dat is eigenlijk jammer omdat het een uitstekend programma is ook in deze vorm. Zelf heb ik een licentie op windows voor de pro versie en kombineer met LX op Linux.
Probleem was dat de ontwikkelaars dit niet accepteerden op een paar na, wat ook weer begrijpelijk is.
Wat een rare vraagstelling: "hoe belangrijk is het voor het succes van open source dat de broncode vrij beschikbaar is?".
Het vrij beschikbaar zijn van de broncode is juist een uitgangspunt van Open Source. Laten we niet gaan zagen aan deze stoelpoot, a.u.b.
Volgens mij moet je hier eerst twee vragen beantwoorden. Wat is succes? en Wat schaar je onder het open source model?
Microsoft heeft ten aanzien van het laatste een eigen antwoord geformuleerd. Citaatje:
[quote]No. The term open source software (OSS) is broadly applied to any (or a combination) of four interrelated concepts: the OSS development model, OSS philosophies, OSS licensing regimes, and OSS business models. However, first and foremost, OSS is a development model built around the idea of community creation and sharing of source code. The other three concepts, and the debates surrounding them, lend further definition to the OSS movement or "culture." [/quote]
De vraag die je hier stelt past wel bij het idee van Microsoft dat het vooral om de community gaat en minder om de open broncode.
Maar ja, raak je dan niet verzeild in een semantische discussie, terwijl de open source gemeenschap zelf deze insteek niet ondersteund? Succes voor de open source gemeenschap is simpelweg al dat de broncode vrijelijk beschikbaar en dat gebruikers vrijheden krijgen om zelf aan de slag te gaan (en niet beperkt blijven tot het neerleggen van wensenlijstjes, hoe goed dat ook georganiseerd is en hoe goed er ook wordt geluisterd).
Hoe het ook zij, natuurlijk heb je succesvolle gesloten software waarbij goed wordt geluisterd naar de gebruikers die verenigd worden in een community (maar zou dat niet moeten gelden voor alle software ;) ) en heb je mislukte open source projecten omdat de ontwikkelaars er niet in slagen een community op te zetten en in stand te houden.
Reaper van Cockos is een voorbeeld (audio opname software), maar er zijn er velen te vinden. Eens dat het vrij beschikbare zijn van broncode onderdeel is van Open Source, maar we moeten niet Open Source zich tot een dogma laten vormen waarbij we niet meer kijken naar de effectiviteit van de beginselen. Strikt genomen is het niet beschikbaar zijn van de broncode dan ook geen Open Source meer, maar is het een slecht idee als je wel je best doen om andere onderdelen van de gedachten achter Open Source te adopteren?
De eerste vraag is "Leidt een open broncode tot succes?", het antwoord hierop is uiteraard: Nee.
Kijk bijvoorbeeld even op sourceforge.net hoeveel initiatieven er zijn zonder volgers, deelnemers en zonder gebruikers. Dus open broncode leidt niet automatisch tot een succes.
Dan de tweede vraag "Hoe belangrijk is het voor het succes van open source dat de broncode vrij beschikbaar is?". Hierboven geeft Jeroen aan dat hij eigenlijk de vraag wil stellen wat een organisatie kan leren van succesvolle Open Source initiatieven. Open broncode lijkt mij daarvoor geen voorwaarde; het gaat meer om het kunnen binden van een groep mensen. Een veel toegepast model buiten de Open Source wereld is die van Gebruikersverenigingen. Er zijn heel wat software pakketten die zo'n vereniging hebben. De ene is succesvoller dan de andere. In zekere zin is een Open Source community ook gewoon een gebruikersvereniging. Of je nu eens per jaar samenkomt in een vergaderruimte of dagelijks op internet, het model is hetzelfde maar het tempo een stuk lager.
In beide situaties is m.i. de doorvoering van jouw persoonlijke idee?n en wensen in de software de belangrijkste factor om een succesvolle participatie te beleven.
De belangrijkste les is dus (en deze kennen we al heel lang): Luister naar je gebruikers.
Xara LX is een goed voorbeeld waarom "hybride" fout kan gaan:
"Lessons learned from open source Xara's failure"
http://www.linux.com/feature/119790
"Xara LX forked to replace rendering engine". http://www.linux.com/feature/60491
Uit alles blijkt dat de open source versie Xara LX niet past binnen het business model van de organisatie (verkopen van de closed source versie voor Windows).
Reaper van Cockos is geheel closed source op enkele open souce componenten na die in Reaper gebruik worden. Ik kan niet bijdragen aan de code of de code inzien. Het businessmodel van Cockos is geld verdienen aan betaalde softwarelicenties voor proprietary software. Dit staat in de overeenkomst:
REAPER Software Distribution Agreement
Licensee shall not, and shall not permit any distributor or other person to, re-configure, modify, translate, decompile, reverse engineer, disassemble, or otherwise determine or attempt to determine source code from the Product or to create any derivative works based upon the Products.
http://www.reaper.fm/dist-agreement.php
Veel proprietary software editors gebruiken OSS in de software die ze verkopen. Het business model is verdienen aan licenties op de (proprietary) software.
De meeste (alle?) propiertary enterprise softwareleveranciers hebben "communities" die een bijdrage leveren aan een of meerder van de community-activiteiten die Jeroen noemt. Dit worden gebruikersgroepen (GG) genoemd. SAP, Oracle hebben dergelijke "communities".
Web2.0 maakt het voor organisaties eenvoudiger om gebruikers bij het product en de processen te betrekken. Forums, wiki's, blogs, video's, etc., zijn allemaal middelen om de betrokkenheid te vergroten. Hier wordt steeds beter gebruik van gemaakt.
SAP, Reaper, TomTom, Xara hebben allemaal actieve gebruikersgroepen en zijn allemaal proprietary en verdienen hun geld met softwarelicenties. Betalen voor softwarelicenties en open source gaan per definitie niet samen.
Open source zonder actieve community is ten dode opgeschreven (zie Xara LX). Andersom: Een belangrijke indicator van een succesvol open source project is de omvang, bijdragen en activiteit van de community.
Een actieve gebruikersgroep van een (gedeeltelijk) closed source product heeft niets met open source te maken, maar is gewoon een actieve (online) gebruikersgroep. Een actieve gebruikersgroep is een zegen voor iedere software editor.
Open_broncode geeft je als software ontwikkelaar de mogelijkheid om op 1 lijn met het gedachtengoed van de maker te gaan zitten. Hierdoor kun je een beter inzicht vewerven hoe iets gemaakt is en hoe het werkt "under the hood".
Open_broncode maakt ook volledige samenwerking mogelijk, omdat je elkaar volledig inzicht bied hoe iemand anders een uitdaging heeft opgelost. Daar kunnen anderen van leren, waardoor de communities ook groeien en levendig blijven.
Open_broncode geeft - mij persoonlijk - ook een stuk vertrouwen. Compleet inzicht hebben in de werking van de software op mijn systeem.
Open_broncode geeft mij ook de mogelijkheid om het e.a.a aan te passen en te herprogrammeren naar eigen inzicht en behoeften. Hierdoor ben ik niet gebonden aan een (closed source) leverancier en dat biedt vrijheid.
Om je vraag te beantwoorden Jeroen;
Open_broncode hoeft niet automatisch tot een succes te leiden. Het ontwikkelen van software is en blijft immers mensen-werk en waar mensen werken, worden fouten gemaakt.
In mijn ogen geeft open_broncode wel meer mogelijkheden tot samenwerking binnen een softwareontwikkel team.
Het schept ook de mogelijkheid waardoor mensen ook onderling van elkaar kunnen leren en elkaar kunnen inspireren door het beste van codings_skills met elkaar te delen.
Volgens mij levert deze open minded "true hacking spirit" in een software development team een veel beter eindresultaat op dan een team met mensen die er "alleen voor het geld" deelnemen aan een project
"Program with passion ..."
http://www.stevenlevy.com/index.php/other-books/hackers
Het bestaan van closed source in open source roept meer weerstand op die het eigenlijk zou moeten hebben. Regelmatig zie je dat er closed source software (flash) in open source paketten voorkomen (Ubuntu) en dat werkt prima. Alleen is er in dit specifieke geval altijd een open alternatief. En zo zou het ook moeten zijn met closed source in open source. Er moet worden voorkomen dat er crippleware ontstaat die zonder de gesloten code waardeloos is.