
Open Source Days: Sunde og usunde open source projekter
Der er mange ting jeg ser frem til på Open Source Days 2010 i næste weekend. Et at de foredrag jeg glæder mig meget til er Jonas Gamalielsson "Assessing the Health of Open Source Communities. Jonas sætter fokus på et at de områder jeg selv gerne ville have lavet kvantitativ og empirisk forskning på "hvordan har projekt XYZ det?".
Vi kender alle projekter, som er døde lige efter fødslen - man nåede version 0.1, og så røg gassen af ballonen. Modsat så findes der mange projekter indenfor open source som er glimrende - men der sker intet ved dem. Alle variationer findes fra håbløse projekter til spændende projekter med fuld tryk på. På Open Source Days 2010 konferencen sætter vi fokus på mange af de populære - eller kommende populære projekter.
Jeg glæder mig til at udfordre Jonas, alene fordi jeg synes det er vigtigt at få bragt mere viden frem om valget af open source løsninger. Der er ofte flere mulige løsninger på et givet problem, men der er helt sikkert forskel på hvor mange penge de enkelte løsninger vil koste en IT-afdeling. Oftest ser jeg valgene af open source løsning lavet af individer ud fra tidligere erfaringer, men sidder man som IT-chef må det være rart at have en systematisk måde at screene for
- Udviklingsstade
- Udviklingsmiljøet bag programmet - herunder kontakten til udviklerne.
- Populariteten
- Bredden i projektet
- Supportmuligheder
Mange af jer læsere sidder og laver de teknologivalg, som påvirker jeres firma de næste par år. Hvordan vælger I' Hvilket processer følger I'
Håber vi ses til OSD
/pto
Peter Toft er senior specialist hos Renesas Mobile og har blogget om open source og Linux siden Version2's begyndelse. Blogger også jævnligt om andre sjove teknologi-områder.
Follow @petertoftKommentarer (1)
Hej Peter
Jeg glæder mig også, endda med en stand og måske skifter mit firma navn - hvem ved :-)
Nå, men når jeg skal vælge software foretrækker jeg open source, idet man således altid har muligheden for selv at ændre, udvide og tilpasse - eller i det mindste kan man betale andre for at gøre det. Man er således ikke låst.
Hvis det ender med lukket software skal jeg have en udvej, en eksportmulighed for data eller lignende. Faktisk gælder det for både Open Source og lukket software at eksportmuligheder og en "exit strategi" helst skal være tænkt ind før man vælger endeligt.
Derefter ser jeg selv på sundheden af "produktet", har det eksisteret flere år tæller det plus, er der flere versioner, med en regelmæssig release - helst kortere release cycle end Debian :-)
Findes der et community omkring produktet tæller det plus.
Et vigtigt punkt efterhånden er også om det er en gruppe som styrer produktet eller en enkeltperson - enkeltpersoner som "benevolent diktator" kan være fint, men enkeltpersoner løber nemmere tør for ressourcer. Et eksempel for tiden er Nagios - hvor der præcis er den slags bøvl.
Faktisk kommer først efter ovenstående nødvendige kriterier andre ting som, bruger det et sprog jeg kan acceptere (PHP no, C OK, Java/Groovy - jaaaaaa)
og selvfølgelig om produktet tilbyder den funktionalitet som jeg skal bruge - eller kommer til det.
Grundet ovenstående trækker jeg ofte over mod Apache.org hvor ting som Apache HTTPD, Apache Tomcat, Ant, Maven, Lenya m.v. har tjent mig tro i mange år. Lenya er undervejs til at blive skfitet ud med Liferay CMS som ligeledes er Open Source.
Undervejs har jeg dog også været omkring teknologier som Docbook, som jeg pt. forsøger at fjerne igen - men er for doven til at omskrive alle rappportskabelonerne tilbage til LaTeX ;-)
- en af grundene var at tool-chain til Docbook behandling stinker, men med fundet af dblatex til at smide docbook gennem LaTeX nemmere virker det faktisk.
Et punkt som support har aldrig været et kriterie for mig, jeg vælger gerne noget som ingen andre i DK kender :-)
En ting der slår mig - som jeg vil bruge fremover er noget nyt. Hvis jeg i fremtiden støder på en udvikler som vil lave alt fra grunden, så vil jeg løbe skrigende bort, ligesom en udvikler der med Hybris tror at vedkommende nemt kan skrive enten et CMS, en postserver eller lignende :-) Jeg vil således i fremtiden foretrække udviklere der forstår at vælge frameworks og grundbyggesten fremfor at lave dem fra grunden selv - dem der har forsøgt at lave en version 2 fordi version 1 blev for rodet ved hvad jeg taler om ;-) - man laver typisk enten andre fejl eller de samme igen.
