Jesper Lund Stocholm bloghoved

Hvor Open-"saucy" er du?

Vi har hos Projectum bygget vores forretning på at levere løsninger på en closed-source stack - nemlig Microsofts Office 365 stack.

I "gamle" dage var Microsofts stack stort set udelukkende closed course. Microsoft leverede DLL'er til os i deres værktøjer, og partnere i økosystemet omkring stack'en var også closed source og leverede buy-ware closed-source components til kunder (som os).

Heldigvis kiggede Microsoft over på fx Google og indså, at deres forretningsmodel (en closed-source cash-cow stack med open-source software omkring den) nok også kunne bruges af Microsoft.

Som resultat af dette har Microsoft i dag en closed source stack (Windows, Office[365], Azure etc) med et sprudlende økosystem omkring den af både Microsofts egen open source komponenter samt gode virksomheder rundt omkring i verden, der laver open source ovenpå stacken.

Hos Projectum er vi jo en "traditionel" (PPM) konsulentvirksomhed, der tjener vores penge på at sælge timer i form af konsulentarbejde. Men som ligesom mange andre virksomheder (fx banker, der brander sig om IT-virksomheder, der tilfældigvis arbejder med penge), så kan vi se, at vores softwaredel af forretningen bliver større og større. Dette skyldes både en stigende modenhed i Microsofts software stack - men også at vores kunder bliver mere og mere "kræsne" og forventer mere og mere af de services de køber - i form af specifik tilpasning til netop deres processer.

Vores organisation har igennem længere tid summet af samtaler om, hvilken strategi vi skal følge fremadrettet for at bygge bro imellem de to verdener.

  • Skal vi leve af vores software og så håbe, at det også kaster konsulenttimer af sig?
  • Skal vi leve af konsulenttimer og se på indtægter fra vores software som mere et "julefrokosttilskud og torsdagskagekasse"?
  • Skal vi satse på softwareudvikling i tro på, at det er vores gode software, der giver os mulighed for at sælge konsulenttimer?

Sandt at sige er det jo et svært spørgsmål.

Så vi er begyndt at eksperimentere en smule med en model a'la Microsoft og Google - nemlig en proprietær softwarestack med open source strøet ovenpå. At Microsofts Office 365 stack er closed source kan vi jo ikke gøre noget ved - og vi har også nogle softwarekomponenter, som vi ikke for nuværende ønsker at lægge ud som open source. Men vi har jo en skøn skov af andre softwarekomponenter, som vi sagtens kunne lægge ud som open source.

Indtil videre har vi valgt at lægge udviklingen af nogle udvidelser til Visual Studio Team Services (deres CI-funktionalitet) ud som open source projekter. Det er ikke dumps af vores kildekode - udviklingen sker også i det fri.

Motivationen er naturligvis, at andre udviklere og (potetielle) kunder i vores branche vil lære os at kende og at vi kan få skabt et mindset omkring, at vi er dem man skal gå til, hvis man ønsker gode, robuste og innovative løsninger baseret på Microsoft Project.

Mig bekendt er der ikke andre i vores branche/niche, der eksperimenterer med denne måde - heller ikke globalt set. Jeg skal ikke kunne sige "hvorfor?", men en årsag kunne være noget kultur i vores branche (Der er mange ... øhem ... "detaljeorienterede controllere" i vores branche) kombineret med noget legacy-closed-source-mindset fra tidligere tider.

Men det har fået mig til at tænke på: alle I gode folk, der har baseret jeres forretning på open source - hvad gør I?

Der er jo mange virksomheder, der er nøjagtig ligesom vores - bortset fra, at deres stack ikke er SharePoint men Joomla, Drupal eller lignende.

Hvad gør I med den funktionalitet I selv laver ovenpå jeres stack? Lægger I disse ting ud som open source eller holder I dem - uanset at jeres stack er open source - tæt på kroppen og deler dem kun med kunder, der vil betale ved "Kasse 1"? Og hvis I lægger dem ud som open source - hvad skyldes dette så? Er det en "bonus-pater"-betragtning i form at at "give noget tilbage", eller gør I det i en forventning om, at det giver mere forretning for jer?

Kommentarer (4)
Peter Christiansen

Det giver god mening at dele ud af sin viden og opensource en god del af sin programmerings forretning, specielt hvis man har lavet et modul / pakke / klasse som løser et specifikt problem som andre også kan være interesserede I.

Hvis der er andre interesserede får man feedback og evt. pull requests, hvis man ligger det på github, så andre folk er med til at videreudvikle eens løsning til det bedre.

Jeg ved ikke om Microsoft huse er meget til at opensource deres kode, men i linux verdenen er det ligefor og man får som regel noget igen i form af fejlrettelser, feature requests ja og så bliver man kendt ude i verdenen.

Jeg ser ikke noget problem for Microsoft huse at opensource, men hvis det er alt for klient specifikt, er der nok ikke nogen ide i at gøre det, det er bedst hvis modulet som sagt tidligere løser et problem andre også har.

Erfaringen siger mig at man i hvert fald ikke mister noget ved at opensource, eens hemmeligheder og super awesome kode, man kan tro at man mister noget ved at sende sin kode ud til offentligheden, men det fungerer snarer modsat. Folk ser dit firmas kode og tænker "dem skal vi bruge, de kan deres kram".
Det er sjældent at folk tænker "det kan jeg stjæle og lave kassen på" det virker sjældent sådan, da personer der vil "stjæle" det ikke har skills til at opdatere og vedligeholde det og integrere det som I har.

De fleste der bruger jeres kode, er selv med på at sende rettelser og tilføjelser tilbage og det gør at arbejdsbyrden bliver delt og alle får glæde af udviklingen.

Thomas Rosenbusk

Der er oceaner af software der i dag er licenseret under GPL, så at OpenSource det kode man selv laver, gør det muligt at få dækket en kæmpe del af de generelle behov til en given løsning.

Så bygger du en løsning på Asterix eller Office365 er det reelt en kæmpe fordel hvis den underliggende software er Open Source, uanset om din egen kode er det.

Personligt tror jeg at Closed Source dagene er ved at være omme. I praksis er det nærmest umuligt at lave løsninger uden at noget af det bliver åbnet, medmindre man synes det er fantastisk at opfinde hjulet hver gang man leverer noget, ligesom at kunderne synes det er fedt at have en løsning hvor man kan gå til et andet udviklerhus i tilfælde af konkurs eller samarbejdsvanskeligheder, etc.
- Det udelukker selvfølgelig vendor-lock-in, men hey, det er vi jo alle imod, ikke? :)

Jacob Bunk Nielsen

Markedet for software er i forandring. Det bliver sværere og sværere at leve af alene at sælge softwarelicenser.

Jeg arbejder selv for en virksomhed, hvor vi er ved at sadle om fra at sælge softwarelicenser til at sælge forretningsværdi leveret ved hjælp af vores software. Enten baseret på vores kommercielle software eller nogle af vores open source projekter. Vi har med andre ord valgt en forretningsmodel der minder om den I nu også er på vej mod hos Projectum.

Jens Kjellerup

Godt I er kommet så langt, at i overvejer om jeres forretningsmodel er tjent med en closed source tilgang.

Set fra kundevinklen er leverandørens tilgang til kode og løsningsejerskab blevet en parameter der har vægt ved anskaffelser.

Vi har den tilgang at vi som betalende kunde ønsker at have ejerskab til løsningen - enten i form af at løsningen er open source eller at vi ejer ip-rettighederne til det udviklede.

I praksis betyder det at leverandører der alene arbejder med closed source stiller sig selv dårligt, når vi som kunde skal vælge mellem flere leverandører.

Et resultat af denne tilgang for (offentlige) kunder er OS2 fællesskabet. I OS2 samarbejder 60 kommuner og 40 leverandører om at udvikle løsninger hvor al kode er open source - se www.os2.eu.

Kode der udvikles, finansieres af kommunerne og ip-rettighederne ejes af OS2 fællesskabet. Koden frigives under en MPLv2 licens der giver leverandørerne (og andre) mulighed for at bygge kommercielle løsninger på baggrund af OS2 kode evt. kombineret med deres egen kode.

Den stigende modenhed hos kunderne fordrer en stigende vilje til at tage ansvar for ejerskabet, for arkitekturen og for udviklingsprocesser.
Leverandører der forstår at agere i dette marked har en fordel.

Log ind eller Opret konto for at kommentere