Hvad er der galt med closed source?

Jeg har haft at gøre med open source i snart 5 år, dog kun som slutbruger, men jeg programmerer også en del. Min indsigt rent programmeringsmæssig, har gjort at jeg i den seneste tid virkelig har kunne mærke en begyndende trang til at hente source koden til de programmer jeg bruger, og derefter tilføje den feature jeg lige mangler. Og ja. Jeg er også udemærket klar over at det måske er for nørklet at gøre, og kræver laaang tid, men bare at jeg har muligheden. Den gør mig glad. Jeg har derfor også begyndt at føle mig indelukket når jeg sidder på en windows system, for her er langt største delen af alle de programmer jeg bruger closed source. Jeg har ikke mere friheden til at ændre de programmer jeg henter og omforme dem så de passer til mig. Jeg kommer nok højest sandsynlig aldrig til at ændre i nogle af de open source programmer jeg bruger (det skulle lige være min emacs som jeg kan proppe lidt ekstra features i med elisp), men bare det at jeg har muligheden. Det betyder meget for mig.

Jeg kan finde på flere dårlige ting at sige om Word, fx dårlig understøtte af almindelige filformater og styresystemer. Jeg har også flere gange forsøgt mig med OpenOffice, LaTeX og andre mindre kendte alternativer, men jeg er altid gået tilbage til Word på grund af dens suveræne håndtering af formattering (inklusiv fonte).

Måske har du ret i, at det er et problem når folk vælger at lave 20 mellemrum efter hvert afsnit (er det den rigtige oversættelse af "paragraph"?), og så ændre udseendet lige så mange gange, og hver gang lave markeringen lidt forskellig, således at hvert af de 20 mellemrum har forskellig font, størrelse, farve osv.

Jeg havde sikkert heller aldrig lært hvordan man får Word til at arbejde med sig i stedet for mod sig, hvis jeg ikke havde lært om style sheets da jeg lærte HTML&CSS.

Men kan man forvente, at hr. og fru Danmark kan bruge style sheets i Word? Måske ikke, men det er nu ikke så svært. Jeg har på under en halv time hver forklaret de fleste i min familie, hvordan man bruger dem, og når jeg en gang i mellem kigger dem over skulderen, bruger de det faktisk.

Nå, men nu handler det om open og closed source. Jeg tror ikke på at licensen gør den helt store forskel. Det handler om hvem der udvikler produktet, og om de vil noget med det og kan, uanset om det er betalte medarbejdere eller et fællesskab af frivillige.

Jeg støder tit på manglende dokumentation, hvilket ikke er noget problem for OS, da man kan kigge på kilden. Og der er næsten altid et forum/maillist til OS-projekter, hvilket også er en utrolig rar ting. Nej, support-telefon er bare ikke specielt godt - har du prøvet Microsoft? Du bliver smidt rundt til forskellige afdelinger og ingen ved noget.

Licenser skal bare fungere. Når jeg køber et produkt til mange tusinde kroner, så skal skidtet bare kunne installeres uden problemer med licenser. Jeg har desværre været nødsaget til at bruge cracks, da licenser har fejlet ved installation eller licens-systemet har sat så mange begrænsninger, at den eneste løsning har været en crack, hvis det skal benyttes i en virksomhed.

Som du selv påpeger Jesper, så er prioriteringen af programmørenes forskellige arbejdsopgaver meget forskellige. Og nu du stiller det op på den måde, kan det både være en styrke og en svaghed for Open Source, at programmørene retter den slags gener. Hvis udviklerne af Open source programmer bliver populistiske og fortrinsvis satser på at forbedre oplevelsen af programmet, frem for at rette potentielle fejl med datatab. I et konkret eksempel så vi på Linuxfronten det revolutionære 3D skrivebord kaldet Compiz. På grund af intern splid delte projektet sig pludselig i to løsninger: Beryl og Compiz, hvoraf Beryl uden tvivl var den mest populære, fordi de valgte at satse på smarte og flotte effekter frem for stabilitet, som ellers blev værdsat af Compiz programmørene.

Man kan jo desuden hævde at producenterne af kommercielt closed source software i højere grad er sårbare overfor datatab, fordi der som regel ikke medfølger garanti på open source software.

Min største problem med closed source software er min mistillid til virksomheders etiske dømmekraft. Vi har varedeklarationer på madvarer, miljøkontrol og fødevarekontrol - Hvorfor har vi det?. Hvorfor har vi ikke det inden for IT? og hvorfor er det så væsentligt at holde koden skjult?

I OpenSource verdenen kan man ikke komme med en ny version og droppe den gamle med mindre den nye vitterligt er bedre end den gamle, vel at mærke fra brugernes synspunkt, hvis man gør det er der stor risiko for at nogen anden fortsætter i stedet med at udvikle på den gamle version.

Jeg bruger aldrig word. Det går ned- eller jeg får det, til det. Det slår aldrig fejl.

Linux suxx- hvis man ikke er programmør. Det er fint- fortæller en massse- men jeg ikke programmør. Computeren er betydelig bedre end mig til at huske kode, så det foretrækker jeg den gør.

Computeren har langtfra nået komfortstadiet, hvor den er let at bruge for de fleste. For at kunne bruge en pc skal man stadig vide så forholdsvis meget, at det svarer til at at tage certifikat til en jumbojet- for at bruge en symaskine. Og alt de med sikkerheden! Meget af det må brugren rode med selv. Det er ikke som at spænde bæltet og køre. Nogengange tror man bæltet er spændt- og det er det ikke. Ærgerligt ærgerligt, dine data er v æ k!

Mvh Tine

At Word ikke kan håndtere fonte tilfredsstillende er ikke et problem ved closed source. Det er et problem ved Word.

Problemet ved closed source (FOR MIG **) er at jeg ikke har muligheden for at modficere det, når det ikke fungerer som jeg ønsker og at det lever på nåde af producenten. Jeg har ikke lyst til at blive brændt (igen) af en leverandør, der lukker og slukker for et produkt. Det forhindre Open Source.

**: Jeg mener det er vigtigt at folk svarer på den her slags spørgsmål ved at spørge sig selv hvorfor det ikke er godt FOR DEM istedet for at antage at det bare generelt ikke er godt. Det samme var problemet i Open Source-debatte Jesper referer til. Folk antager at blot fordi de ikke kan se hvad de skal bruge det til, så er der nok nogle indbyggede problemer i konceptet.

Jeg vil anbefale en Mac... og det er dybt seriøst ment. Det er ikke "computeren" som ikke har nået komfortstadiet, det er primært Windows (men B.G. har jo også sagt at "hvis du ikke kan få det til at virke så få det i det til at se pænt ud!" hvilket forklarer en hel del om Windows).

Du må have nogle rigtigt dårlige erfaringer med Linux, er det noget du vil dele med os ?

Jeg kører SuSE, min far på 70 kører SuSE og min søster kører OS X (og hun er sluppet for computerskrækken af det).

Jeg støder tit på manglende dokumentation, hvilket ikke er noget problem for OS, da man kan kigge på kilden.

Manglende/dårlig dokumentation er i høj grad også et problem med OSS. Den der med, at man bare kan læse koden holder ikke. På kode niveau er der alt for mange forstyrrende detaljer, som man skal holde rede på.

Det primære problem ved closed source er, at man ofte ikke har nogen chance for at finde ud af, hvad det egentlig er, der sker. Det kan til dels afhjælpes med fremragende dokumentation, men kravet til ordentlig dokumentation afhjælpes ikke af, at gøre kode åben. Til gengæld har man måske muligheden for at få hjælp til dokumentationen.

Den er måske lidt søgt som en generel løsning at man blot kan kigge på koden ved OS, men ikke desto mindre, sker det jævnligt at når alt andet fejler, så downloader vi kildeteksten og prøve at greje hvorfor systemet ikke opfører sig som vi forventer. Det munder så som regel ud i en bug-report eller en aha-oplevelse på vores vegne. :)

Det munder så som regel ud i en bug-report eller en aha-oplevelse på vores vegne. :)

Det er så en anden fordel ved OSS: Detaljerede bug reports, der ikke alene dokumenterer fejlen, men også kan indeholde forslag til et patch.

Jeg hader closed source!!

Jeg hader forhindringerne.

Mine personlige udfordringer i 2008:

1) Support kan ikke hjælpe, pga. en underleverandør har skiftet fokus: Intermec 751A terminaler har et trådløst netværkskort af typen MagicLAN fra Samsung. Vi oplever at terminalen på en gaffel truck ikke kan skifte trådløst Access Point, når de køre hurtigt. En sniffer, viser at netværkskortet går i uendelig løkke i en fejlsituation der opstår tit. Intermec support i USA, kan godt se problemet, men har ikke nogen løsning, da Samsung ikke længere har produktserien MagicLAN. Ergo vi har købt support, men de kan ikke hjælpe, og driver/OS er closed source ... Løsning? Køb nyt udstyr!!

2) Support kan ikke hjælpe, pga. nedprioritering: Symbol WS 5100 wiresless switche ... de spytter fejl logfiler ud som ikke er dokumenteret i manualen. Support ved ikke hvad de betyder, det vil jo kræve de kontakter udviklingsafdelingen.

3) Udokumenteret ændringer i patches: Support er gode til at forslog patch udruldninger uden at kunne dokumentere ens fejl bliver løst. Dvs. release dokumentet er mangelfulgt.

3) Lang tid for udgivelser af nye releases: Man finder en fejl i et produkt ... det tager minimum en måned at få producenten i tale ... derefter minimum et halvt år på at få en patch.

4) Licenser ... det er et kapitel for sig selv. Jeg hader at aktivere licenser, at taste 16 cifre koder ind, at taste dem på en telefon eller at fortælle dem over telefonen. Licenser der udløbet ved en fejl (kik på vmware), licens aktiverings server der kører langsomt, eller er gået ned, licener der begrænser software til noget hardware. Specielt hader jeg hardware tokens ... hvordan hænger det sammen med en server platform man vil virtualiser? Hvad sker der hvis hardware token går i stykker? Jeg har betalt for produktet, fat det dog!

Jeg har igennem tidensløb stået med masser af opensource problemer, hvor ting ikke var dokumenteret ordenligt, eller der ikke fandtes support, eller der har været kode fejl eller design fejl ... det har ikke været nogen hindring, så længe man har kildeteksten.

Desværre står jeg ikke samme situation med closed source ...

Der er så lige én ting jeg ikke forstår. Hvorfor fokusere på det negative (Hvad er det galt med...), når man kan fokusere på det positive?

BeOS er et godt eksempel på hvad der er galt med closed source. Haiku er et forsøg på at genskabe BeOS, og for et par måneder siden fejrede de deres 7-års fødselsdag. I løbet af 7 år har de genskabt store dele af BeOS, som open source, men der er stadig lang vej til målet. Havde BeOS været open source, så havde dette spild af tid ikke været nødvendig, og systemet kunne istedet have været fulgt med tiden, og været en reel spiller på markedet for styresystemer. Dem der sidder med sourcen til BeOS, har valgt ikke at bruge den, så de ville ikke have tabt noget, ved at frigive den.

Et andet eksempel er LeechFTP. En lille simpel FTP client til Windows, der gør hvad den skal, uden en masse overflødig pis. Problemet er bare at der ikke har været arbejdet på den siden 1999. Alle holdt vejret da Windows XP udkom, og håbede at den stadig virkede. Det gjorde den heldigvis, og trods mange glade brugeres bange anelser, viste det sig at den også virker med Windows Vista. Hvor længe mon vi kan blive ved med at være heldige?

God pointe. Måske skulle jeg på et senere tidspunkt vende den om, og fokusere på det, som er fedt ved open/closed source.

Man kan jo desuden hævde at producenterne af kommercielt closed source software i højere grad er sårbare overfor datatab, fordi der som regel ikke medfølger garanti på open source software.

Tør du påstå at der følger garanti på closed source? HA! Du har ikke læst EULA, har du? :O)

Tør du påstå at der følger garanti på closed source? HA! Du har ikke læst EULA, har du? :O)

Du spørger om jeg tør, antager derefter selv svaret og smider til sidst "Du har ikke læst EULA, har du?" efter mig. Det er vist lidt søgt, er det ikke det? Jeg har jo netop ikke sagt, at der medfølger garanti på closed source software. Men jeg tror at kunderne i højere grad forventer en eller anden form for godtgørelse, selvom de har læst EULA eller ej.

De fleste fordele ved closed source tilfalder producenten -- der er mindre risiko for, at kode kopieres ind i andre produkter. Selvfølgelig kan open-source licenser også gøre dette ulovligt, men det kan være svært at opdage, når det sker. Endvidere kan producenten nemmere lave support, hvis kunden ikke retter i koden.

For kunden kan jeg ikke se nogen fordele. Kunden kan bare lade være med at se på koden, og har dermed alle de fordele, som closed source giver. Ulemper er der dog nogle af:

• Hvis producenten går nedenom og hjem eller bare ikke ønsker at udbedre kendte fejl, så er man på herrens mark med closed source.

• Det kan være vanskeligere for kunden at interface koden til egen kode, hvis den dokumenterede API ikke er stærk nok til formålet.

Bemærk, at jeg her skelner mellem gratis og open source. Gratis software har udover de nævnte fordele (eller mangler på ulemper) også prisen.

Men for mig er det vigtigste åbne formater: Hvis al gemt data er i veldokumenterede formater, der ikke er unødigt komplicerede, og frit kan bruges uden licenser, så er jeg for det meste tilfreds.

For kunden kan jeg ikke se nogen fordele. Kunden kan bare lade være med at se på koden, og har dermed alle de fordele, som closed source giver.

Ved hardware, kender vi alle idéen med "closed source". Fjernes forsejlingen, går garantien. Det, at sikre sig mod, at kunden bryder ind, er nødvendigt for at kunne tilbyde garanti.

På samme måde er det med closed source. I princippet, vil man kunne tilbyde garanti på produktet, og stå inde for, at det er et produkt uden fejl. Er der fejl, vil du kunne få fejlen udbedret, i op til 3-5 forsøg, og hvis alle fejl ikke er rettet inden, så kan du få pengene retur.

Hvis dem der lavede close-source, tilbød samme garanti - eller blev forpligtet til det - så vil closed source give mening, på samme måde, som du ikke må fjerne forsejlingen, eller åbne et produkt. Efter garantiperioden, er ikke nogen idé med at ikke må fjerne forsejlingen.

Generelt:

Da jeg kan programmere, opfatter jeg det selvfølgelig som at der er noget galt med Closed Source-programmer, hvis jeg ikke kan komme til at rette de fejl jeg støder på i dem.

Typisk:

I praksis er det oftere at jeg støder på at der er noget galt med Closed Source-programmer, der ikke er noget der er en direkte konsekvens af at programmerne er lukkede, men snarere er noget der korrelerer stærkt med det:

a) Programmerne er ikke egnede til at blive brugt fra scripts.

b) Der er ikke en klar mulighed for at rapportere fejl og mangler.

c) Der bruges lukkede/udokumenterede protokoller og filformater.

d) Programmerne kan ikke bruges på alle de relevante platforme.

e) Der mangler integration med styresystemernes systemadministrationsværktøjer.

f) Der mangler genvejstaster til væsentlige funktioner i programmernes brugergrænseflader.

Specifikt:

Nogle programmer der eksemplificerer de ovenstående typiske problemer med Closed Source-programmer:

• SPARK-værktøjerne (d,e)
• Lotus Notes (a,b,c,f)
• Microsoft Power Point (a,b,c,d)
• Microsoft Visual C++ (a,b,c,d,e,f)
• Flash (a,b,c,e,f)
• Microsoft Internet Explorer (a,b,c,d)
• Bloomberg (b,c,e)

Engang var jeg med i projekt, hvor der skulle programmeres op mod et API i CAD-systemet SolidWorks. Min makker sagde at det var et utrolig rodet og ringe API. Det var tydeligt at det var bygget op i forhold til deres GUI og ikke de indre objekter. Det betød at simple operationer på 3D-objekter blev besværlige, fordi man skulle lave noget der mindede om makroprogrammering. For ovenstående specifikation ville det være a, b, c og d. Nu sad jeg heldigvis med front-end-koden i Java.

Jeg tror SolidWorks har været nød til at stille et API til rådighed, fordi nogle "dumme" kunder sagde de ville have det. De er kommet op med en lappeløsning. Hvis det var open source, så ville der slet ikke været noget API, hvis de ikke havde lyst til at lave det. Men hvis de gad, så ville de gøre det ordentligt. Og findes det ikke i ét projekt, så er der nok nogle andre, der har lavet det.

En anden ting jeg savner i closed source, er at man ikke umiddelbart kan "remixe" applikationer, forke dem, gøre dem bedre, og merge dem tilbage igen. Det sker hele tiden i open source-verdenen, fordi det er nemt. Man laver et checkout og går igang. Tænk på KHTML -> WebCore/Safari (closed source) -> WebKit -> Google Chrome -> Iron (den fork lever nok ikke lang tid ?). Det sker ikke i samme grad med closed source, pga. licenser, patenter og immaterielle rettigheder.

Jeg vil lægge ud med akkurat samme indledning som jeg gjorde under open source debatten, bare med modsat fortegn:

Jeg mener at spørgsmålet "Hvad er der galt med closed source?" er for bredt, det er som at spørge "Hvad er der galt med TV-serier?", eller "Hvad er der galt med økologiske produkter?".

Jeg mener hvad er der galt i at mene at noget closed source er godt mens noget andet er noget skrammel, at nogle TV-serier er gode mens andre er dårlige, at nogle økologiske produkter er pengene værd mens andre ikke er?

Men hvis jeg alligevel skal forsøge at svare bredt (det vil sige mine punkter passer på nogle closed source produkter og ikke på andre) så kan jeg komme på følgende punkter i uprioriteret rækkefølge:

1) Ingen adgang til kildekode

Det afhænger af programtypen (standardprogrammel eller specialudviklet), leverandøren, produktet og hvad jeg bruger det til om det har stor eller lille betydning for mig om jeg har adgang til kildekoden eller ej.

Når det omhandler specialudviklet programmel synes jeg altid at kildekoden er vigtig. Først og fremmest er specialudviklet programmel jo normalt hamrende dyrt (nnn timer ganget med høj timepris), samtidigt bliver det ofte leveret af lidt mindre virksomheder (sammenlignet med Microsft, IBM, Oracle m.v.) som man man helst skal være uafhængige af. Hvor uafhængige man rent faktisk kan blive uanset om man har adgang til kildekoden afhænger dog også af hvor godt at softwaren er designet og dokumenteret, men at havde adgang til kildekoden er jo i hvert fald det grundlæggende første skridt.

Ovenstående er dog ikke ensbetydende med at specialudviklet programmel så altid skal være open source i forståelsen distribueres under en open source licens. Der er også andre muligheder som f.eks. overdragelse af rettighederne til kildekoden til kunden (ofte set i offentlige udviklingskontrakter), så closed source betyder ikke nødvendigvis at der ikke er adgang til kildekoden.

For så vidt angår standardprogrammel der har jeg det personligt sådan at hvis producenten er stor (Microsoft, IBM, Oracle m.v.) og hvis jeg ikke har nogen intention om selv at fejlrette i det givne produkt, så betyder det forholdsvis lidt for mig om jeg har adgang til kildekoden.

Selvfølgelig er der en teoretisk chance for at Microsoft, IBM, Oracle m.v. går konkurs, men der er rigtig rigtig mange ting omkring driften af min forretning som der er langt større chance for skulle opstå. Og skulle f.eks. Microsoft, IBM, Oracle m.v. gå konkurs så ville jeg enten leve med deres progammer som de var i dag eller skifte til andre programmer, jeg ville aldrig selv begynde at vedligeholde dem uanset om jeg havde adgang til kildekoden.

Hvis det så er en mindre producent så afhænger det for mig af brugen af det pågældende program. Lad os sige at det f.eks. er et komponent til at konvertere fra Word til PDF og jeg har 10 liniers kode i et af mine programmer der benytter dette. Så betyder det mindre for mig at jeg ikke har kildekoden til dette komponent fordi

• Der findes masser af tilsvarende komponenter
• Arbejdet med at evt. skifte til andet komponent er ganske begrænset.

Hvis det f.eks. er en ORM eller Data Mapper som jeg benytter i mit Data Access lag på mine applikationer, og som der altså investeres rigtig mange udviklingstimer i så begynder det straks at være noget andet, hvilket også er årsagen til at jeg generelt har holdt mig til open source (iBatis, NHibernate) eller Microsofts egne værktøjer, på trods af at der findes rigtig mange tredjeparts closed source ORM/Data Mappers.

Så for mig bliver værdien af at havde adgang til kildekoden altså vurderet fra produkt til produkt, og nogle gange falder det ud til closed sources fordel (fordi at risikoen er så lav) og andre gange ud til open sources fordel.

2) For dyrt

Pris er selvfølgelig væsentligt og sammen med manglende adgang til kildekode jo ofte det som open source produkter benytter som salgsargument.

Som jeg nævnte i open source debatten så er prisen dog for mig personligt sådan set mindre afgørende men selvfølgelig ikke uvæsentlig. Men forstå mig ret jeg benytter nogle open source produkter som jeg gladeligt også betalte en licens for selv hvis f.eks. Microsoft ville give mig deres produkt gratis, og omvendt betaler jeg også gladeligt for nogle Microsoft og andre kommercielle produkter selv om der findes gratis alternativer.

Det afhænger af den værdi jeg får ud af produktet.

Som et eksempel er MS Office hvor at bare det at grammatik/stavekontrol er bedre end i OOo faktisk er rigeligt for mig til at opveje en licens, fordi at den tid jeg ville bruge ekstra i OOo på mere manuel grammatik/stavekontrol, er tid jeg ikke bruger på virkelig at give mine kunder værdi, men blot på at sørge for at det jeg afleverer til dem også er i nogenlunde sproglig kvalitet.

Til gengæld er der andre værktøjer som Microsoft forærer mig gratis men hvor jeg i stedet benytter et gratis open source værktøj (iBatis, NHibernate, NUnit for at nævne et par stykker) og hvor jeg også sagtens ville være villig til at betale en rimelig licenspris for dem.

Men der er selvfølgelig stadig produkttyper inden for hvilke at jeg fravælger et closed source produkt primært på grund af prisen, fordi at den høje pris ikke står mål med den ekstra værdi jeg får ud af produktet. Men når jeg tænker over det så skyldes det næsten hver gang at jeg kun har behov for en brøkdel af det som det pågældende produkt tilbyder mig.

De produkter der lige popper op i hovedet på mig er produkter som f.eks. Microsoft SharePoint, IBM WebSphere produkter, BEA WebLogic/AquaLogic produkter, alle produkter hvor jeg på et eller andet tidspunkt i min karriere har siddet i en situation og skulle foretage et valg af produkt, har kigget på prisen på netop disse produkter og tænkt "det virker godt nok højt i forhold til den værdi jeg får ud af det". Og i alle tilfælde har det været fordi at jeg gerne bare ville bruge et lille hjørne af værktøjet (måske max. 10% af hvad det faktisk kan).

Jeg har også siddet i lignende situationer på større projekter hvor jeg måske skulle bruge 50%+ af hvad disse værktøjer kan, og så har prisen pludselig været mere rimelig.

Det jeg godt nogle gange kunne tænke mig ved kommercielt closed source var at man fokuserede mere på at opsplitte sine produkter i en række komponenter så man størrelse/prismæssigt kunne sammensætte præcis den løsning man ville havde. Så hvis jeg kun valgte 4 ud af de måske 50 komponenter som SharePoint/WebSphere/WebLogic tilbød mig så kunne jeg benytte værktøjet til en rimelig penge.

For et gratis open source værktøj gør det jo mindre hvis du kun bruger 10% af løsningen, mens det kan gøre "ondt" når der er tale om et dyrt kommercielt closed source værktøj.

Jeg tror også at open source er med til at presse på for at ovenstående faktisk vil komme til at ske i større og større grad. Og for IBM, Microsoft, BEA o.s.v. giver det jo også god mening.

Lige som når Jonathan Schwartz siger:

"Students and free users of today are the corporate buyers of tomorrow"

Så burde Steve Ballmer også kunne sige:

"the buyers of a minimal and cheap SharePoint solution of today are the corporate buyers of a full SharePoint solution tomorrow"

3) Er mere afhængig af at kunne levere ny funktionalitet end open source

De forretningsmodeller der benyttes til finansiering af closed source standardprogrammel er efter min mening ofte i langt højere grad afhængige, eller i hvert fald bygget op omkring at der kan leveres nye versioner af softwaren, så der kan sælges licenser til eksisterende brugere.

Men det man begynder at se, og nu er min kendskab størst til Microsofts produkter, er at man begynder at løbe ind i et funktionsloft, måske ikke som at forstå at der ikke kan tilføjes ny funktionalitet, men den funktionalitet der tilføjes er måske kun relevant for meget lille del af brugerne.

Tag sådan noget som Microsoft Windows + Office som de bedste eksempler. De har så meget funktionalitet i dag at jeg tror at store dele af det kun benyttes af en mindre del af brugerne. På samme vis når de skal levere nye versioner af softwaren, så den nye funktionalitet der kan tilbydes vil altså mange gange kun være relevant for en mindre del af brugerne.

Open source er mindre sårbart over for dette, fordi at man fra starten har været baseret på andre finansieringsmodeller hvor at licenssalget har mindre betydning.

4) Svær balancegang mellem videreudvikling af egne produkter og brug af community

Det er primært noget jeg har tænkt over når vi snakker de store closed software produkter.

Hvis man tager sådan noget som f.eks. Linux eller de fleste Linux distributioner (og her snakker jeg om basisinstallationen), så har de jo langt fra i sig selv alle de hjælpeværktøjer m.v. som f.eks. Windows leveres med. Men det betyder intet fordi at man bundler bare med andre open source produkter fra den omkringliggende community, og får derved samlet set et fuldt konkurrencedygtigt operativsystem med tilhørende værktøjer.

Nogle vil nok mene at når mange af de store producenter af Closed Source f.eks. Microsoft ikke gør det samme så skyldes det udelukkende NIH-syndromet (Not Invented Here), men jeg tror kun at det er en del af sandheden. Jeg tror at yderligere del af sandhenden skal findes i førnævnte problem med at der skal leveres nye funktionaliteter, for at havde nye versioner at sælge til kunderne, og så ligger yderligere den del af sandheden i positioneringen af det givne produkt.

Hvis nogle er jer engang imellem læser de markedsanalyser som Forrester, Gartner m.v. laver så når de laver produktsammenligninger så fokuserer de mange gange udelukkende på hvad der leveres med det givne produkt, og mere sjældent på hvad der findes i community'en af tredjeparts løsninger.

Så hvis Microsoft Visual Studio f.eks. ikke indeholder et framework til unit testing, så bliver det altså dårlige vurderet end hvis det har den funktionalitet, uanset at der måske findes ganske udemærket open source framework til unit testing som sagtens kan bruges sammen med Microsoft Visual Studio.

Det leder jo til den svære balancegang for nogle af de store producenter af closed source software at de mange gange gerne vil havde så meget funktionalitet og hjælpeværktøjer m.v. med i deres produkter, men på den anden side skal de også passe på ikke at træde deres community for meget over tæerne, ved hele tiden at udbygge deres produkter på de områder, hvor tredjeparts leverandører forventer at tjene deres penge.

Selvfølgelig går open source heller ikke fuldstændigt fri af denne balanceakt, men indtil videre ser de for mig bare ud til at være langt mindre eksponerede, det er altså langt mere acceptabelt hos forbrugerne at open source programmer i højere grad kan være en sammenblanding af forskellige værktøjer, komponenter m.v. som er udviklet af fuldstændigt forskellige mennesker og organisationer. Det bunder måske nok bare i at man har været forvant til at tænke i at så længe jeg holder mig til en eller få leverandør så er det nok bedst.

For mig at se er det største problem med closed source primært at det er lavet til at blive brugt som "point 'n click", altså INGEN mulighed for at bruge det sammen med andre produkter i en automatiseret / scripted arbejdsprocess.

For eksempel støder har jeg stødt på folk der er fustrerede bare de skal lave 5 ens grafer af forskelligt datamateriale fordi de siger 'hvordan gør jeg det, det vil jo tage timer i excel or få dem ens????'

Jeg derimod vil lave en guplot fil og så lave noget i stil med

for f in fil1 fil2 fil3; do sed 's/inputfile/$f/' opskrift.gp > op.gp ; gnuplot op.gp; done

eller tilsvarende (ok der skulle nok ogse en awk til at ændre output fil men i princippet.. :-)

I min erfaring er næsten ingen closed source produkter gearet til at kunne lave noget så simpelt som ovenstående. Jeg ved godt at man kan lave makroer i excel/word, men de færeste ved hvordan, og når man skal lave noget automatiseret, hvorfor skal man så trækes med winduer der popper op og forsvinder hele tiden???

Man kan rende ind i tilsvarende problemer for open source også (har haft proplemer i den henseende i forbindelse med en labelprinter hvor jeg var nødt til at bruge open office til at printe med -p og den vil ikke køre uden en x-server til rådighed selv om den ikke bruger den...

En anden ulempe ved closed source programmer er at de alt for ofte falder for 'feature creep' hvor man efter et par versioner (som man oftest er tvunget til at opgradere til grudet lukkede dataformater) ender med et program der er alt for tungt at bruge. Dette kan selvfølgelig også ske for open source, men der er de fleste udviklere ofte klar over at brugerene ikke nødvendigvis vil opgradere til en ny version og derfor sjældnere laver nye dataformater midt i det hele.

Hvad er konteksten for at kunne besvare spørgsmålet? Hvis Word havde været open source så alle kunne rette i de antagelige 10 millioner linjer C++ og Visual Basic samt script kode, kunne I så forestille jer at have en ansat (alm. firma frem for et lille start-up firma uden nok opgaver) som brugte arbejdstid på at 1) analysere sig frem til hvorfor håndteringen af fonte ikke er optimal, 2) programmerede en løsning, 3) gennemførte en rigid test heraf således den nye løsning ikke introducerede andre uheldigheder, 4) foretog en udruldning af Word++ i firmaet, for herefter at varetage supporten når udefra-kommende Word dokumenter ikke længere kunne læses? I mit firma skal de tjene penge til forretningen.

Vi kan vel alle kode, de fleste har vel også rettet fejl i Ant, Maven, Spring, diverse kode libraries, ... (og det er virkelig flot at du kan kode og har gjort det) men du vil seriøst vel ikke gå i gang med Word eller lignende hvis det ikke lige skal være til dit hjemme-lan setup?

Ken

Der er intet i vejen med hverken closed eller open source. Det der kan være et problem ved diskussionerne er, at det ofte bliver enten eller. Sådan er virkeligheden jo ikke - alle har lidt MS, Oracle, OSS osv. Diskussionerne bliver ofte religiøse og ensidige. På den ene side kan man lære en masse af en evangelist, men en fanatiker eller en idealist har parkeret fornuften.

Jeg tror det er klogt at sætte sig ud over de religiøse attituder og vælge det rigtige værktøj til opgaven. Herunder at kigge på TCO. Selvom OSS er gratis er det stadig økonomi, der de fleste steder udgør en væsentlig del af beslutningsgrundlaget.

Nej, egentlig ikke dårlige erfaringer, bare at det var svært at bruge, som "almindelig" bruger, der ikke er kodenørd. Det er også blevet nemmere, og jeg overvejer da at skifte (når netbank også er til at bruge).

Som computerbruger igennem 15 år (og adskillige operativsystemer) synes jeg ikke, det er blevet særlig meget nemmere. Jeg har også prøvet mac- og den er for dyr + man ikke selv kan (eller kunne ikke) skifte dele. Den kan heller ikke noget, som jeg ikke kan få i andre OS- er. Med en nørd i huset (fhv Amigabruger nu Linuxnørd), har det givetvis været nemmere for mig, end for de fleste- jeg har support ved hånden (bare ikke til win, som jeg så har måttet lære). Men det er de færreste, der kan afsætte 8 måneder til at sætte sig ind i et OS....

Mvh Tine

Som hardwareudvikler, føler jeg ikke trang til, at rette i f.eks. pentium processoren, ram kredsen, eller andet. For det virker. Og det er kravet.Nul fejl, uanset milliarder af transistorer. Rettede jeg i pentium processoren, vil jeg nemt komme på herrens mark. Og det lyder helt ærligt lidt tosset, at man lige skal ned og rette i rammen, fordi den havde en svaghed, og en bit havde problem med at skifte. Sådan lyder "softwarefolk" i mine øre, når de taler om at "rette". Simpelthen fordi, at software der sælges er så elendigt, at det svarer til, at det virkeligt er en svaghed i "ram'en".

Det var ikke gået, indenfor HW. Så havde producenten gået falit.

Hvis kommercielt software, skal have en fremtid, må de lære af andre brancher: Fremtiden er NUL FEJL. Og ellers er det slut. Man kan - og skal - ikke bruge, eller bygge, på noget der er så meget som éen fejl i. Er der noget, som ikke fungerer - så fjern det. Det har ingen værdi, og ingen brugbarhed. Enhver brug, giver kun "troubles". Og udgifterne, burde kunne føres tilbage til dem der har gjort fejlen.

Hvis kommercielt software, skal have en fremtid, må de lære af andre brancher: Fremtiden er NUL FEJL

Men er folk parate til betale for det?

For der er jo vitterligt nogle steder de laver software stort set 100% fejlfrit, men deres kost pr. linie skrevne kildekode er også meget høj

For et par år siden mens jeg sad og arbejdede på en B2B ehandelsløsning, der læste jeg en artikel fra et amerikansk firma som leverede software primært noget der skulle embeddes i hospitalsudstyr, flyvemaskiner m.v. De havde altså meget omfattende kvalitetssikrings metoder. De havde også lavet en beregning af hvad deres kost var pr. linie kildekode.

Jeg tog så og sammenlignende med den B2B ehandelsløsning som vi havde lavet, som var som et ganske gennemsnitligt projekt, der blev fundet fejl og de blev rettet, det blev sat i drift, og der blev fundet lidt yderligere fejl hen af vejen som blev rettet m.v. Altså sådan et ganske standard projekt som langt fra er fejlfrit men hvor kunden faktisk er godt tilfreds med resultatet og forløbet.

Jeg regnede så den gemmesnitlige kost ud pr. linie kode for vores projekt, ud fra hvor mange linier koder der var og så hvad kunden havde betalt for det. Der var en faktor på ca. 80 til forskel.

Nu ved jeg at en kodelinie er svær at definere, men uanset hvordan man definerer den så er der i hvert fald ikke en faktor 80 til forskel i omfang, og samtidigt er lønninger og derved priser jo generelt højere i Danmark end i USA.

Så jeg spurgte så mig selv. Havde vores kunde været villig til at betale en pris der var 80 gange så høj mod at deres B2B ehandelsløsning så havde været fuldstændigt fejlfrit ved levering? Svaret er et rungende Nej, det havde de langt fra haft råd til.

Samtidigt kan man heller ikke helt sammenligne hardware med software, der er væsentligt forskelle i interfaces. Samtidigt er fejl i hardware (også designfejl) da bestemt ikke usette.

[quote]Hvis kommercielt software, skal have en fremtid, må de lære af andre brancher: Fremtiden er NUL FEJL

Men er folk parate til betale for det?[/quote]Nej, folk er ikke villig til at betale noget - spørger du de fleste, vil de hverken betale for udvikling, forskning, eller software.

Indenfor HW, gøres meget for at undgå fejl. Ellers, vil det simpelthen ikke kunne fungere. Årsagen er, at du bruger noget, som andre har lavet, og du skal stå inde for, at dit fungerer. Indenfor software, er omtrent samme problem. Alternativet til nul fejl, er at alt er ubrugeligt.

Eneste sted, hvor der kan argumenteres for, at brugeren kan få lidt indflydelse på, om de "vil betale", er ved applikationssoftwaren - altså den software, der i sidste ende, ikke anvendes af andet software, og af andre end brugeren. Nogle, vil også være villig til at betale for software der er fejlfri her. Det vil de fleste nok.

Jeg argumenterer specielt for, at de grundlæggende dele af computerens operativsystem - det vil sige alt, der "bruges" af andet software, er 100% fejlfrit. Minestryger er et applikationsprogram der ikke bruges af andet software, så det er jeg ligeglad med fungerer. Det som skal fungere 100% er softwarens "bestanddele", altså operativsystem, biblioteker der bruges af andet software, compilere, compilerbiblioteker osv. Efterhånden som du nærmer dig applikationen, bliver det mere ligegyldigt - men det afhænger af applikationen. Regneark, er eksempelvis meget vigtig, og skal også fungere 100%.

På nuværende tidspunkt, har man ikke prøvet at give brugeren muligheden for, at få noget som fungerer. Det vil kræve en lovgivning, så der er garanti, og reklamasionsret på software, som for alt andet. Jeg er sikker på, at brugeren med tydelighed vil vise, at det de ønsker, er noget som fungerer. Og ellers ønsker de ikke at betale. Kan intet leveres, bruges måske open source, og kommercielt software, må begrænse sig, til det som fungerer. En utilfreds bruger, vil få pengene tilbage.

Jeg regnede så den gemmesnitlige kost ud pr. linie kode for vores projekt, ud fra hvor mange linier koder der var og så hvad kunden havde betalt for det. Der var en faktor på ca. 80 til forskel.

Dels, kan du ikke måle i kodelinier. Noget, som virker, fylder ofte langt færre linier, fordi at udvikleren arbejder grundigt med tingene og opnår stort overblik. De kan sikkert nemt spæde det op med en faktor 80 i kodelinier, hvis det betyder noget. Du skal se på det, udfra programmets brugervenlighed og faciliteter.

Dertil kommer, at der ikke er tvivl om, at dem der laver noget som fungerer, har større gevindst på medarbejderne. Programmørerne får måske højere løn. Det er som IBM var førhen - man betaler også for "navnet". Og kvalitet.

Software, skal som jeg ser det deles i to: Open Source, hvor der kan rettes. Idéen er, at der er fejl at rette, og grund til det. Og så closed source - her er ikke noget at komme efter. Nul fejl, og fuld tilfredshed.

Min nørdemand laver lidt Open Source programmering. Hans programstump fylder måske otte linier- og bruges mest af en gut i Frankrig (med ret meget trafik/kunder). Den handler om mail.

Nå humlen er, han opdagede en fejl- rettede den- og brugerne ER glade. De henvendte sig da på mailen.

Koden er effektiv og lille. "Og det virker!" som manden plejer at sige.

Så med Open Source kan en specialist, som min nørdemand yde sit. Et normaldansk firma ville aldrig ansætte ham- han går i dybden- og tænker ikke i penge, men hvad der er godt- for slutbrugeren.

Mvh Tine

Den foregående artikel er sammen med denne artikel i og for sig meningsløse. De bygger for mig at se begge på buddet "du må ikke have andre guder end mig!" og præmissen at man i branchen overholder dette bud. Jeg kan næppe forestille mig at nogen vælger et produkt alene efter dets licensbetingelser. Der må vel være andre parametre. Forestil dig at du skal købe en plæneklipper: "Uha, sikke en fin een den der... den kan jeg selv reparere". Det er jo meget godt for dem som faktisk kan reparere en plæneklipper. Men for sådan en som mig som kun lige akkurat kan skifte tændrør og lader resten foregå på et værksted, har det ingen betydning overhovedet. Dér er det andre ting jeg vælger at kigge på.

Jeg er programmør i en branche med særdeles komplicerede behov og betragter ikke mig selv som begynder i faget. Så principielt kán jeg faktisk godt reparere denne billedlige plæneklipper. Det er bare lige det, at min faglige viden kun dækker mekanikken; jeg ved jo ikke nødvendigvis noget om detaljerne i kunsten at slå græs, ligesom jeg formentlig ikke gad sætte mig ind i de finere detaljer for knibning af visse skriftsnit, stillet foran et problem i mit tekstbehandling og derfor formodentlig ville komme til kort overfor en font-fejl i et open source produkt.

For mig er det til enhver tid behovet der afgør valget. Hvis jeg får formuleret et behov, hvor den åbenhed er afgørende, ja så bliver det taget med. Hvis mine behov kun bliver dækket af closed source software, så har jeg heller ikke noget problem med det. Problemet med diskussionen kontra et pro open og closed source er, at de altid bliver stillet op som modsætninger, og ofte endda så kategorisk at man føler sig som kætter når man vælger den ene frem for den anden. Der ér ingen enkelt sandhed - så enkelt er det.

For der er jo vitterligt nogle steder de laver software stort set 100% fejlfrit, men deres kost pr. linie skrevne kildekode er også meget høj

Når jeg ser på http://www.adacore.com/home/gnatpro/tokeneer/ og lignende projekter, så ser det ikke ud til at prisen nødvendigvis bliver vanvittigt meget højere. (Men så var der også mindst én fejl i første udgave af Tokeneer.)

Så vidt jeg kan se det, er det kritiske ikke så meget hvor mange fejl man vil have i programmerne, men om man sørger for at justere procedurerne og arkitekturen efter hvor mange fejl man ønsker.

/Jacob

Når jeg ser på http://www.adacore.com/home/gnatpro... og lignende projekter, så ser det ikke ud til at prisen nødvendigvis bliver vanvittigt meget højere.

Har du små projekter, vil prisen normalt være høj. Ved større projekter, vil grundigheden oftest betale sig, og medføre færre resourcer bruges til senere fejlfinding. Ved store prjekter, tror jeg at du måske sparer på, at gå efter nul fejl.

Det, som er svært, er at tage et dårligt udviklet projekt, hvor der er opsamlet hundreder eller tusinder af fejl, der tilfældigvis dukker op, på skift, med jævne mellemrum, og omdanne dette til et "nul-fejls" projekt. Det er så godt som umuligt. Ønskes at arbejde efter et fejlfrit produkt, er det en beslutning som skal tages i starten, og man skal holde sig til den. Selvom, der er problemer med tidsplan, eller resourcer, vil det gå galt, hvis der pludseligt accepteres fejl - og ofte må man regne med, at alt skal gøres om fra dette øjeblik. Softwaren, vil ikke have gennemgået tilstrækkelige tjek, måske er dokumentationen for sparsommelig, der er ikke eksempler på brugen af rutiner og objekte, hvor eksemplerne også bruges til test og afprøvning af rutinerne, og brugeren af rutinerne ved måske til sidst, ikke hvad de helt præcist laver, men koder efter formodning.

Når der er fejl i software, er det lidt som ved alt andet. Det skyldes, at man optimerer tidsplanen og økonomien for godt. Det er en slags "Carlson" effekt, der går godt i starten, men går grulig galt senere.