Efter ett uppträdande av Microsofts vice Pres. Craig Mundi och av Richard Stallman, FSF grundare, på NYU (New York Univ.) pratades det under 2001-2002 en hel del om OpenSource kontra företagsegen kod.

Microsoft hävdar att Open Source (vilket GPL inte helt är) är ett hot mot företag, medan FSF menar att all kod skall vara öppen (tillgänglig).

Vår åsikt, som publicerare av copyleft programvara, är att det är helt fel ärende som diskuteras.

Som systembyggare, systemägare eller vilken roll vi har för stunden, måste vi kunna lita på den IT-struktur som vi blir allt mer beroende av. Ändå hamnar vi ofta i situationer som inte förutsätts av programkonstruktören och systemen så inte klarar av.

Ett något groteskt exempel grundaren varit med om, var en ombootning av ett flygplan enligt känt MS-maner (på marken som tur var), strömlöst tillstånd. Mindre groteskt, men väl så irriterande, är den där Word-filen från en kollega, som redan gått upp på senaste version.

Kärnfrågan är snarare, vem har rätten att bestämma över mitt system, Microsoft, FSF, Linus, webdesignern på www.foo.com, databasdesignern på Kalles Databasverkstad eller vi själva?Å

Vi anser att om OpenSource används, skall detta göras på så sätt att den som placerat koden i OpenSource har en relevant och korrekt kontroll över sin kod, enligt den öppna "licenstyp" koden publicerats under (GPL eller annat) o/e att man inte tar betalt för produkter som inte skulle realiserats utan den öppna koden. Det innebär att vill man använda öppen kod, måste man ta konsekvensen därav. [Inom parantes så finns misstanken; har MS någon produkt som innehåller öppen kod de inte kan avveckla, som driver frågan?]

Men härmed erkännes också, att en organisation (offentlig, privat o/e företag) har en berättigad rätt att kunna hålla sin kodmassa privat. Om inte annat, så utifrån driftsäkerhetsperspektivet.

Och om utveckling görs med GNU/BSD/Linux, men inte är en uttalad del av OS:et, dvs. objektet är migrerbart mellan Linux, BSD, Solaris, Posix-derivat, Windows o/e andra fristående OS/system-miljöer, betyder detta att öppen kod aktivt används för att bygga objektet eller tillhandahålles endast en öppen driftmiljö? Om i stort alla systemanrop och biblioteksrutiner är gjorda för att emulera anrop/rutiner som implementerats i mindre öppna system, hur påverkas då verkshöjden/"unikhets"-graden hos använd baskod/bibliotek.

Frågan har delvis diskuterats inom GNU/FSF, men vi känner att den till fullo inte är belyst. GNU/BSD/Linux t.ex. är ju faktiskt bara en "emulering" av AT&T:s gamla "stängda" UNIX-miljö och skulle aldrig uppstått om AT&T tillåtet Ken Thompson, Dennis Ritchie m.fl. att fortsätta att ge bort UNIX så som de gjorde under flera år. Och X är ett am. statlig forskningsresultat.

Men om vi så ser bort från denna rent juridiska kråka i bråket kring GPL, har vi kvar den nog så viktiga innovations-/kvalitetsaspekten.

-------

Öppen kod har en klar positiv påverkan på programmerar-kollektivet, men knappast i den omfattning som görs gällande. Det är snarare attityden hos de enskilda medlemmarna i det öppna kollektivet, viljan att mer öppet diskutera lösningar och att komma med konstruktiv kritik, som är den avgörande nyckelfaktorn i OpenSource-kulturen, inte kodens publicering i sig själv. Att en stor del av medlemmarna dessutom har mer än 5 års erfarenhet av ren kodning, gör inte saken sämre.

Att efter i över 20 år i olika sammanhang [som kund, lärare, chefer, konsulter och kollegor] ha arbetat med programmerare så har en sak framstått allt klarare och tydligare:

I den kommersiella världen finns inte samma tendens till att [inom godkända ramar] diskutera med samma öppenhet. Man sitter mer isolerad på sin kammare, genomförandes sitt pensum enligt tidplan, med statusrappotering som primär kvalitetscheck. Kvalitestkontrol skall säkra koden, men allt för ofta slinker problem igenom, vilket ses i patch-cyklerna.

För att fortsätta, efter 2-3 år som kodare, får programmeraren sin belöning i form av projektledarskap eller liknande. Dvs. kodaren står tillsammans med nätadminstratören och sekreteraren löne- som status-mässigt oftast på nedersta steget.

Javisst, ni som känner att vi beskriver er värld helt felaktigt, det finns undantag, avdelningar och tom. organisationer som har code reviews, premierar kodare m.fl. (t.ex. Google eller "dröm"-fabriken Bell Labs).

Men vi själva har sällan träffat på organiserad så kallad "structured walkthrough" med mindre än att det gällt en kris eller för den delen, programmerare med mer än 5 års erfarenhet - och det även inom ganska stora projekt. Gurus finns möjligtvis med under insäljningen av ett projekt och de första 1-2 månaderna. Sedan tar oftast de mindre erfarna över.

Om vi fokuserar på kvalitetsaspekten, vad vill vi föreslå att man gör? Meningen med inlägget?

Vi föreslår följande handlingsplan:

• Se till de praktiska behoven, behövs Open Source använd Open Source och behövs sk COTS (Commercial Off The Shelf), så använd COTS. Se bara till att systemen manageras korrekt.

• Behåll bra programmerare som vill fortsätta, premiera dem till att stanna som kodare, att specialisera sig. Se dem inte som en ekonomisk belastning, utan en resurs. Och kom ihåg - vi konsulter tar alltid med oss kunskapen när vi går.

• Underlätta intern diskussion, organiserade gruppövergripande "Structured Walkthroughs". Även om ett projekt inte kan dela hela sitt uppdrag, kan problematiska kodavsnitt ofta mycket väl diskuteras utrykta ur sitt sammanhang.

  Viktigt är att moderatorn håller det på en konstruktiv nivå, som grundregel, kritik skall åtföljas av alternativa förslag.
  

• Gör Frederick P. Brooks "The Mythical Man Month" till tvingande läsning (Wikipedia).

  Vi har själva kunnat studera skillnaden via två stora projekt, där ena [projektledaren ovetandes] kördes enligt Brooks MMM modell med 4 personer över 1.5 år, medan det andra utfördes enligt traditionella metoder med 15 personer över 2.5 år. Storleksskillnad i kodmassa: 1:3.

  MMM-gruppen missade målet med 2 månader, men hann då byta verktyg från ett 4GL-verktyg till Oracle Forms och C under projektet. Det traditionella teamet bommade med mer än 1 år och hann inte riktigt starta innan verktygbytet. Samt att en stor del av konsultkoden i slutet fick skrivas om, ca 10-20% av totala koden.

• Använd KISS - Keep It Stupid Simple.

  Nästa alla av oss utvecklare lider av långt framskridet "bra att ha"-syndrom. Ifrågassätt alla, även "kundens", önskemål. Visst går det bra att integrera t.ex. web/mailservrar och klienter i stort sett alla typer av applikationer. Men är det praktiskt, gör det applikationen bättre, finns ett reellt mervärde för användaren?

  Och framförallt, underlättar eller försvårar funktionen för användaren eller den som skall operera server o/e infrastruktur runt applikationen.

  Detta är ett "KVALITETS"-problem som vi konfronteras med dagligen. Programleveratörer som bygger in framförallt web- och e-postserverar högt och lågt, som inköpande avdelning absolut måste använda [de har ju betalt för funktionen] oavsett hur det bryter mot gjorda strategier / existerande miljö.

  Bara för att det går, så gör det inte, om det inte finns ett tydligt affärsbehov (internt, som externt). Speciellt sk. Easter Eggs/Splash-bilder, var finns mervärdet för kunden?

  Vi har aldrig sett något mervärde.

Om vi går vidare på onödighets-spåret, utanför Open Source, men något som helt klart en kvaltetsfaktor.
• Förutsätt inte att kunden (intern eller extern) kan anpassa sig helt till den IT-miljö ni som utvecklare föredrar.

  Typexemplet är webmasters (vi är själva). Har ni försökt klaga till någon för att sidorna ser dåliga ut i Opera o/e NS o/e IE. Vad fick ni för svar? "Installera senaste IE/NS, så fungerar det".

  Webvärlden är kopiöst okänslig för verksamhetsbehov. Om vi har ett produktionssystem, som vi bara måste kunna få ut status från och som bara klarar NS 4.2, vad gör vi när webmastern på vår resebyrå säger; "Ni måste köra IE8 med Flash11!". Eller hävdar att våra PC är för gamla, "Köp nya PC - vi kräver 64bit/2Gb minne"

  Vi bör nog byta resebyrå.

  Förutsätt aldrig, aldrig att vi har kontroll över eller kan styra kundens infrastruktur.

• Och har ni en aning om vad det kostar att byta 500-2000 PC var 3 år, 7.000 per PC? Inkluderat re-installation av program/data, intrimning av nya Office-versioner mm hamnar vi snarare på 30.000/PC. Och det 2007.

  Efter alla år av PC-byte är det fortsatt en okontollerad kostnadsaspekt för många organisationer. Se också på Microsofts nya licensstruktur. Licenserna är dock den lilla delen, hårdvara och uppdateringskostnader är den stora, som nu drivs allt hårdare med Vista och Windows7.

  Företag måste producera sina varor billigare, så den "onödiga" kostnadsökning IT genererar [ofta driven av felaktiga systemstrategier], måste hämtas in på annat håll, ofta till medarbetarnas förfång. Ni har väl hör buzz-ordet, "anorektiska organisationer"? Om någon ekonom verkligen analyserade fenomenet, tror vi denne skulle finna att skenande IT-kostnader är en viktig orsak till många av dagens sparbeting.