[fria24] Vilken teknik bör användas ?

[Anders Wallenquist]

Jean-Marc Orliaguet wrote:

>Anders wrote:
>
>  
>
>>Vilken teknik bör användas ?
>>
>>Har skrivit ihop en liten sammanställning av de krav som kommer behöva
>>lösas och ger förslag på hur de löses. Den är inte fullständig utan ett
>>första utkast för att igång diskussionen.
>>
>>
>>http://se.linux.org/arbetsgrupper/fria24/teknikval/
>>
>>
>>Någon som har några åsikter i frågan ? Kanske känner till
>>saker som inte finns medtagna ?
>>
>>
>>Anders
>>    
>>
>
>
>Hej Anders!
>
>Titta på z3lab [1] projeketet.  (z3lab sajten skapades i exakt 2 dagar i Zope/CPS)
>
>I det projektet håller jag på utveckla en WYSIWYG webbeditor i Zope3 som använder sig av AJAX i väldigt stor utsträckning. 
>Kolla också på flash animeringarna.  
>
>hälsningar /JM
>
>[1] http://www.z3lab.org
>[2] http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_17_some-thoughts-about/
>  
>

Väldigt trevligt och spännande, men du missar min poäng. Jag menar att
det är fel att lägga sig på denna nivå när man skall skapa ett brofäste
för en fri 24 plattform, en fri 24 plattform i det långa perspektivet
måste givetvis potentiellt omfatta all FRI programvara  (som uppfyller
kraven på kvalitet, öppna standarder, api-er etc), med betoning på fri
och programvara i betydelsen applikation.

Ett färdigt sjukvårdsadministrativt system byggt i Zope3 tillsammans med
Ajax är säkert ett mycket starkt och konkurrenskraftigt system med
potensial att användas på tusentals sjukhus både inom EU och utanför.

Ponera att det största hindret för att installera det färdiga fria
skoladministrativa systemet, skatteinlämningsystemen,
e-demokratisystemet what-ever är bristen på SHS-integration, så spelar
det ingen roll om SHS-modulen är skriven i C, C++, PHP, Python, Perl,
Ruby så länge du gör motsvarande apt-get install shs på din
favoritplattform och visp så har du din integration med godtycklig fri
applikation biff.

Vi kan sitta på kammaren och utveckla hur vackra system som helst på
Drupal, Zope 2/3/4, Mambo eller vilken plattform som helst, men vi gör
det inte på det sätt som framgångsfull fri programvara uppstår. Fri
programvara är utvecklad av användare för användare. Vi måste därför
sitta i knät på en riktig användare av kött och blod för att detta skall
uppstå.

I teorin kan man komma till en potentiell användare och fråga, vad
önskar du dig mest av allt (inom 24-timmars svären) och den vägen
identifiera bästa pilotprojektet. Vi lyssnar med stora öron och plockar
fram den världsledande lösningen på deras behov genom att översätta det
Brazilianska systemet X från portugisiska till svenska. 

Men det är inte så enkelt, vi måste ha på fötterna och ha en aning om
vad vi kan (och i viss mån vill) leverera. Frågan måste forumleras "Vi
känner till att ni behöver X och vi vill gärna att ni vill bli vårt
pilotprojekt". Med X så vet vi att det är en rimligt enkel funktion vi
kan verkligen kan leverera med frivilliga krafter, integrera på alla
håll och kanter, och som är tillräckligt synlig för att fungera även i
PR-syfte. Med X så vet vi att 24-timmarsfunktionalitet på (helt) fri
plattform kan demonstreras och vara förebild för nästa projekt. Lagom
banbrytande.

Mats Östling använder SugarCRM som role-model i Programverket.org, ett
enkelt hack som gör att *Applikationen* fyller sitt syfte i sitt
sammanhang. En bra demonstration av vad fri programvara kan åstadkomma
utan att kosta stora resurser. Lagom banbrytande men rätt för sina syften.

Skillnaden är om projektet är ett integrationsprojekt (av någon/några
fria programvaror) eller om projektet skall vara ett systemutvecklande
upstream projekt som utvecklar *en* majorapplikation från scratch och
sedan fortvarit i en tioårsperiod. Ja, ni förstår vad jag menar och att
det är det förstnämnda som jag menar är det enda rimliga att göra.

Ett systemintegrationsprojekt är en möjliggörare som skapar öppningar
och förutsättningar för många nya projekt, medan det traditionella fria
systeutvecklingsprojektet uppstår internt hos
myndigheten/kommunen/landstinget och inget som kan komma utifrån.

Alternativet är att istället skriva en skugg IT-strategi med detaljerade
riktlinjer för att inte utesluta användningen av fri programvara och
premiera/tvinga användningen av öppna standarder. Detta skulle vara
nyttigt, men bara nå en begränsad krets beslutsfattare och alldeles för
enkelt att ignorera. Ett slagkraftigt exempel och verklig användning har
potentialen att vara förebild, referensprojekt och inspiratör i många år
framöver.

Om det nu är ärendehanteringssystemet med medborgagränssnitt (som alla
behöver för att uppfylla lagar och förordningar), bokningssystemet eller
vad det nu är, så är mitt inlägg i debatten att Drupal kan vara en bra
utgångspunkt i arbetet att hitta något någorlunda färdigt för ett första
projekt.

* Av "politiska" skäl tycker jag att det vore olyckligt om piloten inte
är helt fri i alla avseenden. Allt ofritt kommer vändas emot oss. - "När
ni, fri programvara förespråkare, skall visa vad den fria världen förmår
måste ni ändå använda ofria komponenter"...

* Argumenten att fri programvara är smalt, svårt att hitta support på,
hitta kompetens på, bara teknikälskande nördars våta drömmar, dyrt att
drifta, dåliga prestanda och vaporware är som vi alla vet bara myter.
Men finns det minsta tendens åt något sådant i piloten kommer även detta
att blåsas upp och vändas emot oss.

* En bra förebild är ett system som uppfyller grundkrav för att kallas
24-timmars-system (men kanske inte mer än nödvändigt), har en stark
befintlig internationell användarförening, använder så många fri
programvarumekanismer som möjligt. Kan återanvändas helt eller delvis i
nya projekt. Får definitivt inte utesluta någon annan fri programvara
(som också uppfyller grundkraven). Ett bra pilotprojekt är
användardrivet och speglar användarens (IT-anvsvarig på
kommun/landsting/myndighet) perspektiv.

* En pilot som aldrig blir färdig och missnöjd kund är mer badwill än
goodwill för hela fri programvaru-rörelsen

/Anders