Japp, i stort sett överens. Jag tror inte vi kommer längre utan jag tackar för debatten. Ha det bra. Hoppas vi får möjlighet att diskutera fler gånger … 🙂

/Marcus

Skämt å sido, jag förstår din ståndpunkt men jag står också fast vid att argumentet, även om det är för OSS, är i klenaste laget och knappast ett som får vågen att tippa över till OSS fördel.

Att själv, eller med andra, ta ägandeskap över en kodbas är ett sätt att få som man vill i produkten men det finns andra som funkar bra men annorlunda där jag inte behöver äga någon kod. Tex, och det här gäller ju för både OSS och stängd programvara, feature requests via user groups eller dylikt (MS har ju tex Connect där man kan rösta på features, med tillräckligt många röster så lyfts featuren in i planeringen). Det är de här möjligheterna som gör att jag inte tycker att ”ägandet” av koden tillför så mycket till OSS fördel.

Men det är ganska tydligt att den här frågan är väldigt tydligt baserad på omständigheter, erfarenheter och frågan om vad man tycker är viktigt. Vilket är det som gör att jag inte tror att OSS kommer att bli den all rådande ordningen pga av tillgång till källkoden utan det är andra faktorer som måste spela in som är mer affärsdrivna än så.

Men i stort överrens, otroligt 😉

Jag tror att inte att våra system och projekt skiljer så mycket faktiskt. Jag tror att vi i grund och botten är överens om att det inte alltid (eller mycket sällan) är önskvärt att använda möjligheten att anpassa koden genom att modifiera en stor kodmassa man annars inte behöver förvalta.

Men sedan skiljer det lite. Jag tror att du tittar i din värld med de projekt du jobbar medan jag försöker se till alla aspekter. Jag hävdar att det trots allt finns ett stort värde i att möjligheten finns. Du skriver själv:

”Vill man ta det ansvaret själv och bygga kompetens runt kärnan i produkten och anser att det hjälper min affär (min verksamhet brukar sällan stå och väga pga avsaknaden av ett API eller ett par saknade parametrar) då skall jag ta över ägandet av koden och investera i den kompetens som behövs”

Detta kräver ju att det finns en möjlighet att göra det vilket jag förespråkar. Sedan är det ju som du skriver i de flesta fall inte ekonomiskt försvarbart att göra det, men man behöver inte göra det ensam. Om du vill ha en funktion som inte leverantören vill implementera kanske det finns ett incitament för en extern aktör att implementera den och erbjuda den till dig och de andra som vill ha den.

Ett annat scenario kan vara till exempel en Kommun som behöver en viss anpassning av ett system och kan välja att göra den anpassningen tillsammans med några andra kommuner och i samma veva lägga förvaltningen på en extern, förhoppningsvis lokal, partner.

Nyckeln är möjligheten och valfriheten och att denna även gäller andra, inte bara mig. Slipper man så är det så klart bra.

I övrigt håller jag med dig i alla dina argument. Jag vill inte heller förvalta kod som inte ger mig ett försprång gentemot mina konkurrenter. Men samtidigt jobbar jag med än gärna tillsammans (finns flera former för det) med mina konkurrenter på sådan kodmassa som vi ändå har gemensamt eftersom det för den totala utvecklingen framåt. Ett bra exempel på detta tycker jag är Linux-kärnan som idag utvecklas till stor del av olika företag som är konkurrenter i mycket annat.

Som sagt, vi är överens om det mesta men jag hävdar fortfarande, envist, att det är en stor fördel att kunna anpassa programvaran. Jag tror också att vi är överens om att det är mycket positivt för framtidssäkerheten.

Jag tror att vår meningsskiljaktighet beror på att vi jobbar med olika typer av projekt och har olika typer av krav.

Vad gäller anrop och parametrar så brukar det vara ett väldigt komplext arbete att ”lägga” till i stora och komplexa produkter. Oftast finns inte parametern där av en anledning och om ett API är privat så betyder det att de som byggt produkten inte förväntar sig att det används på några andra sätt än de som produkten gör.

Min erfarenhet är att en sådan ändring kanske verkar enkel vid ett första ögonkast men är oftast extremt komplex i praktiken, för att inte tala om det som du själv tagit upp: versionshantering i framtiden med nya patchar och versioner från upphovsmakaren.

Vill man ta det ansvaret själv och bygga kompetens runt kärnan i produkten och anser att det hjälper min affär (min verksamhet brukar sällan stå och väga pga avsaknaden av ett API eller ett par saknade parametrar) då skall jag ta över ägandet av koden och investera i den kompetens som behövs. Men i de allra flesta fall mår min verksamhet bättre av att låta bli och jag skulle vilja påstå att de som argumenterar för att ändra APIer snarare har ett kod-centriskt tänkande än ett med affärsfokus.

Jag skulle också vilja hävda att i slutändan handlar det om att den enda kod jag vill äga och ha ansvar över är den kod som ingår i mitt strukturkapital och gör min affär unik jämfört med mina konkurrenters.

Ramverskoden för Java eller Office bidrar sällan till mitt strukturkapital utan är mer ofta en kostnad och jag vill inte ha kostnader, jag vill ha strategiska investeringar.

Tack för ditt välskrivna inlägg. Kul att kunna föra en saklig debatt.
Jag ser också att jag missuppfattat eller dragit för stora växlar av
ditt inlägg på IDG där du skriver att det inte är ett argument mot utan
ett klent argument för fri programvara.

Men jag hävdar fortfarande att det är ett starkt argument för. Som jag
skriver tidigare innebär inte möjligheten att anpassa en produkt att man
måste göra det. Det är inte ens önskvärt att man gör det. Precis som du
skriver innebär det då också att man måste hantera framtida patchningar
av produkten manuellt, eller köpa in förändringen och underhållet från
någon annan.

Om man förändrar koden är det bästa att skicka förändringen till
upphovsmannen av programmet och hoppas att de lägger in den i den
officiella versionen så slipper man problemet.

Men till ditt argument. Du nämner några programvaror och att
programvaror ofta låter sig anpassas via någon programmeringsmodell
eller integrationspunkter. Det är ju kalas! Har man en programvara som
är perfekt och låter mig modifiera den och samtidigt på ett naturligt
sätt isolera min egen kod så finns det ju ingen anledning att ändra
eller läsa koden.

Men vad händer om jag skulle sakna ett visst anrop eller parameter? Jag
inser att den måste finnas i programmet men jag kan inte nå den via något
api, i alla fall inte enligt den dokumentation jag fått. Jag kontaktar
leverantören och av någon konstig anledning vill de inte ge tillgång
till den parametern. Alternativt säger de att det eventuellt kommer att
vara med i nästa version.

Nu är jag i ett låst läge och källkoden hade varit bra. Så jag hävdar
fortfarande att det är ett mycket starkt alternativ för, men jag är
lycklig så länge jag slipper nyttja det.

/Marcus

Jag påstår inte att argumentet är mot fri programvara, jag säger att det är ett av de sämsta argument man kan försöka använda /för/ OSS.

De flesta större och seriösa programvaruföretagen låter dig anpassa deras programvaror med hjälp av någon form av programmeringsmodell eller integrationspunkter. Med dem kan jag oftast fokusera på min affärsverksamhet och lägga till det som är specifikt för mig till den generella produkten.

I den typ av verksamhet jag rör mig så är det sällan OS du är intresserad av att anpassa utan snarare affärssystem, crm, portaler, ordbehandlare och dylikt. Att bygga utökningar till dem och integrera dem med varandra kräver oftast inte öppen källkod så i de fallen tillför OSS inte så mycket för att jag skall kunna vara ”affärsmässig”.

Jag kan tex bygga programvaror med .NET Framework och Java (även innan Java blev någon form av kvasi-OSS). Att ha tillgång till källkoden i de båda fallen tillför inget ur ett ”affärsperspektiv”. Samma gäller tex Sharepoint, jag har en enorm mängd möjligheter att anpassa sharepoint till min verksamhet utan att ha tillgång till sharepoint-källkoden eftersom det är byggt med massvis av utökningsmöjligheter. Det innebär bla att jag kan fokusera på att hantera endast min källkod och inte för hela produkten, med alfresco blir det lite annorlunda, där har jag en stor kodbas som jag inte ens förstår som jag också får underhålla om jag vill använda deras kod.

Så även om fri källkod ger mig ”fördelar” vad gäller produktens fortlevnad så är jag sällan intresserad av att hantera det ansvar, kravet på kompetens och kunskap som tillgång till källkoden för tex Open Office skulle ge mig när det räcker med kompetens för tex Visual Studio Tools for Office och integrationsmöjgliheterna där för att faktiskt anpassa ordbehandlaren till min verksamhet.

Så igen, jag säger inte att det är ett argument /mot/ OSS utan jag vill mena att det är ett ganska haltande argument /för/.