Plattformar

From The Joel on Software Translation Project

Revision as of 19:47, 31 January 2006 by Davidhall (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

< Huvudsida | Svenska | 2002-Aug-30 Platforms | >

Av Joel Spolsky
Översatt av Stefan Rindeskar
Bearbetat av Kim Gräsman
den 30 augusti 2002

De flesta programvaruutvecklare, inklusive Fog Creek Software, är fullt nöjda med att bara skriva applikationer. Du vet, program som gör något eller löser något specifikt problem. De modiga bland oss vill förändra världen och väljer därför att jobba med plattformar: stora programvaror som egentligen inte gör någonting i grundutförande men som möjliggör en hel värld av nya och intressanta applikationer. De personerna skriver operativsystem, databashanterare eller runtime-miljöer som t.ex. Java och hoppas att deras plattform ska dra till sig oberoende utvecklare som skapar nya fantastiska applikationer

Ett operativsystem är nästan per definition en plattform. Många plattformar lever i ett operativsystem, som till exempel Javas runtime-miljö. Windows startade inte som ett OS utan som ett program som kördes ovanpå DOS men som i grundutförande inte gjorde annat än att låta utvecklare skapa GUI-applikationer för billiga Intel-burkar.

Det är väldigt, väldigt viktigt att lista ut om en produkt är en plattform eller inte eftersom plattformar måste marknadsföras på ett annorlunda sätt än applikationer för att lyckas. Det beror på att en plattform behöver tilltala utvecklare i första hand och inte slutanvändare.

Jag har precis haft turen att få läsa en förhandskopia av Rick Chapmans utmärkta nya bok om dumheter inom progamvaruindustrin. (Förutsägelse: en bästsäljare). Eftersom jag är en analytisk person letar jag efter återkommande mönster. Ett av de tydligaste mönstren för misslyckanden inom mjukvaruindustrin är en plattformstillverkare som inte förstår att de är plattformstillverkare och därigenom stöter bort sin nyckelgrupp: utvecklarna.

Exempel: NetWare tog så lång tid på sig för att släppa rimliga verktyg för att skapa NLMer att när Unix och Windows NT kom med bättre och billigare utvecklingsverktyg, svepte de bort huvuddelen av utvecklare av serverprogramvara.

Exempel: Apple har spenderat tiotals år med att göra livet surt för sina utvecklare. Varje nytt OS under nästan 20 år har krävt fixar och ändringar i koden till applikationerna. Om du blev för bra så tävlade Apple mot dig (fast ibland hade de en nickedocka vid namn Claris som tävlade mot dig så att de kunde låtsas att det var någon annan).

Exempel: Att utveckla mjukvara för OS/2 krävde en investering på $3000 för SDK:t och då var du tvungen att skriva dina egna skrivardrivrutiner om utskrifter var viktiga för dig. Utskrifter var viktiga så OS/2 hade inga applikationer.

Men motexemplen är minst lika intressanta:

Exempel: De första versionerna av Windows inkluderade en fritt distribuerbar runtime, så att om du skrev en Windows-applikation kunde du sälja den till någon som hade DOS, du var alltså inte begränsad till de få knäppa töntarna (jag!) som köpte Windows 1.0.

Exempel: Trots de misstag som Sun gjort med Java så har deras runtime alltid varit gratis. Bra Java-verktyg var billiga eller gratis, de också. Ingen annan utvecklingsplattform har blivit så dominant så fort (t.o.m. Visual Basic, det bäst säljande programmeringsspråket genom tiderna, tog åratal på sig att slå igenom).

Om du vill att en plattform ska lyckas behövs massiv uppslutning och det innebär att du behöver utvecklare som utvecklar för den. Det bästa sättet att döda en plattform är att göra det svårt för utvecklare att bygga på den. Oftast händer detta därför att plattformsföretagen antingen inte vet att de har en plattform (de tror att det är en applikation) eller så blir de giriga (de vill ha alla intäkter själva).

Giriga plattformsföretag står inte ut med idén att kreti och pleti kan tjäna pengar på deras plattform. Så de gör det nästan omöjligt för vem som helst att utveckla för den. Troligen det mest spektakulära misslyckandet som illustrerar detta var IBMs PS/2, med sin stora portfölj av tillhörande teknologier, som t.ex. Microchannel-arkitekturen som var designad så att IBM var den enda som kunde göra expansionskort. Detta är förstås otroligt kortsiktigt. Ingen ville ha PS/2 för, öh, tilläggskort fanns inte tillgängliga och när de sedan fanns så var de istället för dyra. Som plattformstillverkare är du bara så lyckad som de som bygger på dig.

Ett mer subtilt problem är när plattformsföretagen inte tror att de har en plattform utan de tror att de har en applikation. För att illustrera detta måste jag än en gång hacka på Groove.

"Varför håller du på och hackar på Groove, Joel?" Tre orsaker:

  • De har en intressant arkitektur som tillhandahåller viktig plattformsfunktionalitet som jag verkligen skulle kunna ha användning för i mina egna produkter.
  • De gör det omöjligt (eller i alla fall orealistiskt) för mjukvaruutvecklare att bygga på deras plattform och dömer därigenom sig själva till att glömmas bort, antingen av girighet eller för att de tror att Groove är en applikation och inte en plattform.
  • och Grooves uppfinnare, Ray Ozzie, har en webblogg så han kan svara mig om han tycker att jag är på fel spår. (Det gjorde han.)

Jag lade märke till Groove-problemet eftersom jag har en produkt, CityDesk, för enkel desktop-baserad webbinnehållshantering. Webbloggar, företagssajter, små organisationer, etc. -- för personer som behöver innehållshantering men inte har råd med de stora systemen, inte har kontroll över en server någonstans eller inte orkar böka med att installera perlskript på en server.

Som alla 1.0-produkter har vi vår beskärda del av svagheter. En av de stora är att människor vill samarbeta på CityDesk-siter över Internet. Ett rimligt önskemål. Till nästa större version måste vi göra något åt denna begränsning. I grund och botten har vi två val. Det traditionella valet vore att göra något client-server-aktigt: skapa en CityDesk-server som man kan installera någonstans så att alla kan samarbeta.

Det andra valet som bättre bibehåller CityDesks fördelar att inte kräva någonting på servern, vore att använda en säker peer-to-peer-arkitektur. Något ganska exakt som vad Groove tillhandahåller.

Så jag funderade på att porta CityDesk till Groove. Sedan noterade jag att:

  1. det finns ingen gratis Groove-runtime. Varenda en av mina kunder vore tvungna att köpa Groove.
  2. ingen har Groove ännu.

Det dömde ut Groove-idén från början. Jag pratade med några av Grooves "partners" som enligt utsago håller på att utveckla programvara för Groove. "Var relationen med Groove värd någonting?" frågade jag. "HA!" sade de. "Vi betalade $1500 och i utbyte fick vi mindre än 10 genomklickningar per månad på deras webbsida. Bortkastade pengar. Vi kunde inte ens få Groove att dela sin kundlista med oss."

Det här är inte en plattform som jag vill utveckla för. Å andra sidan, tekniskt sett så är det exakt den plattform som jag vill utveckla för men den kontrolleras av ett girigt (eller aningslöst) företag som kommer att strypa sin egen syretillförsel -- de attraktiva applikationerna baserade på Groove. Ray Ozzie pratar om det fantastiska med hur coola webbloggar är -- var är webblogg-applikationen för Groove? Vem ska skriva en? Evan Williams, skaparen av Blogger? Till och med Blogger Pro kostar bara $35 per år och det räcker inte så långt för att betala $99 för en enanvändarlicens för Groove.

Vad skulle hända om Grooves runtime var gratis? Ta Windows som exempel. Det startade som en fri runtime som lät dig köra en GUI-applikation i taget. I slutändan köpte många människor den fullständiga versionen för att få fördelarna med Windows filhantering, klipp-och-klistra mellan Windows applikationer osv. Sedan kom Windows 3.0 och var så populär och hade så många applikationer att den kom med varje PC. Idag är Windows som TV-skatten i England. Alla betalar för det utom utvecklaren -- när du skriver mjukvara för Windows så kostar det inte ett öre. Faktum är att under Windows historia har utvecklarna aldrig behövt oroa sig för kostnaden för själva Windows.

Vem som helst som någonsin har försökt att sälja mjukvarukomponenter (ActiveX-kontroller, beans, etc.) vet att man måste ha en gratis runtime. Annars vill ingen utvecklare ta i dig ens med tång. Microsoft låter dig t.o.m. distribuera vidare Jet, en komplett relationsdatabasmotor som är nio tiondelar av Microsoft Access, gratis. Den är till och med förinstallerad på Windows 2000.

Om Groove vill bli en framgångsrik plattform så måste de göra samma sak. En fritt distribuerbar Groove skulle innebära att hundratals applikationer skulle poppa upp och sprida deras runtime vitt och brett. Många av dessa användare skulle inse värdet av att köpa en full version av Groove med inbyggda samarbetsfunktioner. Groove-tjänster som t.ex. hostade reflektorer skulle få en mycket bredare potentiell kundkrets.

De kan förstås göra samma sak som Notes, förutsätta att det enda sättet att sälja mjukvara är att imponera på VD:er med coola Powerpoints och sälja miljondollars-licenser för hyllvara till företag. I slutändan gjorde Lotus en del riktiga pengar på det, för Notes hade en tilltalande applikation -- e-post -- inbyggd. Men tänk er om Notes runtime hade varit fri. Om Notes hade haft en mjukvaruindustri baserad på sig ända tillbaka på 80-talet. Då hade kanske något nystartat i någon högskolekorridor gjort en tilltalande hypertext-applikation för det istället och hunnit före webben. Drömmarna om riktigt stora Notes-nätverk hade kanske blivit verkliga och Notes skulle vara lika vanligt på PC som Patiens. Idag är det bara ännu ett e-post-system, ett utan någon vidare framtid.

Jag fortsätter att hacka på Groove, men det är bara för att det finns något intressant där. En av de få teknologier som är intressant nog att bry sig om. Ja, Groove-ingenjörerna är arkitekturastronauter. Det är OK. De bygger arkitektur. Men de positionerar det som en applikation och jag tror inte att Groove kommer att bli någon framgång om de gör det. Någon annan kommer att kliva fram med en P2P-arkitektur och sälja den som en komponent eller släppa det som open-source-bibliotek (ja, jag är medveten om JXTA) och det är vad mjukvaruutvecklarna kommer att använda.


Originalartikelns engelska titel är Platforms

Personal tools