Re: [ITPOLITIK] Certificeringer (var: proces- og tidsplan for arbejdet med statens it-politik. )

[Esben Jensen <sslug@sslug>]

Jamen jeg er stadig lidt forvirret over om du snakker om kernen (delvist 
styret af Linus) eller om GNU/Linux som samlet OS.

Udviklingen af kernen kan muligvis godt styres, med store mængder 
diplomati og en stak penge. Men jeg tror ikke du som ikke-teknisk 
bruger vil få meget nytte af det. Jeg tror egentlig heller ikke at 
krævende kunder, som f.eks det offentlige vil interessere sig særligt 
meget for kernen isoleret set.

Mozilla og Open Office har jo ingenting med kernen at gøre. De kører 
begge på en lang række forskellige kerner, som f.eks Windows'. Jeg tror 
ikke engang udviklere af disse applikationer vil mærke meget til 
ændringer i hvordan kernen udvikles.



> Jeg mener, at Linus skal være bedre til at styre sine projekter,
> Stallman kan så styre sine.
>
> Jeg så bare gerne, at fx. Linus havde en overordnet målsætning. Og
> jeg så i hvert fald gerne, at andres patches kom med (under
> forudsætning af, at de er relevante). Som det er nu har fx. Raymond
> jo klaget over, at Linus tilsynelandende bare dropper rettelser, hvis
> han ikke har tid eller "whatever".
>
> "I don't care" er en kedelig holdning.

Jeg kender ikke den konkrete situation. Jeg er heller ikke kvalificeret 
til at bedømme kvaliteten af den pågældende patch, selvom jeg havde 
mulighed for at se den.
Men jeg kan godt forstå hvorfor Linus ikke har tid til at argumentere 
for at afslå hver eneste patch han får. Basar modellen er jo netop 
kendetegnet ved at man har råd til at smide ting ud med rund hånd.
Den er også kendetegnet ved at udviklingsuniverset bliver inddelt i små 
kongedømmer, hver med sin enevældige hersker. Så vidt jeg ved fungerer 
udviklingen af kernen på samme måde. Som det blev nævnt før i denne 
tråd, man har ret til sit eget udviklingstræ - ikke andet.
Det er vel en nødvendig måde at organisere sig på i en verden, hvor 
udviklere og mandetimer er en ubegrænset ressource, men hvor styring er 
en begrænset ressource. Så må man vel forholdsvist blindt uddelegere 
autonome kongedømmer og så med tiden se hvor godt de klarer sig.

Som jeg ser det foregår OSS udvikling generelt, som en ustyret 
naturkraft der går i tilfældige retninger med stor fart. Det er 
ineffektivt, men det opvejes i høj grad af at mængden af ressourcer er 
så meget større.


> Jeg så bare gerne, at fx. Linus havde en overordnet målsætning. Og
> jeg så i hvert fald gerne, at andres patches kom med (under
> forudsætning af, at de er relevante). Som det er nu har fx. Raymond
> jo klaget over, at Linus tilsynelandende bare dropper rettelser, hvis
> han ikke har tid eller "whatever".
>
> "I don't care" er en kedelig holdning.

Jo, men sådan er Linus ikke. :)

Da han i '92 udgav Linux v. 0.2 blev han udskældt for at være 
ustruktureret, og han blev bedt om at sammenligne med Hurd. Linus 
svarede at Hurd endnu ikke var en realitet, det var Linux og han gik 
efter noget der kunne bruges her og nu.
I 2003 er Hurd stadig ikke en realitet (Selvom den vist kan boote), men 
Linux har været going strong i en del år. Linus har en meget pragmatisk 
holdning til tingene, det skal virke, og det skal være 'cool'.
Den holdning har vist sig at give succes, jeg tror du skal have endog 
meget gode overtalelsesevner for at få Linus til at droppe den 
indstilling.


> Ja mon ikke. Men som ikke teknikker kan jeg kun bruge Linux på trods
> af alle besværlighederne. Og ved at opgive en række bekvemmeligheder.
> Det gør jeg så på forventet efterbevilling.

Jeg synes udviklingen af GNU/Linux som helhed går hurtigt. Der er stadig 
ting som ikke kører så gnidningsfrit som man kunne ønske, og det vil 
der altid være. På mange områder kører det meget mere gnidningsfrit end 
Windows, på andre områder er der huller. Hullerne vil blive fyldt ud 
med tiden. Kvalitetsmæssigt tror jeg ikke generelt at der vil være 
kommercielle produkter der vil være konkurrencedygtige på lang sigt. 
Men der vil sikkert være nicher hvor de kommercielle løsninger kan 
levere et bedre produkt.


-- 
Esben Jensen