Står fortiden i vejen for fremtiden?

Til tider kan man opleve, at fortidens succeser står i vejen for fremtidens. At man har produkter, komponenter og løsninger, der er "gode nok" til at man ikke straks slår dem ihjel og fordeler de ressourcer, der går til at sælge og vedligeholde disse til at skabe noget nyt, som er det, der skal bære en igennem fremtidens udfordringer.

Cash cows kan være guld værd, men de kan også være så dyre at have på kost, at de forhindrer en i at anskaffe den fuldautomatiserede malkerobot, der kommer til at være en nødvendig forudsætning for at skalere bedriften.

Oversat til software-verdenen betyder det, at vi nogle gange må erkende, at produkter eller komponenter, som vi engang har lavet, brystet os af og været stolte ved, måske ikke i al fremtid er den bedste løsning til eller overhovedet relevant for virksomhedens problemdomæne. Og det koster måske lidt på stoltheden, især hvis man ikke selv er den, der først har indset, at verden er på vej et andet sted hen, end den var i går.

Vi kender alle udtrykket, at "det gode er det bedstes værste fjende", i den forstand, at man nogle gange lever for længe med en middelgod løsning, blot fordi den eksisterer. Derved gør man sig sårbar overfor at blive overhalet af konkurrenter - ja, måske ligefrem af realiteterne.

Ledelsesteoretikeren Peter Drucker (manden, der opfandt begrebet "videnarbejder") skriver med stor visdom i sin bog "Om ledelse - udfordringer i det 21. århundrede" om nødvendigheden af at udfordre eksistensberettigelsen af virksomhedens produkter og processer:

**Man er nødt til seriøst at stille sig selv spørgsmålet: "Hvis vi ikke allerede gjorde det her, ville vi så, med den viden, vi har i dag, beskæftige os med det?"

Hvornår har du selv sidst stillet det spørgsmål?

Kommentarer (30)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jesper Udby

Tjah... Fra JAVA verdenen:

Jeg kommer af og til hos kunder, som har nogle hjemmelavede frameworks og standarder (gudhjælpemig også hjemmelavede coding-style og -guidelines).

Disse er typisk udviklet af godtroende nørder for små 10 år siden, som ikke havde læst (eller forstået) fx "Effective Java" eller "Pragmatic Programmer".

Den slags er ganske enkelt en katastrofe, især fordi de sjældent har flyttet sig de sidste 10 år - det vil ganske enkelt være for dyrt at skrive dem om så de understøtter Generics/Typesafe Collections, Enums, Annotations osv.

At udvikle videre med den slags legacy er sindssygt dyrt - men ingen i organisationen kan få sig selv til indrømme (det har jo kostet kassen), at man ville være bedre tjent uden...

Løsningen er ofte "ny arktitektur version 2", hvor man så enten sender skidtet til Indien og/eller gentager successen, nu baseret på "SOA", gerne med input fra "store firmaer" med gode CMMI ratings. Gartner[tm] siger det gør de andre og det er jo også nyt og smart og lækkert :-)

Damn hvor har du ret :-)

  • 0
  • 0
Allan Ebdrup

Når man starter noget nyt op er det lige det modsatte der gør sig gældende: "det bedste er det godes værste fjende", der handler det om at få noget ud af døren og se hvordan folk bruger det.

I det hele taget er "det bedste" ikke værd at satse på, det du laver vil altid være "godt nok" og så må du justere hurtigt når du ser hvordan brugerne opfører sig. Det er ok at have en vision om hvad "det bedste" er for dig og tage skridt på vejen derhen. Men "det bedste" flytter sig hele tiden og du når aldrig derhen alligevel.

Hvis det er nødvendigt og rentabelt skal man selvfølgelig anskaffe sig den fuldautomatisk malkerobot. Men det er sjældent så simpelt at gøre regnestykket op.

"Det bedste" er en illusion. Jeg ved ikke hvor mange gange jeg har set en forretning spørge en sagesløs udvikler om hvordan man opnår nogle langsigtede strategiske mål, og lige glemt at definere klare rammer, som hvad må det koste og hvor lang tid må det tage osv. Og jeg ved ikke hvor mange gange jeg har hørt de stakkels udviklere der er blevet sat på denne umulige opgave, komme tilbage og sige "Applikationen skal skrives om fra bunden". Det er nærmest standardsvaret i sådan en situation. Men det sker stort set aldrig.

Se hvordan det gik Netscape da de i sin tid besluttede sig for, at omskrive browseren de havde helt fra bunden. De blev fuldstændigt tromlet af MS.

Udviklernes stræben efter "det bedste" kan dræbe enhver virksomhed. Det skal slås og holdes nede! ;-)

  • 0
  • 0
Jesper Udby

HELT enig :-)

Og netop derfor skal man være varsom med at sætte dygtige folk til at udtænke BIP ("Best-Integration-Platform").
For den findes ikke...
Og når den så er lavet, har man så råd til at vedligeholde den, så den er tidssvarende?
Og når den så er forældet, og man har kastet masser af gode kroner efter den, er man så klar til at smide den ud?
Næppe.

Alle (også gode) applikationer når til et punkt hvor de enten skal pensioneres eller vil have bedst af at blive skrevet om.

Derfor: lav det der er godt nok og lav det i en høj kvalitet. Gå efter 90% løsninger (husk 90-90 reglen) og se hvilke krav der kommer, når løsningen er sat i drift...

Og vær ikke bange for at sige: tjah, det brugte vi godtnok nogle millioner på, men den holder ikke længere...

Det betyder ikke man ikke skal kaste sig ud i egenudvikling. Selv "standard software" forældes, skal opgraderes, udskiftes, licenser fornyes osv.

  • 0
  • 0
Anne-Sofie Nielsen

Se hvordan det gik Netscape da de i sin tid besluttede sig for, at omskrive browseren de havde helt fra bunden. De blev fuldstændigt tromlet af MS.

Netscape gik bag om dansen både feature- og stabilitetsmæssigt og blev dermed alt for let for IE at overhale.

Ingen tvivl om, at det sjældent er løsningen at kyle HELE sit produkt overbord og starte forfra, men til tider kan større eller mindre dele af et produkt være så ude af trit med behovet, at det bliver dyrere at beholde det.

Min pointe var blot, at vi har en tendens til at tillægge allerede afholdte udgifter relativt for stor værdi, og ikke tør tænke forfra, fordi vi allerede HAR hældt mange penge i et sort hul.

  • 0
  • 0
Allan Ebdrup

Min pointe var blot, at vi har en tendens til at tillægge allerede afholdte udgifter relativt for stor værdi, og ikke tør tænke forfra, fordi vi allerede HAR hældt mange penge i et sort hul.

Ja det er helt sikkert sandt nogle gange, min pointe var bare at nogle gange tillægger man (sikkert nogle andre man'er end dem du taler om) allerede afholdte udgifter relativt for LILLE værdi ;-)

  • 0
  • 0
Torben Mogensen Blogger

Måske er den rigtige løsning at beholde kernekomponenter fra de gamle systemer og blot lave mere moderne applikationer til at interface med dem.

En stor hindring for dette, at gamle programmer ofte bruger komplicerede og dårligt dokumenterede dataformater. Det gør det for svært for nye systemer at bruge gammel data eller konvertere data til nye formater.

Hvis man bruger simple og veldokumenterede dataformater, er det forholdsvist enklere at lade nye og gamle systemer spille sammen og med tiden helt erstatte de gamle med nye. Det betyder i reglen, at man skal undgå binære filformater, men i stedet bruge tekstbaserede formater. Ikke nødvendigvis XML, som er overkill i mange tilfælde (og ret tung at danse med), men blot noget, hvor man kan skrive en simpel kontekstfri eller regulær grammatik. Hvis man synes, at tekstbaserede formater fylder for meget på disken, kan man komprimere dem med standardkomprimeringsværtøjer.

  • 0
  • 0
Jesper Udby

Måske er den rigtige løsning at beholde kernekomponenter fra de gamle systemer og blot lave mere moderne applikationer til at interface med dem.

Enig, og det er jo i princippet også hvad mange af de større virksomheder, der har "mainframe" som "kernen" gør. Her er "protokollen" typisk COBOL copybooks evt. XML, over en CTG eller MQ...

Det forhindrer dem nu ikke i at bygge en masse hjemmelavede frameworks ovenpå... :-)

  • 0
  • 0
Nikolaj Brinch Jørgensen

Jeg kan ikke lade være med at tænke på RDBMS. De bliver simpelthen brugt til al lagring, fordi man har dem, og betaler en hulens bunke penge for dem løbende.
Alt for ofte ser jeg projekter hvor man ikke vurdere behovet for lagringsstruktur, men hovekuls bare skal have alt ned i RDBMS, mange gange med det til følge at det ender med at blive enormt problemfyldt og omkostningstungt.

Hejmmestrikkede frameworks er ondt (i den forstand Jesper beskriver). Alt for ofte ses de i form af noget nogen har lavet for at bevise de er super seje. Andre gange er nogle konsulenter kommet kortvarigt ind i virksomheden og har solgt ideen om dette framework de kan bygge som løser hele verdens problemer, som så ender i en klon af Struts, Wicket, Spring MVC eller lignende, og hvor det havde været åh så meget bedre at benytte et allerede eksisterende.

  • 0
  • 0
Jesper Udby

Din sammenligning med RDBMS er ikke helt rimelig.

Jeg kan komme med mange gode argumenter for at bruge en god database til "simpel lagring" - hvis altså organisationen bruger RDBMS i forvejen.
Så har man nemlig med stor sandsynlighed også procedurer for backup, restore, recovery, capacityplanning osv. Måske har man også nogle fornuftige (pragmatiske) holdninger til organisering af data.
En ordentlig RDBMS tilføjer også ACID, hvilket er relevant i samme øjeblik man forsøger at opdatere mere end én række i samme unit-of-work, og interesserer sig en smule for dataintegritet.

Mht frameworks er jeg helt enig: lad nu være. Hvis du kan finde noget, helst open-source, som andre bruger, så har du hele verden til at hjælpe dig. Et mystisk statement fra en log-fil kan ofte googles og giver ofte svaret eller årsagen.

Hjemmelavede frameworks skal holdes på et minimum, de skal være så "tynde og simple" at selv den grønneste udvikler kan bruge dem.

Og lad være med at bruge de smarte avancerede features i de lækre frameworks fordi konsulenten foreslår det, med mindre din organisation er gearet til at supportere brugen, også efter konsulenten har forladt biksen.

Mao: KISS!

:-)

  • 0
  • 0
Kim Jensen

Hejsa,

Har prøvet at sidde og vedligeholde nogle temmeligt gamle systemer. Når kerneforretningen ikke er IT, så et IT blot et værktøj, et værktøj bliver ikke bare udskiftet, men skal istedet slibes og vedligeholdes. Jeg kan i den sammenhæng klart anbefale 2 bøger:

  1. Michael Feathers: Working effectively with Legacy Code
  2. Martin Fowler: Refactoring

Ting tager tid, men med de værktøjer beskrevet i disse bøger er det muligt i små skridt langsomt at få mange håbløst forældede og forfærdeligt dårlig kodede systemer bragt op til en mere moderne og mere vedligeholdelses venlig stand.

/Kim

  • 0
  • 0
Magnus Lund

Jeg sad netop og så den her video (http://www.infoq.com/presentations/From-Months-to-Minutes?utm_source=twi...) som har mange af de samme pointer - godt nok i en anden sammenhæng.

Men tanken om at man i tide skal begynde at udskifte komponenter i ens løsning for at rette sig efter hvilken retning markedet/konkurrenterne/teknologien udvikler sig i. Derudover at holde tingene simpelt og koncentrere sig om der, hvor værdien er: Branchekendskabet. Hvis du kender den branche/gruppe af brugere du henvender dig til, er du langt foran dine konkurrenter. Det er den ting som ikke er nemt at kopiere/plagiere.

  • 0
  • 0
Carsten Sonne

Står fortiden i vejen for fremtiden?

Oftest. Men ikke mere end fremtiden nok skal vinde alligevel. Tynger fortiden nok, ja så bliver man "overhalet af konkurrenter" når godt nok, viser sig ikke at være så godt nok, alligevel.

På sin vis er problemet ikke større end markedet selv løser det igennem favorisering af bedre produkter - om ikke andet, så over længere perioder. De største klodser at rykke er monopollignende markedet, hvor konkurrencen er sat ud af spil og kunderne har minimal indflydelse på "Godt nok".

Omvendt giver det ringe udbytte at optimere eller erstatte et system som vitterlig er godt nok sammenlignet med konkurrerende produkter. Hvis business casen ikke er der, så nytter "det kunne være dejlig hvis ..." ikke noget. Et godt råd ville været at bryde en migrering til en nyt og mere tidsvarende system ned i mindre bidder. Herved bliver opgaven mere overkommelig og knapt så skræmmende for den med et "godt nok" system.

En alternativt angrebsvinkel ville været at sikre et system ikke "sander til". Ward Cunningham, Martin Fowler og andre taler i den forbindelse om teknisk gæld eller "Technical debt". Peter Nørregaard havde et blogindlæg for noget tid siden om en relateret problemstilling:
http://www.version2.dk/artikel/18006-teknisk-gaeld-leg-med-matadorpenge

En bemærkelsesværdig detalje omkring fortidens medfølgende inerti, der er værd at notere sig er: Den uden fortid - eller den uden teknisk gæld - er ikke tynget af selvsamme.

  • 0
  • 0
Peter Stricker

På sin vis er problemet ikke større end markedet selv løser det igennem favorisering af bedre produkter - om ikke andet, så over længere perioder.

Ikke større problem??? Nej, men det er så sandelig da også det altoverskyggende problem for den leverandør der vrages af markedet.

Hvis jeg har forstået Anne-Sofie ret, så handler denne blog om at finde løsninger der sikrer, at man ikke bliver den leverandør der blev overhalet af udviklingen.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Din sammenligning med RDBMS er ikke helt rimelig.

Jeg kan komme med mange gode argumenter for at bruge en god database til "simpel lagring" - hvis altså organisationen bruger RDBMS i forvejen.
Så har man nemlig med stor sandsynlighed også procedurer for backup, restore, recovery, capacityplanning osv. Måske har man også nogle fornuftige (pragmatiske) holdninger til organisering af data.
En ordentlig RDBMS tilføjer også ACID, hvilket er relevant i samme øjeblik man forsøger at opdatere mere end én række i samme unit-of-work, og interesserer sig en smule for dataintegritet.

Jeg tror vi snakker lidt forbi hinanden. Ja der er gode anvendelsesmuligheder for RDBMS til lagring af oplysninger der falder naturligt ind i en relationel model, med alt hvad der tilbydes af RDBMS (ACID) mv.
Til hierarkiske data og/eller grafer er det ofte noget gøgl, specielt når det skal skaleres (her kan man bare se på nogle af de RBAC modeller med support for delegeringer som er implementeret i LDAP med RDBMS som backend).

"simpel lagring" som du nævner bør laves simpelt (KISS - selv om jeg efterhånden er ved at være træt af dette buzzword). RDBMS er ikke simpelt.
Desuden er der en tendens til at skulle indføre distribuerede transaktioner i forbindelse med RDBMS indførelse, hvilket er en god grund til at sørge for at holde sig på afstand så længe som muligt. Det skalerer nemlig voldsomt ringe.
Det der starter som simpel lagring, ender ofte et andet sted. Nogen gange vil det passe i RDBMS, andre gange ikke. Jeg har set alt for mange der har "proppet" konfigurationer og alt muligt andet ballade i RDBMS fra start, for at erfarer at det nu er en kæmpe klods opm benet på dem.

RDBMS er et værktøj, og som alt andet værktøj skal det bruges fornuftigt. Det er klart at kender man ikke til andre effektive lagringsmetoder, vælger man det man kender. En DBA kender ofte ikke særligt mange andre. Måske titlen DBA skulleomdøbes til RDBMSA? :-)

  • 0
  • 0
Nikolaj Brinch Jørgensen

Jeg ser ofte kæmpe investeringer i proprietære stakke af software som 5-10 år efter ikke er blevet opgraderet.

Godt nok er det ikke helt det Anne-Sofie snakker om, men den type moderniseringer sker der ofte for få af. Systemerne sander til af den simple årsag at man fokuserer på anskaffelse, langt mere end at man fokuserer på det der i virkeligheden er det dyreste, nemlig vedligeholdelsen. God vedligeholdelse af systemerne gør også at man fjerne redundante og overflødige ting (spild i Lean termer). Man alt for ofte afsættes der ingen ressourcer til dette.
Innovationen står ikke stillle og det der før krævede en hel masse kræfter af maskinerne og en hær af manuel kraft, kan nu omlægges med besparelser og øget effektivitet.
Man gør det bare ikke.

/Nikolaj

  • 0
  • 0
Peter Stricker

Den enes død, den andens brød.

Jeg er helt enig med dig, og derfor synes jeg også at det er godt at Anne-Sofie kommer med gode råd til hvordan man sikrer sig brødet. Det andet alternativ må du gerne beholde, siden det åbenbart ikke betyder noget for dig.

  • 0
  • 0
Anne-Sofie Nielsen

Det syntes jeg da også, Peter. Der er bare forskellige interesser: Kundens og leverandørens. Det er jo ikke en eventyr verden vi lever i. Du vil vel også gerne have mest muligt for dine penge ?

Men givet at man arbejder et sted, hvor man sidder på den software-producerende side (altså leverandørens), har man da en forpligtelse overfor sin arbejdsplads til at sikre, at man også i fremtiden er dem, der render med brødet...

Det er da selvfølgelig en trøst for samfundet som sådan, at der givetvis er andre, der samler de kunder op, som en falleret virksomhed måtte efterlade sig, men som software-producent er det interessante spørgsmål jo, hvordan man bedst muligt sikrer sig, at man til stadighed leverer værdi for sine kunder.

  • 0
  • 0
Carsten Sonne

Det er værd at graduere spørgsmålet lidt. Der er langt imellem de 2 yderpunket, at gå fallit eller at have uovertruffen succes. Heldigvis får de fleste da rettet skuden op inden det går så galt. Krisetider måske untaget.

Og så taler jeg egen regning: Som mening udvikler, er det begrænset hvor stor indflydelse, man har på den type investeringer. Varierende efter forskellige parametre, bl.a. om man arbejder med produktudvikling eller med skræddersyet løsninger, ligger beslutningskompetencen højere eller lavere i det givne organisations hierarki. Investeringer i en tilpas størrelsesorden må nødvendigvis passe ind i øvrige strategiske beslutninger.

Der kan være andre hensyn at tage end de umiddelbare synlige. Faktisk kan man så vidt som at sige, såfremt en sanering af et utidssvarende system udebliver, må det nødvendigvis være grundet andre hensyn vejer tungere. I modsat skyldes beslutningen jo enten magtarrogance eller inkompetence.

Som jeg ser det, er det bedste man som udvikler - eller måske teknisk projektleder - kan gøre, såfremt man mener et system er misvedligeholdt, dels at skabe en selverkendelse ift. det værdiskabende i systemet og dels at søge at skabe en bevidsthed om et systems tilstand blandt relevante beslutningstagere – og så i øvrigt holde for øje, at andre ikke nødvendigvis ser verden præcis som man selv gør, af forskellige årsager.

  • 0
  • 0
Nicolai Møller-Andersen

Det gode står givet af og til i vejen for det bedste.

Det er bare ikke altid, at det bedste er godt nok.

Nogen gange er en god plan i dag bedre end en perfekt plan i morgen.

I een af de der berømte bøger, tror det er Pragmatic Programmer, er der lavet en undersøgelse af fidusen ved at smide alt over bord og kode forfra versus reparare på gammel leverpostejkode. Reparation ender så vidt jeg husker med at være temmeligt godt.

  • 0
  • 0
Anne-Sofie Nielsen

I een af de der berømte bøger, tror det er Pragmatic Programmer, er der lavet en undersøgelse af fidusen ved at smide alt over bord og kode forfra versus reparare på gammel leverpostejkode. Reparation ender så vidt jeg husker med at være temmeligt godt.

Nogle gange er der jo også andre glimrende alternativer til at kode forfra, f.eks. hvis der er dukket nye, velegnede open source komponenter op, som kan erstatte gammel, proprietær kode. Og derved bliver det ikke så meget en udgift at ændre det, man har, som en investering i at mindske fremtidige vedligeholdelsesudgifter.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Nogle gange er der jo også andre glimrende alternativer til at kode forfra, f.eks. hvis der er dukket nye, velegnede open source komponenter op, som kan erstatte gammel, proprietær kode. Og derved bliver det ikke så meget en udgift at ændre det, man har, som en investering i at mindske fremtidige vedligeholdelsesudgifter.

Man kunne jo også være lidt mere open source agtig, og give sin gamle proprietære kode til open source, og så ad den vej få hjælp til udviklingen, samt hjælpe andre.

På den måde kunne man også bidrage i stedet for kun at være forbruger af open source.

:-)

Ellers har du da helt ret. Man må så håbe, at i tråd med at man får foræret en hel del udvikling, at man så vil afsætte dem der før lavede proprietær kode, til at bidrage til open source. Desværre opfører meget få softwareleverandører sig sådan.

  • 0
  • 0
Kim Jensen

Man må så håbe, at i tråd med at man får foræret en hel del udvikling, at man så vil afsætte dem der før lavede proprietær kode, til at bidrage til open source. Desværre opfører meget få softwareleverandører sig sådan.

Open Source Software (OSS) er ikke den gyldne løsning på ret mange problemer, faktisk er det uhyre få projekter der reelt overlever som OSS, da interessen generelt er propertional med dets udbredelses muligheder.

Software leverandører skriver gerne noget der af 2 årsager ikke er interessant at gøre til OSS. Den første grund er den rent juridiske, kunden har en kontrakt, og en standard part her er gerne ejerskabet af kildeteksterne. Den anden grund er at næsten alle projekter er skrevet meget specifikt til en kunde, og derfor ikke noget som man kan lave til OSS, da det næppe vil have interessante komponenter (en leverandørds standard komponenter er gerne noget som man beholder som en konkurrence parameter).

Endeligt, så bør man heller ikke glemme, at der kan være skrevet hemmeligheder ind i koden, eksempelvis forretningsgange, specielle algoritmer, o.s.v.

/Kim

  • 0
  • 0
Nikolaj Brinch Jørgensen

Hej Kim,

Software leverandører skriver gerne noget der af 2 årsager ikke er interessant at gøre til OSS. Den første grund er den rent juridiske, kunden har en kontrakt, og en standard part her er gerne ejerskabet af kildeteksterne. Den anden grund er at næsten alle projekter er skrevet meget specifikt til en kunde, og derfor ikke noget som man kan lave til OSS, da det næppe vil have interessante komponenter (en leverandørds standard komponenter er gerne noget som man beholder som en konkurrence parameter).

Jeg tror at vi (du og så Anne-Sofie og jeg bla.) taler om to forskellige ting.
Du taler om projektudviklet software. Altså specialudviklet software som er lavet til/for en kunde og denne kundes forretning. Her er det rigtigt at copyright ofte er kundens, men det er jo noget man kan forhandle. Det er også at en del projekters komponenter i tidens løb er endt som OSS.
Vi (Anne-Sofie og jeg) taler om produktudvikling. Altså produkter som er brede i den forstand at de skal sælges til så mange kunder som muligt.
Det er klart at i brede softwareprodukter, er der funktionalitet, som er bredt egnet, og som derfor kan benyttes af andre. Dem kan det være en fordel at udgive som OSS (det er bla. blevet til en hel række af WebApp Frameworks på Java fronten af den vej). Det er også klart at copyrighten i dette tilfælde er ens egen.

  • 0
  • 0
Kim Jensen

Hej Nikolaj,

Jeg tror at vi (du og så Anne-Sofie og jeg bla.) taler om to forskellige ting.

Jeg prøver at uddybe lidt. Som jeg ser der er der primært 2 aspekter af denne diskussion; Overvejelse & Relevans.

Kigger man lidt på det første aspekt, nemlig overvejelsen om at gøre noget til OSS, så er der en række parametre som man skal vurdere. Blandt disse nævnte jeg før, at der kan være kontraktlige forhold (herunder rettigheds problemerne), forretningsmæssige problemer (konkurrence hemmeligheder), o.s.v. Hvor stor en procentdel af alle projekter der falder indenfor denne kategori er svær at sige, men hvis nogen siger 80+ procent, vil jeg ikke være forbavset.

Det andet aspekt er når man har en komponent der er mere generel, så kan man kigge på relevansen ved at gøre den til OSS, her er der så problemet at der næsten med garanti findes et utal af tilsvarende OSS komponenter (du kan jo eventuelt prøve at finde mine OSS projekter, blot for sjov ;-)).

Kigger man på Freshmeat.net eller SF.net, så kan man få en ufattelig stor liste over OSS projekter, såfremt man graver lidt ned i listen, så er det meget tydeligt at grønne udviklere lige mangler 1-2% funktionalitet i et eksisterende projekt, så fremfor at tilføje dette, så laver man et nyt. Oftest er problemet også den anden vej rundt, en udvikler har lavet et OSS projekt, men kommer man med en udvidelse til det, så er det ikke altid at denne falder i god jord!

Når jeg læser kommentarer der siger at OSS er vejen frem, så leder det oftest tankerne hen på alle de udvikler konferencer/træf jeg har deltaget i - hvor grønne udviklere stræber efter at blive den næste Linus Torvalds. Nej, OSS er sjældent vejen frem. Førend man kaster nye projekter ud, bør man overveje relevansen, en forhåbning/forventning om at andre vil fikse ens problemer er et tegn på blåøjet naivitet.

Fremfor at kaste egne projekter i grams, bør man istedet overveje at deltage i udviklingen af eksisterende, selvom dette for mange udviklere er som et slag i ansigtet.

Håber dette uddybede min kommentar.

/Kim

  • 0
  • 0
Nikolaj Brinch Jørgensen

Hej Kim,

Dit indlæg er relevant. Men som jeg ser det (uden det rettighedsmæssige og forretningsmæssige blandet ind i det, man kan sagtens beholde sine rettigheder, og man det meste af den software et produkt består af, er ikke "forretningssoftware"), er der ikke så meget tabt ved at lave nogle af sine komponenter til OSS. Det værste der kan ske er, at man ikke får nogen udefra til at deltage, og så sidder man så med de samme udviklere der laver den samme kode. Altså status quo.
Det giver vel en situation hvor der er meget at vinde, men ikke rigtigt noget at tabe.
Som jeg sagde er en del af de succesfulde OSS projekter netop afledt af andreudviklings projekter, og andre ud fra at licensvilkårne for det proprietære alternativ er ugunstige, og nogen så mener der bør findes et OSS alternativ.

  • 0
  • 0
Kim Jensen

Hej Nikolaj,

man kan sagtens beholde sine rettigheder, og man det meste af den software et produkt består af, er ikke "forretningssoftware"), er der ikke så meget tabt ved at lave nogle af sine komponenter til OSS. Det værste der kan ske er, at man ikke får nogen udefra til at deltage, og så sidder man så med de samme udviklere der laver den samme kode. Altså status quo.

Hvorvidt man vinder eller ej på at gøre en projekt til OSS, er for mit vedkommende irrelevant - det er op til de enkelte selv af afgøre.

Men, jeg ville lige knytte en kommentar til problematikken omkring rettigheder, da dette er et sted hvor man skal træde varsomt.

Det mange glemmer, er at tredje-parts komponenter selv har nogle rettigheds betingelser, disse skal alle samstemmes med projektet, og en af farerne ved OSS er at eksterne udviklere knytter nye tredje-parts komponenter til projektet, som ikke er samstemt, hvilket kan få ret kedelige konsekvenser.

Når vi laver nye produkter/projekter, så er det gerne med en liste af for-hånds godkendte tredje-parts moduler, der alle er inklapslet i "wrappers", således at en udskiftning af modulet kan gennemføres med minimal indflydelse på selve projekte. Kommer der ønske om nyere/andre komponenter, så skal disse først igennem en analyse/godkendelses process.

/Kim

  • 0
  • 0
Log ind eller Opret konto for at kommentere