Trobergs betraktelser (om mjukvaruutveckling)

[f91jsw]

(Fortsättning på den här tråden: http://www.byggahus.se/forum/teknik/160318-era-saemsta-erfarenheter-med-iphone-3gs.html)

Varför skulle inte kod som är utvecklad under en öppen licens kunna användas? Man väljer ju själv vilken kod man inkluderar i det man kör, så man kan mycket väl ha öppen kod med bara sin egen kod.

Att användaren själv ska kunna modifiera koden är en del av det, men om man lägger den under GPLv2 så behöver man inte ge användaren teknisk möjlighet att lägga in sin modifierade kod på den aktuella hårdvaran.

Jag tycker du har en underlig syn på vad som är öppen kod.

Det finns två aspekter här: det ena är att använda någon annans open source-kod. Det är som jag försökt förklara utelslutet av regulatoriska skäl eftersom koden inte är utvecklad under kvalitetssäkrade former. Det andra är att publicera sin egen kvalitetssäkrade källkod. Det du föreslår ovan är alltså just det, dvs man publicerar källkoden men utan att ge användarna möjlighet att i praktiken använda koden för det den är tänkt. Visst kan man göra det, men återigen, vem skulle ha intresse av att granska sådan kod för en obskyr medicinteknisk apparat?

Instämmer. De viktigaste metoderna för kvalitetssäkring är:

* Erfarna utvecklare.
* Genomtänkt design.
* Vettig utvecklingsmetodik.
* Bra koddesignsregler.

Nej, det är inte vad begreppet kvalitetssäkring betyder. Kvalitetssäkring innebär att man har rutiner för att säkerställa att (bl a) de metoder du nämner finns, och följs. Problemet med open source-utveckling är just att säkerställa efterföljandet. När du åker på en granskning av en Notified Body eller FDA kommer de att kolla hur du gör för att säkra metoderna. Det gör de genom att titta på dina utvecklares CV, titta på dina SOPar för design och utveckling, titta på dina kravspecar, dina designspecar, dina testplaner för verifiering och validering etc. Man kan tycka vad man vill men detta är den enda metodik som är accepterad för säkerhetskritiska system och det gäller i alla industrialiserade länder.

Tja, vetenskapscommunityn brukar vara glada för sådant.

"Vetenskapscommunityn" har i allmänhet redan tillgång till hårdvaran genom specialavtal med tillverkaren. De får då tillgång till koden eller i alla fall någon form av API och kan leka fritt med tekniken. Sådana maskiner får då inte användas för klinisk verksamhet, eller också har man speciella rutiner för att ställa om mellan klinisk verksamhet och forskningsverksamhet. Sådan verksamhet fungerar bra och är till gagn för både tillverkaren och forskarna, och helt öppen källkod är inte nödvändig.

Korrekt, men samtidigt är det desto viktigare att felen upptäcks genom kodanalys, inte genom test. Testerna kan funka tusen gånger, sedan sker något oväntat med hårdvaran och något går fel. När man granskar kod så gör man det utifrån att koden skall kunna hantera alla lägen som hårdvaran ska kunna hamna i.

Titta på Therac-25, det är ett typexempel på hur hårdvara kan funka perfekt massor av gånger, för att sedan göra något oväntat.

Erfarenheten har visat att kodgranskning bara har begränsat värde för att upptäcka fel oavsett hur noggrann den är. För att uppnå hög säkerhet krävs flera steg där kodgranskning är ett. Exempelvis testning och feltolerant arkitektur/redundans är andra. Systemet måste designas för att vara säkert även om det finns fel, som är oundvikliga i all mjukvara.

Security through obscurity är förkastat för länge sedan. Designa systemet säkert, då spelar det ingen roll om någon ser koden.

Det stämmer inte alls. Inom kryptografi möjligen, men security through obscurity är en viktig princip inom många tekniska sammanhang. Det är t ex en grundläggande del i doktrinen för att förhindra spridning av kärnvapen. Även i harmlösa sammanhang som konsumentprodukter är det flitigt använt. Många tillverkare av kameror, mobiltelefoner, teveapparater etc. räknar med att kostnaden (tid och pengar) för att göra reverse engineering eller bryta något skydd på produkten ska vara så stor att de hinner räkna hem vinsten innan någon annan kan börja profitera på den.

Rent företagsekonomiska aspekter. Man vill inte ge bort t ex algoritmer och andra företagshemligheter till konkurrenterna.

Förlegade affärsmodeller (speciellt när det är hårdvara inblandat...).

Det är knappast förlegat eftersom säkerligen mer än 90% av alla företag använder principen. Inom medicintekniska produkter i framkanten skulle jag säga 100%.

När jag gör ett program som min arbetsgivare säljer, så är det inte ett antal kodrader som kunden köper. Kunder har ett problem, och köper en lösning. Kan man prestera lösningar snabbare och bättre genom att utnyttja öppen kod så kommer kunden bara att bli ännu gladare. Om företag kan dra nytta av varandras kod så tjänar alla på det.

Det finns ett otal andra möjliga förutsättningar som inte stämmer in på dem som du jobbar under. Mitt företag har ett antal algoritmer som kärnprodukt. De övergripande principerna för algoritmerna är kända men vi har jobbat i ett tiotal år med implementeringen av dem och har en uppsjö med speciella lösningar för att optimera och förbättra implementationen, allt från rena programmeringstekniska finesser till speciella numeriska metoder och parameterval. Vi är ett förhållandevis litet företag (i förhållande till giganter som GE, Siemens och Philips). Om vi släppte vår kod fri för att plockas upp av jätteföretagen, vilket värde skulle finnas kvar i vårt företag?

 

[Troberg]

Det finns två aspekter här: det ena är att använda någon annans open source-kod. Det är som jag försökt förklara utelslutet av regulatoriska skäl eftersom koden inte är utvecklad under kvalitetssäkrade former. Det andra är att publicera sin egen kvalitetssäkrade källkod. Det du föreslår ovan är alltså just det, dvs man publicerar källkoden men utan att ge användarna möjlighet att i praktiken använda koden för det den är tänkt. Visst kan man göra det, men återigen, vem skulle ha intresse av att granska sådan kod för en obskyr medicinteknisk apparat?

Tja, man kan ju ta in kod från andra som utvecklar under samma regelverk?

Sedan när det gäller intresse av att granska koden så underskattar du hackers intresse för obskyra utrustningar.

Sedan skulle jag nog hävda att det är lika säkert att ta in väl bra, beprövad och granskad kod som att skriva ny enligt en viss kvalitetsmodell, men visst, regelmässigt kan det vara svårare att hantera, men man borde kunna utöka regelverket med en kvalitetsmodell för inkludering av främmande kod.

Nej, det är inte vad begreppet kvalitetssäkring betyder. Kvalitetssäkring innebär att man har rutiner för att säkerställa att (bl a) de metoder du nämner finns, och följs.

Jag vet det, men utan de förutsättningar jag nämner så kan kvalitetssäkringen bara innebära att man låser fast sig på en jämn, men låg, kvalitetsnivå.

Man kan tycka vad man vill men detta är den enda metodik som är accepterad för säkerhetskritiska system och det gäller i alla industrialiserade länder.

Tja, man borde kanske fundera på att anpassa den metodiken när bättre metodik dyker upp?

Erfarenheten har visat att kodgranskning bara har begränsat värde för att upptäcka fel oavsett hur noggrann den är. För att uppnå hög säkerhet krävs flera steg där kodgranskning är ett. Exempelvis testning och feltolerant arkitektur/redundans är andra. Systemet måste designas för att vara säkert även om det finns fel, som är oundvikliga i all mjukvara.

Instämmer. Det var därför jag satte "erfarna utvecklare" överst på min lista, för det är där allt börjar.

Det handlar dessutom inte om att eliminera fel, det lär man aldrig klara, utan att minska risken för fel och öka chansen att ett inträffat fel kan hanteras på ett säkert sätt. Allt är sannolikhetshantering. Programmerar man en skärmsläckare är det likadant, men med betydligt lägre krav på säkerhet eftersom riskerna är mindre, men grundläggande riskanalys är densamma.

Det stämmer inte alls. Inom kryptografi möjligen, men security through obscurity är en viktig princip inom många tekniska sammanhang.

Nej, det håller inom programutveckling i allmänhet också. Se till exempel på hur Linux är i princip fritt från säkerhetsluckor, medan Windows har fler hål än en ko som trampat på en splittermina. Att felen upptäcks och åtgärdas innan de kommer ut i skarp drift ger mycket högre säkerhet än att man inte gör något förren de blir ett problem och man hinner få till en patch.

Att folk kan se din kod gör också att du verkligen anstränger dig för att göra den prydlig, och prydlig kod är lättolkad kod, och lättolkad kod är mindre felbenägen kod.

Det är knappast förlegat eftersom säkerligen mer än 90% av alla företag använder principen.

Så, bara för att bara 10% har hunnit ta steget in i framtiden så innebär det att det inte är framtiden? Titta på trenderna!

Inom medicintekniska produkter i framkanten skulle jag säga 100%.

Inte konstigt att det är så dyrt att ta fram läkemedel då, när alla måste uppfina hjulet separat.

Det här är ett område där jag anser att staten borde gå in och kräva öppenhet, helt enkelt för att det skulle ge den medicinska utvecklingen en så mycket högre utvecklingstakt, vilket skulle rädda massor av liv.

Det finns ett otal andra möjliga förutsättningar som inte stämmer in på dem som du jobbar under. Mitt företag har ett antal algoritmer som kärnprodukt. De övergripande principerna för algoritmerna är kända men vi har jobbat i ett tiotal år med implementeringen av dem och har en uppsjö med speciella lösningar för att optimera och förbättra implementationen, allt från rena programmeringstekniska finesser till speciella numeriska metoder och parameterval. Vi är ett förhållandevis litet företag (i förhållande till giganter som GE, Siemens och Philips). Om vi släppte vår kod fri för att plockas upp av jätteföretagen, vilket värde skulle finnas kvar i vårt företag?

Tja, titta på hur småföretag som MySQL, TrollTech (QT) med flera sålts för fantasibelopp, trots att de haft sina produkter öppna. Vad vill köparna ha, de får ju inte mer ägande av produkten än vad tex jag som använder den har? De köper kompetensen, de köper inflytande på utvecklingen, och de tycker att det är värt miljardbelopp i de marknadsfördelar det ger.

Edit: Jag var en gång, precis som du, misstänksam mot öppen kod. Men, jag läste på, jag provade, jag utvecklade under sådana former, och jag kan inte se hur någon skulle vilja stanna i de gamla modellerna. För mig så känns det som att sitta i en Ferrari och längta efter en rostig cykel, det är så stor skillnad.

 

[Milkshaken]

Äventyret fortsätter... Vem ska få sista ordet.... Spännande...

 

[Troberg]

Milkshaken: Verkar som om det blev du.

Edit: Attans, nu blev det visst jag ändå!

 

[f91jsw]

Tja, titta på hur småföretag som MySQL, TrollTech (QT) med flera sålts för fantasibelopp, trots att de haft sina produkter öppna. Vad vill köparna ha, de får ju inte mer ägande av produkten än vad tex jag som använder den har? De köper kompetensen, de köper inflytande på utvecklingen, och de tycker att det är värt miljardbelopp i de marknadsfördelar det ger.

Jag kan visst se att det finns fördelar med open source, men i traditionella säkerhetskritiska branscher som medicinteknik ligger det så lågt borta från nuvarande filosofi att det vore helt omöjligt för ett litet företag att rubba strukturerna. Tänkandet i branschen genomsyras till stor del av tänkandet inom läkemedelsbranschen, där kompetensen inom företaget har ett mycket ringa värde. Kompetent labpersonal finns överallt och kemitekniken är mer eller mindre standard. Det som har värde där är den kemiska formeln på läkemedlet (patentet) och hur långt man har kommit i kliniska studier. Detta stämmer visserligen dåligt med produkter som inbyggda system där företagets know-how är minst lika mycket värt om inte mer, men den kunskapen är svår att få fram till investerare och företagsledningar.

När det gäller de exempel du tar upp handlar finns det såvitt jag kan bedöma en del avgörande skillnader mot medicinteknikbranschen: Inom IT-branschen rör sig utvecklingen extremt fort och det finns stora och snabba pengar att hämta för den som hänger på ny och slagkraftig teknik fort. Utvecklingen är i sig förhållandevis billig eftersom det "bara" behövs några duktiga programmerare och man har ändå inte så lång tid på sig att utveckla produkten så man hinner inte bränna mycket pengar. Det man säljer för miljardbelopp är inte främst det tekniska utvecklingsprojektet utan det faktum att köparen inte skulle ha tid att utveckla en motsvarande produkt utan att riskera att missa tåget.

Inom medicinteknikbranschen rör sig däremot allting långsamt medan utvecklingskostnaderna är mycket stora eftersom det handlar om mjukvara som ska utvecklas parallellt med högt specialiserad hårdvara (med en massa regulatoriska krav som sinkar ytterligare). Det innebär att man som litet utvecklingsföretag är beroende av stora investeringar av riskkapital under lång tid. Om man ska köra open source-utveckling har man då ovanpå allt annat problemet med att övertyga investerarna att de ska pumpa in pengar under lång tid i ett projekt som i princip vem som helst när som helst kan ta resultaten från utan att betala något. När styrkeförhållandena mellan konkurrenterna är ojämna talar tiden emot den mindre parten. Om GE har en motsvarande produkt kan de i lugn och ro sitta och följa projektet och plocka in godbitarna i sin egen produkt efter hand.

 

[Krillew]

Förlåt att jag lägger mig i...

När jag skriver kod och det är nått jag undrar om så kan man ofta söka på nätet och få fram ett svar..
Väldigt bra.. det finns mycket exempel opensource mm..
Jag lägger själv ut kod som andra kan ladda ned...

Vi gör en produkt som är CE-märkt vi måste ha ordentliga tester...
så jag skriver Unit tester mot både det jag laddar ner och mot min egen kod.. ingen skillnad..
allt måste testas..

Men om framtiden är opensource ??!! som tidigare inlägg så måste jag hålla med om att det som är företagt hemligheter måste man hålla på för det är ju dom som ger oss en fördel på marknaden.

Det här debatten med open source är nästan som debatten om vad som är modärna språk..
Många tycker t.ex att Java är grejen det är "nytt" o hipp och det jag jobbar med Delphi är totalt ute...
Det är många fler som jobbar i java än i Delphi. Är det för att java är så mycket bättre?? nej naturligtvis inte
det beror mest på vilken typ av applikationer som byggs mest.. Sen kan det bero på att samma sak som skall göras i Java i stället för t.ex Delphi kräver fler timmar i java än i delphi... Men utgår man från Open source så får man snabbt upp nått i Java.. men skall du skriva allt själv tar det tid...

Så visst opensource och "open language" går hand i hand...

Dyra utvecklingskostnader... Ja visst men hela tiden så slås jag av hur vissa företag lyckas sälja in nått om knapt existerar... Många rider på det här .. vi anpassar för er.. Men sen så blir det inget när väl affären är klar... det är väl inget opensource projekt som är klart ännu som man kan sno koden från!!??

Framework är bra som opensource och där finns det mycket för webb..
Sen den här opensource marknaden livnär även dom som "lever" på att undervisa i olika framework och miljöer.

Jag är lite kluven....
Open source är bra för vissa saker... men andra inte..
Jag tror inte att opensource är framtiden. Om man backar lite ca 7 år tillbaka alla pratade om opensource och plugginfunktionaliteter... Idag är det inte lika hett..
Ett företag måste alltid hålla i sina produkter att sätta i gång o kopiera BMW är inte så lätt... men att
kopiera musik, film, code mm är lätt.. man behöver inga speciella utrustningar..
Ett företag som lever på att sälja bokföringsprogram får ju snabbt en konkurent om det är opensource..

Sen visst så har vissa uppköpare som krav att allt skall bygga på opensource...
Vill man sälja till dom så får man slåss med andra... den som juger bäst får uppdraget..

 

[Milkshaken]

Krillew: Exakt så känner nog dom flesta av oss "Hobbyinsatta"......
Bra skrivet och formulerat.

 

[Mats]

Det finns en sak till som är rätt avgörande i större verksamheter.

Går en databas ner i tex en processindustri pga en bugg så kan det kosta mångmiljonbelopp i timmen. Vilka garantier på åtgärdstid inklusive skadestånd/kompensation för stillestånd kan jag få?
Med en opensourcelösning är det extremt svårt att hitta något företag som vill ta på sig den garantin.
Med de stora closed Source leverantörerna är det inga som helst problem att få ett sådant avtal. Naturligtvis får man betala mer för ett sådant avtal men iom att en årsvinst kan raderas med bara någon dags stillestånd så är det något man gärna försäkrar sig emot.

Tanken med små snabba komponenter som skulle vara bra på sitt och inte bli stora och komplexa är en gammal tanke.
Den första ordentliga satsningen på det i volym hette Windows. Vi vet hur det gick...

 

[ordain]

Det jag kan undra lite över är att diskussionen om öppen respektive sluten källkod nästan uteslutande handlar om väldigt publika infrastrukturprodukter, såsom operativsystem, webbservrar, webbläsare, applikationsramverk, databaser, etc.

Detta är produkter som har en extremt stor spridning och det är därför naturligt att dessa får stor uppmärksamhet. För dessa går det också att hävda att öppen källkod innebär att "många hjärnor" kommer att granska och förbättra produkten.

Om man ser till utveckling totalt så är dock dessa stora publika produkter en väldigt liten del. Den allra mesta mjukvara som skrivs är väldigt specialiserad. För denna mjukvara blir det inte speciellt intressant om källkoden är öppen eller inte.

Om du utvecklar ett användargränssnitt för en specifik tandläkarröntgenapparat som ditt företag tillverkar, eller syr ihop en lösning för att få företagets 20 år gamla lokalbokningssystem att funka tillsammans med tidsrapporteringsystemet, eller någon annan mindre "häftig" utveckling, så spelar det ingen större roll om du släpper källkoden för produkten eller inte. Inga mängder av utvecklare kommer kasta sig över din källkod för att submitta patchar till dig. Ingen kommer heller orka lägga tid på att stjäla bitar av koden.

Jag skulle gissa att de flesta utvecklare arbetar med sådant där synen på öppen källkod inte är så enormt avgörande.

 

[Troberg]

Jag kan visst se att det finns fördelar med open source, men i traditionella säkerhetskritiska branscher som medicinteknik ligger det så lågt borta från nuvarande filosofi att det vore helt omöjligt för ett litet företag att rubba strukturerna.

Jag håller inte med om att det är mindre säkert. Låt säga att du bygger ett system som har en databas i botten (de flesta system (utom embedded) brukar ha det). Vad gör Oracle säkrare än MySQL? I ena fallet är du utlämnad åt Oracle, och måste lita på dem (tro mig, det är inte roligt), i andra fallet kan du både granska och fixa databasen om det är galet. Programutveckling av meningsfull komplexitet idag bygger på sådana färdiga komponenter som tex databaser eller bildbehandlingsbibiliotek, och ingen vid sina sinnens fulla bruk skulle sätta sig och skriva sådana komponenter från scratch för att få det säkrare. En beprövad, pålitlig databashanterare är tex ett jätteprojekt att ta fram.

Detta stämmer visserligen dåligt med produkter som inbyggda system där företagets know-how är minst lika mycket värt om inte mer, men den kunskapen är svår att få fram till investerare och företagsledningar.

Just ledningen är enligt min erfarenhet proppen. De förstår inte öppna licenser, deras möjligheter och deras skyldigheter, och svänger sig glatt med modeord som de inte förstår.

Det är dock en utbildningsfråga, inte en teknisk fråga.

När det gäller de exempel du tar upp handlar finns det såvitt jag kan bedöma en del avgörande skillnader mot medicinteknikbranschen: Inom IT-branschen rör sig utvecklingen extremt fort och det finns stora och snabba pengar att hämta för den som hänger på ny och slagkraftig teknik fort. Utvecklingen är i sig förhållandevis billig eftersom det "bara" behövs några duktiga programmerare och man har ändå inte så lång tid på sig att utveckla produkten så man hinner inte bränna mycket pengar. Det man säljer för miljardbelopp är inte främst det tekniska utvecklingsprojektet utan det faktum att köparen inte skulle ha tid att utveckla en motsvarande produkt utan att riskera att missa tåget.

Inom medicinteknikbranschen rör sig däremot allting långsamt medan utvecklingskostnaderna är mycket stora eftersom det handlar om mjukvara som ska utvecklas parallellt med högt specialiserad hårdvara (med en massa regulatoriska krav som sinkar ytterligare). Det innebär att man som litet utvecklingsföretag är beroende av stora investeringar av riskkapital under lång tid.

Nja, det kan funka på hype-produkter som tex Skype, men så fort man kommer in på stora produkter som måste vara stabila, tex Linux, MySQL, QT, stora administrativa databassystem (tro mig, det är antagligen den största biten i IT-sektorn) med mera, då är det en lång väg att gå. Då kostar det tid och pengar.

Om man ska köra open source-utveckling har man då ovanpå allt annat problemet med att övertyga investerarna att de ska pumpa in pengar under lång tid i ett projekt som i princip vem som helst när som helst kan ta resultaten från utan att betala något. När styrkeförhållandena mellan konkurrenterna är ojämna talar tiden emot den mindre parten. Om GE har en motsvarande produkt kan de i lugn och ro sitta och följa projektet och plocka in godbitarna i sin egen produkt efter hand.

Å andra sidan kan man då utnyttja att GE också lägger in resurser i det, och plocka tillbaka godbitar som de gör. Resultatet blir att båda företagen får en fördel som de som inte är med på tåget missar. Visst, man är inte ensam om att få fördelen, men man har också delat bördan och risken.

Jag tror inte att opensource är framtiden. Om man backar lite ca 7 år tillbaka alla pratade om opensource och plugginfunktionaliteter... Idag är det inte lika hett..

Nja, man pratar inte om det lika mycket för att det nu är accepterat. Det är inte en fråga längre, det är ett svar.

Dina argument fanns säkert när aktiebolagen först uppfanns. Varför ska jag investera i något om andra också tjänar på det? Svaret är samma då som nu: För att dela på bördan, risken och för att kunna köra större projekt än vad man skulle kunna var för sig.

Men om framtiden är opensource ??!! som tidigare inlägg så måste jag hålla med om att det som är företagt hemligheter måste man hålla på för det är ju dom som ger oss en fördel på marknaden.

Är det verkligen det? Köper kunden kodrader eller är det den expertkunskap som ni besitter som också råkar finnas i kodraderna? Väldigt få programvaror är "fire and forget", de flesta innebär att man startar en långsiktig relation med kunderna. Då är det viktigt för kunden att programmet inte bara funkar och gör vad det ska idag, utan också i framtiden. Det kräver kompetens, och det betalar kunderna för.

Vi gör en produkt som är CE-märkt vi måste ha ordentliga tester...
så jag skriver Unit tester mot både det jag laddar ner och mot min egen kod.. ingen skillnad..
allt måste testas..

Om du använder kod under en öppen licens (lite beroende på licens) så blir automatiskt hela er produkt under samma öppna licens. Detta gäller speciellt GPL. Det är inte en free for all, det ställs krav på motprestation.

Ja visst men hela tiden så slås jag av hur vissa företag lyckas sälja in nått om knapt existerar... Många rider på det här .. vi anpassar för er.. Men sen så blir det inget när väl affären är klar...

Tyvärr mycket vanligt, speciellt inom konsultbranchen.

Ett företag som lever på att sälja bokföringsprogram får ju snabbt en konkurent om det är opensource..

Definitivt inte. Det är ett område där områdeskunskap är nödvändigt. Man måste hänga med i lagändringar, omvärldsförändringar och sånt, det är så mycket mer än att bara kunna kompilera ett program. Dessutom är bokföring notoriskt supportkrävande, något som de som gjort programmet kan göra bättre än någon annan.

Går en databas ner i tex en processindustri pga en bugg så kan det kosta mångmiljonbelopp i timmen. Vilka garantier på åtgärdstid inklusive skadestånd/kompensation för stillestånd kan jag få?
Med en opensourcelösning är det extremt svårt att hitta något företag som vill ta på sig den garantin.

Har du försökt? Det är inte så svårt.

Dessutom, om ett företag går omkull så står du där med rumpan bar. En öppen produkt lever vidare så länge som det finns användare.

Om man ser till utveckling totalt så är dock dessa stora publika produkter en väldigt liten del. Den allra mesta mjukvara som skrivs är väldigt specialiserad. För denna mjukvara blir det inte speciellt intressant om källkoden är öppen eller inte.

Jag håller inte med. Jag jobbar med precis den mjukvara du talar om, och det stora drivet just nu handlar om integration mellan system, att få systemen att samverka. Det kräver ofta att åtminstone delar av koden är öppen.

Många kunder begär dessutom tillgång till koden, eller att den hålls av en betrodd tredje part och släpps om företaget skulle gå omkull, just därför att det är ett specialsystem och viktigt för dem. De vill ha garantier för att systemet kan leva längre än företaget.

 

[lars_stefan_axelsson]

Går en databas ner i tex en processindustri pga en bugg så kan det kosta mångmiljonbelopp i timmen. Vilka garantier på åtgärdstid inklusive skadestånd/kompensation för stillestånd kan jag få?
Med en opensourcelösning är det extremt svårt att hitta något företag som vill ta på sig den garantin.
Med de stora closed Source leverantörerna är det inga som helst problem att få ett sådant avtal. Naturligtvis får man betala mer för ett sådant avtal men iom att en årsvinst kan raderas med bara någon dags stillestånd så är det något man gärna försäkrar sig emot.

Tja, å andra sidan så är stora delar av telekomsystemet i Sverige idag byggt med (Erlang, gcc, gdb, java, ant osv) och av (Linux, div. nosql, Apache osv) fri och öppen källkod. Ericsson lämnar naturligtvis sådana här avtalsenliga garantier. (Men betalar förstås inte ut något. Det är väldigt sällan det i praktiken faktiskt kommer till några pengar i slutändan och gör det det så är det inte mycket. Det är därför som alla lovar 100% tillg. idag). Dessutom så har jag aldrig varit med om att exv. Oracle skulle gå in och garantera upptider osv. Det gör enligt min erfarenhet någon mellanhand. Som inte har så mycket pengar som det skulle behövas. (Men det finns säkert undantag).

Och det är ju samma sak med det berömda "vi kan få support av microsoft om vi köper windows". Nej, det kan ni inte. Och ni får inte en krona av dem heller. Däremot finns det flera andra företag som lämnar support, dem kan ni få hjälp av, men knappast några större summor.

Vad gäller just embedded/HA, så är det ju i den delen av branschen som just gcc/Linux osv. har en mkt stor del av marknaden, även om man aldrig ser det utan att läsa det finstilta. Alla "specialister" som fanns på 80-talet har ju gått under, och traditionella RTOS känner pressen från Linux extra hårt idag. (Notera att jag pratar om "vanliga" HA-system osv, alltså inte den enstaka procenten som utgör av kärnkraftverk, fly-by-wire, rymdfärjan osv.)

 

[Troberg]

Och det är ju samma sak med det berömda "vi kan få support av microsoft om vi köper windows". Nej, det kan ni inte. Och ni får inte en krona av dem heller. Däremot finns det flera andra företag som lämnar support, dem kan ni få hjälp av, men knappast några större summor.

Vilket är precis hur det funkar för Linux också, fast Linux har också bra support online via diverse forum.

Vad gäller just embedded/HA, så är det ju i den delen av branschen som just gcc/Linux osv. har en mkt stor del av marknaden, även om man aldrig ser det utan att läsa det finstilta. Alla "specialister" som fanns på 80-talet har ju gått under, och traditionella RTOS känner pressen från Linux extra hårt idag.

Exakt. Jag har sett vad det kan kosta att ta fram ett eget RTOS, även ett väldigt enkelt sådant för en specifik tillämpning. Kan man bygga på färdiga och beprövade bitar så sparas mycket pengar.

 

[Mats]

Och det är ju samma sak med det berömda "vi kan få support av microsoft om vi köper windows". Nej, det kan ni inte. Och ni får inte en krona av dem heller. Däremot finns det flera andra företag som lämnar support, dem kan ni få hjälp av, men knappast några större summor.

Jo, du har för det första 90 dagars installations och komma igång support inkluderat i priset för operativsystemet om du köper en Windows kartong. (Ej oem)
För det andra så har Microsoft egna supporttjänster så att säga att man inte kan få support från dem är direkt felaktigt. Den vanligste supportformen för större kunder är Premier Support där man normalt sett har support för alla licensierade produkter. Man är också garanterad resurser med kunskap om just den produkten/komponenten när man får problem.

Sen beträffande viten osv så beror det som sagt på storlek på kund och vad man vill betala. Jag har varit med om både hård och mjukvaruleverantörer som har fått slanta.
Troberg var inne på konkursrisker tidigare. Det är just därför man går direkt på de stora spelarna och skippar mellanhänderna.

 

[lars_stefan_axelsson]

Jo, du har för det första 90 dagars installations och komma igång support inkluderat i priset för operativsystemet om du köper en Windows kartong. (Ej oem)
För det andra så har Microsoft egna supporttjänster så att säga att man inte kan få support från dem är direkt felaktigt. Den vanligste supportformen för större kunder är Premier Support där man normalt sett har support för alla licensierade produkter. Man är också garanterad resurser med kunskap om just den produkten/komponenten när man får problem.

Jepp, jag är medveten om allt det där. (Har haft med det att göra på SKF, Ericsson, och i högskolevärlden). Och det bruka ändå sluta med; "Oj, det där har vi aldrig sett, jag har ingen anning, vi öppnar en ticket på det där," osv, osv.

Jag var med (inte direkt, utan högst på ett hörn) när Ericsson trodde att man skulle kunna bygga routrar/112-system på Windows NT. Det gick inte. Inte ens i närheten. Och den support man fick var inte vatten värd. Vilket inte förvånar mig, jag har sett en del riktiga "godag yxskaft" svar från WindRiver (vxWorks... no it doesn't) och de är i alla fall i rätt bransch. Microsoft är det inte. Frågan är aldrig om man kan få pengar när de inte håller vad de lovar, utan om man kan tro att de kan hålla vad de lovar. Om man försöker göra något som inte alla andra kunder gör med produkten så krävs det en storleksordning mer arbete, och ev. garantier om skadestånd spelar ingen/mycket liten roll i sammanhanget.

Så, jag formulerar det så här istället. Om man *behöver* support, så kan man inte få det. Om man behöver "hålla handen" när man installerar om ett OS på en desktop. Så kan man få det. Och några pengar för att de inte kan hålla vad de lovat (vare sig det är IBM, SunOS eller Microsoft) får man typiskt inte. Eftersom det finns tillräckligt med finstilt som tar det tillbaka, och de stora företagen har tillräckligt med advokater för att kväva dig i pappersarbetet. Om man måste gå till domstol så har man som företag typiskt redan förlorat.

 

[lt1cobra]

...

Nej, det håller inom programutveckling i allmänhet också. Se till exempel på hur Linux är i princip fritt från säkerhetsluckor, medan Windows har fler hål än en ko som trampat på en splittermina. Att felen upptäcks och åtgärdas innan de kommer ut i skarp drift ger mycket högre säkerhet än att man inte gör något förren de blir ett problem och man hinner få till en patch.
...

OT. Men att Linux är fritt från säkerhetsluckor är helt enkelt inte sant...
http://secunia.com/advisories/search/?search=debian
http://secunia.com/advisories/search/?search=red+hat
http://secunia.com/advisories/search/?search=slackware
http://secunia.com/advisories/search/?search=gentoo

Må hända att någon del inte har haft en bugg, men det är som att säga tex : Terminal services tjänsten i windows inte har haft en bugg och därför är windows säkert...

Slut på OT