bebraw
2/26/2010 - 9:59 AM
01.diff
=== modified file 'refs.bib'
--- refs.bib 2010-02-12 14:01:25 +0000
+++ refs.bib 2010-02-26 09:47:06 +0000
@@ -16,6 +16,21 @@
keywords = "dblp "
}
+@article{rajlich00,
+ author = {Rajlich, V\'{a}clav T. and Bennett, Keith H.},
+ title = {A Staged Model for the Software Life Cycle},
+ journal = {Computer},
+ volume = {33},
+ number = {7},
+ year = {2000},
+ issn = {0018-9162},
+ pages = {66--71},
+ doi = {http://dx.doi.org/10.1109/2.869374},
+ publisher = {IEEE Computer Society Press},
+ address = {Los Alamitos, CA, USA},
+ }
+
+
@Book{shore07,
author = {Shore, James},
title = {The Art of Agile Development},
@@ -47,7 +62,7 @@
pages = {1--202},
priority = {2},
publisher = {IEEE Press},
- title = {Guide to the Software Engineering Body of Knowledge - SWEBOK},
+ title = {Guide to the Software Engineering Body of Knowledge - {SWEBOK}},
year = {2004}
}
@@ -123,7 +138,7 @@
title = {Computing in the Middle Ages},
publisher = {Authorhouse},
year = {2002},
- address = {City},
+ %address = {City},
isbn = {1403315175}
}
@@ -746,7 +761,7 @@
}
@InProceedings{ stewart04,
- title = "OSS Project Success: From Internal Dynamics to External Impact",
+ title = "{OSS} Project Success: From Internal Dynamics to External Impact",
author = "Katherine J. Stewart",
series = "Proceedings of the 4th Workshop on Open Source Software Engineering ",
booktitle = "Collaboration, Conflict and Control",
@@ -778,7 +793,7 @@
@InProceedings{ crowston04,
author = "Kevin Crowston and Hala Annabi and James Howison and Chengetai Masango",
- title = "Towards a portfolio of FLOSS project success measures",
+ title = "Towards a portfolio of {FLOSS} project success measures",
booktitle = "In Collaboration, Conflict and Control: The 4th Workshop on Open Source Software Engineering, International Conference on Software Enginnering (ICSE 2004",
year = "2004"
}
@@ -791,7 +806,7 @@
}
@InProceedings{ mikkonen06,
- title = "Survey on four OSS com- munities: description, analysis and typology ",
+ title = "Survey on four {OSS} communities: description, analysis and typology ",
booktitle = "Empirical Insights on Open Source Software Business",
author = "Teemu Mikkonen and Niklas Vainio and Tere Vaden",
editor = "Nina Helander and Maria M{\"a}ntym{\"a}ki",
@@ -803,7 +818,7 @@
@InProceedings{ conklin05,
author = "Megan Conklin and James Howison and Kevin Crowston",
- title = "Collaboration using OSSmole: a repository of FLOSS data and analyses",
+ title = "Collaboration using {OSSmole}: a repository of {FLOSS} data and analyses",
booktitle = "MSR '05: Proceedings of the 2005 international workshop on Mining software repositories",
year = "2005",
isbn = "1-59593-123-6",
@@ -825,14 +840,14 @@
@InProceedings{ deshpande08,
year = "2008",
author = "Amit Deshpande and Dirk Riehle",
- title = "The Total Growth of Open Source",
+ title = "The Total Growth of {Open Source}",
booktitle = "Proceedings of the Fourth Conference on Open Source Systems",
pages = "197--209",
publisher = "Springer Verlag"
}
@Electronic{ daffara00,
- title = "Free Software / Open Source: Information Society Opportunities for Europe?",
+ title = "{Free Software / Open Source}: Information Society Opportunities for Europe?",
url = "http://pascal.case.unibz.it/handle/2038/338",
author = "Carlo Daffara and Jesus M Gonz{\'a}lez-Barahona and Edmund Humenberger and Werner Koch and Bernard Lang and Ben Laurie",
year = "2000",
@@ -840,7 +855,7 @@
}
@Article{ gacek04,
- title = "The Many Meanings of Open Source",
+ title = "The Many Meanings of {Open Source}",
author = "Cristina Gacek and Budi Arief",
year = "2004",
month = Jan-Feb,
@@ -854,7 +869,7 @@
@Article{ delone03,
author = "William H. DeLone and Ephraim R. McLean",
- title = "The DeLone and McLean Model of Information Systems Success: A Ten-Year Update",
+ title = "The {DeLone} and {McLean} Model of Information Systems Success: A Ten-Year Update",
journal = "J. Manage. Inf. Syst.",
volume = "19",
number = "4",
=== modified file 'thesis.tex'
--- thesis.tex 2010-02-17 16:42:58 +0000
+++ thesis.tex 2010-02-26 09:47:36 +0000
@@ -7,6 +7,7 @@
\usepackage{url}
\usepackage{array}
+\usepackage{lscape}
\newcolumntype{x}[1]{%
>{\centering\hspace{0pt}}p{#1}}%
@@ -17,7 +18,7 @@
%\usepackage{natbib}
-\title{VALO-ohjelmistojen menestys}
+\title{Vapaiden ja avoimen lähdekoodin ohjelmistojen menestys}
\translatedtitle{The Success of FLOSS Projects}
\setauthor{Juho}{Vepsäläinen}
@@ -28,8 +29,8 @@
\tiivistelma{TODO}
\abstract{TODO}
-\avainsanat{tietotekniikka, gradu, avoin lähdekoodi, vapaaohjelmistot, FLOSS, FOSS, menestys, VALO}
-\keywords{information technology, Master's thesis, open source, free software, FLOSS, FOSS, success}
+\avainsanat{tietotekniikka, avoin lähdekoodi, vapaaohjelmistot, FLOSS, FOSS, menestys, VALO}
+\keywords{information technology, open source, free software, FLOSS, FOSS, success}
\tyyppi{pro gradu -tutkielma}
@@ -43,40 +44,35 @@
\chapter{Johdanto}
-karkea versio (ydinajatukset):
-
-Tutkimuksen johtoajatus:
--Projektin menestys määrittyy sen merkittävyyden kautta. -> eli tutkaillaan menestystä merkittävyyden näkökulmasta (miten määritellä merkittävyys? -> projektin vaikutus ympäristöön. esim. linux ja apache ovat tunnettuja (mullistivat omalla tavallaan sovellusalueensa). BIND ja sendmail aiempia, vähemmän tunnettuja esimerkkejä (merkittävyys suhteessa internetin infran kehitykseen, ei niinkään julkiseen käyttöön!)
-
-Karkeasti ottaen tarkoitus on koota paketti, jonka lukemalla lukija ymmärtää paremmin mistä VALO-ohjelmistoissa oikein on kyse (käsitteistö, historia) ja pystyy mahd. tekemään kontribuutioita nykyisiin projekteihin tai perustamaan oman (projektien ja niiden menestyksen pohdinta antaa eväät tähän). Tämän voisi kuitenkin nähdä toissijaisena tavoitteena, joka seuraa tarkastelusta liki automaattisesti.
-
-Termeistä:
-\begin{itemize}
-\item VALO-ohjelmisto == FLOSS/FOSS, yleinen termi, joka kattaa seuraavat
-\item vapaa ohjelmisto == Free Software - FSF:n määritelmän mukaisesti!
-\item avoimen lähdekoodin ohjelmisto == Open Source Software - OSI:n määritelmän mukaisesti! (sisältää vapaat ohjelmistot enimmäkseen (joitain poikkeuksia saattaa löytyä))
-\item kts. myös termistöliite
-\end{itemize}
-
-Rakenteesta:
-\begin{itemize}
-\item Ohjelmistot - Mikä on ohjelmisto? (lähtökohta tulevalle tarkastelulle, määr. myös vapaaohjelmiston)
-\item Historia - VALO-ohjelmistojen tausta (olennainen käsitteen ymmärtämisen kannalta)
-\item Immateriaalioikeudet - Viittaa ed. lukuihin ja esittelee immateriaalioikeudet (tekijänoikeus, patentit, ym.)
-\item Vakiintuneet projektit - Käy läpi jo asemansa vakiinnuttaneita projekteja (auttaa ymmärtämään miksi nämä ovat merkityksellisiä ja miten niistä on tullut sellaisia)
-\item Ympäristö - Projektien ympäristö, ekosysteemi laajemmassa mittakaavassa, pohjustaa projektilukua
-\item Projektit - Ohjelmistotuotannosta tarkemmin, miten ohjelmisto rakentuu (periaatteessa pätee yleisesti mutta perehdyn asiaan nimenomaan VALO-ohjelmistojen kautta)
-\item Yhteisöt - Yhteisön merkitys ja osat (tarkastellaan kokonaisuutta sekä kehittäjiä että käyttäjiä erikseen). Erottelin tämän omaksi luvukseen, koska yhteisöt ja projektit eivät mappaudu 1-1 vaan nähdäkseni käyttäjät/kehittäjät voivat liikkua projektien välillä ja kuulua laajempiin yhteisöihin (metayhteisöt)
-\item Menestys - Menestys mittarina suhteessa projekteihin
-\item Menestysmalli (tarvitaanko?) - Omia havaintoja, synteesi edelliseen pohjautuen (ajatuksena on, että malli huomioi vapaaohjelmistojen asettamat vaatimukset toisin kuin esim. McLean IS-malli)
-\item Yhteenveto - olennaisimmat huomiot, jatkotutkimus
-\end{itemize}
-
-Eli rakenne on pyramidimainen "yleisestä yksityiseen". Lähtökohtana aksioomat, joiden varaan rakennan lopun tarkastelun.
-
-Hakkereista oli alun perin oma lukunsa, mutta sisällyttänen sen olennaiset huomiot historiaan ja projekteihin. Hakkeri terminä on hieman ongelmallinen ottaen huomioon sen negatiiviset merkitykset (kiitos 80-90-lukujen median (vrt. krakkeri vs. hakkeri!)). Hakkerikulttuurista saa lähinnä irti periaatteet, joita voi sitten verrata nykyiseen menoon (kts. Levy). Levyn ajatus hakkerista voidaan nähdä FSF:n ideaalina (idealistinen näkemys). OSI:n myötä (ja jo aiemmin, kts. KDE-projekti) pragmaatikot saivat oman tunnuksensa. OSI:a voisi tässä mielessä kohdella idealismina vaikka se voidaan nähdä myös metodologiana (Linux-kehitys OS-metodologian protona).
-
-\chapter{Ohjelmistot}
+% Johtoajatus: Vaikuttavien (tai menestyneiden) OSS-projektien karakterisointi ja niiden menestyksen kannalta oleellisten ominaispiirteiden systemaattinen esiintuonti, analysointi ja luokittelu (tieteelliseen yms. kirjallisuuteen perustuen).
+
+Vapaiden ja avoimen lähdekoodin ohjelmistojen voidaan nähdä mullistaneen ohjelmistoteollisuuden. Erityisesti Linuxin johdattamana ne ovat nousseet merkittävään asemaan ja muodostavatkin tärkeän lenkin useiden suuryritysten strategian osana. Tämä murros on tehnyt näkemyksen koodin sulkemisen mielekkyydestä kyseenalaiseksi. Hieman paradoksaalisesti koodin vapaus mahdollistaa keskenään kilpailevien yritysten välisen yhteistyön ja täten vahvistaa niiden asemaa kilpailijoitaan vastaan.
+
+Kysymys kuuluukin, miksi näin on käynyt? Mikä on tehnyt vapaista ja avoimen lähdekoodin ohjelmistoista varteenotettavan vaihtoehdon suljetuille vastineilleen? Tarkemmin ottaen, mikä on saanut ne menestymään? Tässä tutkielmassa tarkastelen näitä seikkoja ja pyrin luomaan viitekehyksen, jonka puitteissa arvioida jo olemassa olevia projekteja ja toisaalta kehittää uusia. Seuraavaksi määrittelen vapaiden ja avoimen lähdekoodin ohjelmistojen termin, jota laajennan edelleen vielä myöhemmin.
+
+Vapaaohjelmistot haastavat vakiintunutta tapaa ajatella tekijänoikeutta ja itse asiassa käyttävät tekijänoikeuslakia sitä itseään vastaan. Olennaisesti vapaaohjelmistot pohjautuvat ajatukseen siitä, että niiden vapaus voidaan säilyttää vain jos ne ovat kenen tahansa edelleen muokattavissa. Tarkennettuna tämä tarkoittaa sitä, että mikäli vapaaohjelmistoa jaetaan julkisesti, tulee sen lähdekoodin olla pyydettäessä saatavilla. Kenties hieman ironisesti luopumalla tästä pienestä vapaudesta, vapaudesta olla jakamatta lähdekoodia, ohjelmistoa voidaan pitää todellakin vapaana.
+
+Avoimen lähdekoodin ohjelmistojen määritelmä sisältää myös vapaaohjelmistot, mutta toisaalta se sallii myös lähdekoodin jakamattomuuden tietyin ehdoin. Puhekielessä avoimen lähdekoodin ohjelmistoja voidaan pitää siis yleisnimityksenä sekä vapaille että avoimen lähdekoodin ohjelmistoille. Käytännössä tämä on kuitenkin hieman epätarkasti sanottu, koska termit sisältävät myös ideologisen merkityksen. Avoimen lähdekoodin liikettä voidaan pitää hyvin pragmaattisena vapaaohjelmistojen liikkeen ollessa hyvin ohjelmistovapauden ideologialle uskollisena.
+
+Välttääkseni tämän ideologisen kannanoton viittaan tässä tutkielmassa sekä vapaisiin että avoimen lähdekoodin ohjelmistoihin käyttäen lyhennettä VALO\footnote{Vapaan ja Avoimen Lähdekoodin Ohjelmistot. Kyseinen termi on englanninkielisten alkuperäistermien FOSS ja FLOSS vastine. Kts. liite \ref{sec:termisto}.}.
+
+Olen jakanut tutkielman lukuihin seuraavasti:
+\begin{itemize}
+\item Ohjelmistot käsitteenä - Mikä on ohjelmisto? Miten luokitella niitä? Mikä on niiden yhteys kaupallisuuteen?
+\item VALO-ohjelmistojen historian askelmalli - VALO-ohjelmistoihin johtanut historia ja sen osat
+\item Immateriaalioikeudet - Immateriaalioikeuksien (tekijänoikeus, patentit, lisenssointi) lyhyt historia ja niiden suhde VALO-ohjelmistoihin.
+\item VALO-projektien ympäristö - Millaisessa ympäristössä VALO-projektit toimivat? Mikä on niiden suhde toisiinsa?
+\item VALO-yhteisöt ja yksilöt - Kuka niitä projekteja oikein kehittää? Millaisia yhteisöjä VALO-projektien toimintaan osallistuvat muodostavat?
+\item VALO-projektit - VALO-projektin anatomia. Mistä projekti koostuu ja miten se kehittyy?
+\item VALO-menestystarinoita - Esimerkkejä menestyneistä VALO-projekteista. Mikä on tehnyt juuri näistä projekteista menestyksekkäitä?
+\item Menestys - Mitä menestys on? Kuinka mitata menestystä?
+\item VALO-menestysmalli - Omia havaintoja, synteesi edelliseen pohjautuen (ajatuksena on, että malli huomioi vapaaohjelmistojen asettamat vaatimukset toisin kuin esim. McLean IS-malli)
+\item Yhteenveto - Olennaisimmat huomiot, jatkotutkimusideoita.
+\end{itemize}
+
+%Ajatuksena on, että kukin luku tarkastelee VALO-ilmiötä hieman eri näkökantilta alkaen aina ilmiön taustoista päätyen aina menestykseen asti. sopiva siirtymä ohjelmistoihin käsitteenä...
+
+\chapter{Ohjelmistot käsitteenä}
Karkeasti ottaen ohjelmisto mahdollistaa laitteiston hyödyntämisen halutulla tavalla. Tämä määritelmä on kuitenkin hieman epätarkka. Se ei kykene ottamaan selvästi kantaa esimerkiksi seuraaviin kysymyksiin: Mitä jos ohjelmisto on määritelty laitteiston tasolla? Koska äänitteen toistaminen aiheuttaa laitteiston toistamaan ääniä onko myös se ohjelma?
@@ -101,6 +97,8 @@
\section{Ohjelmistojen kaupallisuus}
+% XXX: muuta käyttämään VALO-käsitettä suoraan
+
\begin{figure}[!ht]
\centering
\includegraphics[width=80mm]{kuvat/floss_four.png}
@@ -118,7 +116,7 @@
COSS (Commercial Open Source Software) (OSS + suljettuja komponentteja (esim. patentoituja osia) paketoituna yhteen). Tässä voisi viitata esim. kaupallisiin Linux-jakeluihin (mainitse IP:n sovittamisesta OS-arvomaailmaan. vrt. esim. DeCSS ja DMCA Yhdysvalloissa ym. patenttihäkkyrät!).
-\chapter{Historia}
+\chapter{VALO-ohjelmistojen historian askelmalli}
asian ydin pähkinänkuoressa (vrt. nykykulttuuri) (pitänee jättää pois lop. versiosta). pointtina quotessa on lähinnä se, että FLOSS kapseloi ajatuksen aika totaalisesti. ehkä se voidaan nähdä siis jonkinmoisena luonnollisena seurauksena (periaatteessa sen voisi ajaa ahdinkoon ankaralla lainsäädännöllä, mutta kuitenkin...)
\begin{quotation}``Totuuden tutkimus on nimittäin niin välttämätöntä ja mittavaa, että siinä täytyy useiden tuhansien ihmisten työ saada yhteen. Ja maailmassa on niin vähän ihmisiä, jotka ryhtyvät siihen harkiten, että he joutuvat sitäkin enemmän tukemaan toisiaan ja auttamaan toisiaan jakamalla havaintonsa ja ajatuksensa keskenään. Omasta puolestani tarjoan tätä teille kaikin puolin lämpimästi.'' -- René Descartes 1640 T1, 340\end{quotation}
@@ -157,23 +155,23 @@
1940-luvun alkua leimasi erityisesti 2. maailmansota. Sen voidaan nähdä antaneen lähtölaukauksen modernin tietokoneen kehitykselle. Alan Turingin johdolla Ison-Britannian Bletchley Parkissa tehty työ loi perustan nykyaikaiselle tietokoneelle. Turingin työn kimmokkeena voidaan pitää akselivaltojen viestinnässä hyödyntämää Enigma-salauslaitetta, jonka salauksen purkamiseen vaadittiin merkittävä määrä laskentatehoa \cite{gere08}.
-Ensimmäiset kehitetyt koneet hyödynsivät tiedon syöttöön paperia. Ratkaisu osoittautui kuitenkin riittämättömäksi ja johti johti koneen sisäiseen, elektroniseen muistiin. Työn tuloksena Manchester Mk 1, kenties maailman ensimmäinen digitaalinen tietokone \cite{gere08}. Manchesteria seurasi suorituskykyisempi, yhdysvaltalainen ENIAC. Sen tarjoama toiminnallisuus oli määritelty pitkälti rautatasolla. Se tarjosi ohjelmoitavuutta vipujen ja erityisten pistotulppalevyjen muodossa \cite{ornstein02}.
-
-Vaikka Yhdysvaltain puolustusvoimat painottikin puhtaan laskennan merkitystä, kone oli suunniteltu yleisempiä ongelmia silmällä pitäen. Seuraava projekti, EDVAC, vei ajatuksen askeleen pidemmälle. EDVAC hylkäsi kymmenjärjestelmän käytön koneen lukujen sisäisenä esitysmuotona ja korvasi sen binääripohjaisella (1 ja 0) järjestelmällä. Tämä yksinkertaisti koneen toteutusta huomattavasti. Toinen merkittävä muutos oli itse ohjelman säilyttäminen suoraan koneen muistissa sen sijaan, että se tulisi syöttää ulkoisesti. \cite{ornstein02}
-
-VALO-ohjelmistojen kannalta erityistä toisen maailmansodan aikana tehdyssä kehitystyössä oli se, että se pakotti eri alojen tiedemiehet yhteistyöhön. Aiemmin eri tieteenalojen toimijat toimivat käytännössä eristyksessä toisistaan. Selkein esimerkki tämän lähestymistavan menestyksestä oli Manhattan-projekti, joka yhdisti eri alojen ja valtion osaamista tehokkaasti. \cite{benussi06}
+Ensimmäiset kehitetyt koneet hyödynsivät tiedon syöttöön paperia. Ratkaisu osoittautui kuitenkin riittämättömäksi ja johti johti koneen sisäiseen, elektroniseen muistiin. Työn tuloksena syntyi Manchester Mark 1, kenties maailman ensimmäinen digitaalinen tietokone \cite{gere08}. Manchesteria seurasi suorituskykyisempi, yhdysvaltalainen ENIAC. Sen tarjoama toiminnallisuus oli määritelty pitkälti laitteistotasolla. Se tarjosi ohjelmoitavuutta vipujen ja erityisten pistotulppalevyjen muodossa \cite{ornstein02}.
+
+Vaikka Yhdysvaltain puolustusvoimat painottikin puhtaan laskennan merkitystä, kone oli suunniteltu yleisempiä ongelmia silmällä pitäen. Seuraava projekti, EDVAC, vei ajatuksen askeleen pidemmälle. EDVAC hylkäsi kymmenlukujärjestelmän käytön koneen lukujen sisäisenä esitysmuotona ja korvasi sen binääripohjaisella (1 ja 0) järjestelmällä. Tämä yksinkertaisti koneen toteutusta huomattavasti. Toinen merkittävä muutos oli itse ohjelman säilyttäminen suoraan koneen muistissa sen sijaan, että se tulisi syöttää ulkoisesti. \cite{ornstein02}
+
+Toisen maailmansodan aikana tehty kehitystyö pakotti eri alojen tiedemiehet yhteistyöhön. Aiemmin eri tieteenalojen toimijat toimivat käytännössä eristyksessä toisistaan. Selkein esimerkki tämän lähestymistavan menestyksestä oli Manhattan-projekti, joka yhdisti eri alojen ja valtion osaamista tehokkaasti. Tätä voidaan pitää analogisena VALO-projektien tapaan järjestäytyä. Myös ne yhdistävät eri alojen osaamista. \cite{benussi06}
Yhteistyön merkityksen havaitseminen johti uuteen ongelmaan: kuinka kommunikoida ja jakaa tietoa tehokkaasti? Tämä ongelma johti viestintäteknologian kehitykseen. Toisaalta toista maailmasotaa seuranneeen kylmän sodan ilmapiiri johti pohdintoihin siitä, kuinka hajauttaa laskentateho puolustuksen kannalta hyvin. \cite{benussi06}
Sodan jälkeinen tietotekniikan kehitys painottui erityisesti Yhdysvaltoihin. Kylmän sodan aikaisen kilpavarustelun voidaan nähdä vauhdittaneen sitä. Yhdysvallat joutui tukalan tilanteen eteen erityisesti sen jälkeen, kun Neuvostoliitto onnistui laukaisemaan Sputnik-satelliitteja kiertoradalle vuonna 1957. \cite{hafner96}
-\subsection{ARPAnet}
+\section{ARPAnet}
Sputnik aiheutti pelonväristyksia Yhdysvaltain johdossa. Yhdysvaltojen tieteellinen ja teknologinen johto oli selvästi uhattuna. Yhdysvaltain hallinto joutui harkitsemaan tieteen asemaa uudelleen. Toisen maailmansodan aikainen tieteen ja valtion hedelmällinen yhteistyö oli yhä tuoreessa muistissa. \cite{hafner96}
Jo ennen Sputnikia hallinnossa oli käyty keskusteluja erityisen tieteeseen keskittyvän viraston perustamisesta. Perinteisesti eri puolustusvoimain lohkot kilpailivat samoista voimavaroista keskenään. Viraston tarkoitus oli vähentää tätä kilpailua ja koordinoida kehitystä paremmin. Vaikka puolustusvoimat vastustikin ajatusta aluksi vastarinta saatiin kukistettua. Piakkoin vuoden 1958 alussa perustettiin ARPA. \cite{hafner96}
-ARPA aloitti toimintansa varsin anteliaalla budjetilla (2 miljardia tuolloista dollaria), joka kuitenkin koki kolauksen vuonna 1959, kun NASA\footnote{National Aeronautics and Space Administration} perustettiin. NASA vei suuren osan ARPA:n tehtävistä sen keskittyessä avaruus- ja ohjustutkimukseen. Seurauksena ARPA:n budjetti tippui 150 miljoonaan dollariin ja sen tulevaisuus oli uhattuna. \cite{hafner96}
+ARPA aloitti toimintansa varsin anteliaalla budjetilla (2 miljardia tuolloista dollaria), joka kuitenkin koki kolauksen vuonna 1959, kun NASA\footnote{National Aeronautics and Space Administration} perustettiin. NASA vei suuren osan ARPA:n tehtävistä NASA:n keskittyessä avaruus- ja ohjustutkimukseen. Seurauksena ARPA:n budjetti putosi 150 miljoonaan dollariin ja sen tulevaisuus oli uhattuna. \cite{hafner96}
Budjetin leikkauksen seurauksena ARPA:n tuolloinen päällikkö sanoutui irti toimestaan. Ennen lähtöään hän oli kuitenkin jo hahmotellut ARPA:n mahdollista tulevaisuutta. Tämän hahmotelman perusteella ARPA:n analyytikot päättivät määritellä ARPA:n tehtävän uudelleen. He havaitsivat, että aiemmin tutkimus oli painottunut lyhyellä aikavälillä tuottaviin projekteihin ja miellyttäviin alihankkijasuhteisiin. Oli siis selvää, että virasto voisi keskittyä pitkän aikavälin perustutkimukseen, jonka tuloksista ei ole mitään takeita, mutta joka onnistuessaan voi tuoda muassaan merkittäviä edistysaskeleita. \cite{hafner96}
@@ -201,7 +199,7 @@
OSS-yhteisön prototyyppi! postilistat, RFC (epäformaali tapa koostaa protokollia),
-1978, Donald Knuth (Stanford) julkaisee TEX:n vapaana ohjelmistona.
+1978, Donald Knuth (Stanford) julkaisee TeX:n vapaana ohjelmistona.
1979 Eric Allmann, UC Berkeleyn opiskelija, kehitti ohjelman, joka reitittää viestejä tietokoneiden välillä hyödyntäen ARPANETia. Myöhemmin tästä ohjelmasta muodostuu Sendmail.
\section{MIT, projekti MAC ja CTSS}
@@ -244,12 +242,12 @@
huom! GPL ei sinänsä ole kaupallisuutta vastaan (vrt. Linuxin menestys kaupallisessa ympäristössä!). Kaupallisuuden kannalta pointtina on lähinnä se, että arvo syntyy palvelusta/paketoinnista. Lähdekoodin saatavuus mahdollistaa kilpailijoiden väliset välilliset liittoumat (kaikki hyötyvät, kun jaettu koodikanta pysyy kunnossa. samalla vältetään turhaa työtä, kun kaikkea ei tarvitse keksiä itse uudelleen). Pointtina myös luovien yhdistelmien kehittäminen ja tällä tavoin uuden lisäarvon tuottaminen (toki joku muu voi käyttää ja myydä samaa tuotetta, mutta esim. brändi voidaan suojata (trademark) ja toisaalta esim. tukea on hankalaa replikoida.)
-GNU määrittelee \textbf{vapaan ohjelmiston} seuraavasti:
+GNU määrittelee \textbf{vapaan ohjelmiston} seuraavasti \footnote{Määritelmä kokonaisuudessaan löytyy osoitteesta \url{http://www.gnu.org/philosophy/free-sw.html}.}:
\label{vapaamaaritelma}
\begin{itemize}
\item Vapaus ajaa ohjelma käyttötarkoitusta rajaamatta (vapaus 0).
\item Vapaus tutkia, kuinka ohjelmisto toimii ja soveltaa sitä omiin käyttötarkoituksiin (vapaus 1). Pääsy lähdekoodiin on tämän esiehto.
- \item Vapaus jakaa kopioita, jotta voit auttaa naapuriasi (vapaus 2).
+ \item Vapaus jakaa kopioita, jotta voit auttaa lähimmäistäsi (vapaus 2).
\item Vapaus parantaa ohjelmistoa ja julkaista parannukset yleisesti saataville, jotta koko yhteisö hyötyy niistä (vapaus 3). Pääsy lähdekoodiin on tämän esiehto.
\end{itemize}
@@ -401,40 +399,7 @@
IP:n käsite
-\chapter{Aikaiset projektit}
-
-\section{BIND}
-
-\section{Sendmail}
-
-\section{LaTeX}
-
-\section{Apache}
-
-\section{Mozilla Firefox}
-
-\section{Linux}
-
-\cite{moody01} \cite{raymond01}
-
-Linusin laki.
-
-\begin{itemize}
-\item 1987, Andrew Tanenbaum julkaisee Minixin. Minix on UNIX-versio, joka on tarkoitettu PC, Mac, Amiga sekä Atari ST alustoille. Sen mukana tulee myös lähdekoodi.
-\item 1991, Linus Torvalds julkaisee 0.02 version uudesta UNIX-variantista. Hän kutsuu versiota Linuxiksi Minix-uutisryhmässä.
-\item 1993, FreeBSD 1.0 julkaistaan. FreeBSD pohjautuu BSD UNIXiin ja se sisältää verkkotoiminnallisuutta sekä tuen virtuaalimuistille, suorituksen vaihdolle (task switching) sekä suurille tiedostonimille.
-\item 1993, Ian Murdock luo Debian Linux-jakeluversion.
-\item 1994, Marc Ewing muodostaa Red Hat Linuxin. Red Hatista tulee nopeasti johtava Linux-jakeluversio.
-\item 1994, Bryan Sparks perustaa Calderan entisen Novellin CEO:n Ray Noordan tuella.
-\item 1995, Apache ryhmittymä (Apache Group) kehittää uuden web-palvelimen, Apachen. Se pohjautuu NCSA:n (National Center for Supercomputing Applications) HTTPd 1.3:een ja kokoelmaan korjaustiedostoja (patch). Apache on nykyään johtava HTTP-palvelinohjelmisto.
-\item 1998, Merkittävät ohjelmistojen tuottajat, mm. Computer Associates, Corel, IBM, Informix, Interbase, Oracle sekä Sybase, ilmoittavat suunnitelmistaan portata ohjelmistojaan Linuxille. Sun ilmoittaa suunnitelmistaan julkaista Java 2:n lähdekoodi kehittäjille.
-\item 1999, Linuxin käyttäjien määräksi arvioidaan 7.5 miljoonaa.
-\item 2000, Yhä useammat ohjelmistojen tuottajat, kuten Novell ja Real, julkaisevat ohjelmistoistaan versioita, jotka toimivat Linuxilla.
-\end{itemize}
-
-olennaisia pointteja: Minix olisi voinut olla Linux, jos Tanenbaum olisi ollut kehityksen suhteen avoimempi (Linusin "innovaatio"). Vrt. myös OpenBSD (kaatui laitevaatimuksiin?) ja Hurd (kaatui kompleksisuuteen?). Olennaista huomata, myös kuinka Linux-organisaatio kehittyi (Linus ei skaalaudu! -> rakenne skaalautuu (jaettu vastuu)). Distribuutiot (Debian, Red Hat ym.). Ubuntun nousu (ubuntuismi terminä? chege, Ubuntuism, Commodification, and the Software Dialectic.). Menestys mobiili/serveripuolella. KDE vs. GNOME. monoliittisyys vs. monimuotoisuus (kernel, ikkunointijärjestelmät, standardit)
-
-\chapter{Ympäristö}
+\chapter{VALO-projektien ympäristö}
Kunkin projektin asema määrittyy suhteessa sen ympäristöön. Ensinnäkin projekti asettuu tiettyyn kohtaan ohjelmistojen hierarkiassa. Se voi keskittyä järjestelmätoiminnallisuuteen (esim. Linux-kernel), toimia alustana (esim. ohjelmointikielet ja kirjastot) tai olla varsinainen sovellus. Projektin ohjelmiston ollessa alusta tai sovellus joutuu se ottamaan kantaa siihen, millä järjestelmillä sitä voidaan käyttää. Sovelluksen tapauksessa sopivilla alustavalinnoilla voidaan taata, että sovellus toimii laajalla kirjolla eri järjestelmiä.
@@ -466,7 +431,71 @@
\section{Evoluutio}
-\chapter{Projektit}
+\chapter{VALO-yhteisöt ja yksilöt}
+
+\begin{figure}[!ht]
+ \centering
+ \includegraphics[width=75mm]{kuvat/sturmer.png}
+ \caption{A Very Abstract Picture of an Open Source Project \cite{stuermer05}}
+\label{fig:stuermer}
+\end{figure}
+
+Periaatteessa jo vain yhden hengen projekti muodostaa oman mikroyhteisönsä. Kun projekti saavuttaa näkyvyyttä, sen yhteisö myös kasvaa. Kuten Senyardin ja Michlmayrin \cite{senyard04} mallista näimme, kaikki projektit lähtevät liikkeelle katedraalimaisina...
+
+yhteisön jako rooleihin!
+
+- huomaa kehittäjien ja käyttäjien duaalinen rooli + roolin vaihtelevuus. kts. \ref{fig:gacek}
+
+\begin{figure}[!ht]
+ \centering
+ \includegraphics[width=75mm]{kuvat/udclassification.png}
+ \caption{A Classification of Open Source Users and Developers \cite{gacek04}}
+\label{fig:gacek}
+\end{figure}
+
+Goldman and Gabriel \cite{goldman05} note that it is usual for people to come up with code centric view on project structure. Nakakoji et al. \cite{nakakoji02} have developed one fitting this description. Goldman and Gabriel highlight the importance of designers and separate it as a group of its own. Their main observation is that there is more to a project than just the code.
+
+It is also important to remember the connections between separate open source projects \cite{goldman05}. As mentioned earlier it is natural for an open source project to make use of existing work. Therefore when studying some specific project it does make sense to look at the whole to understand what kind of an effect the environment has on the project.
+
+\section{Rakenne}
+
+\begin{figure}[!ht]
+ \centering
+ \includegraphics[width=100mm]{kuvat/nakakoji.png}
+ \caption{VALO-yhteisön yleinen rakenne \cite{nakakoji02}}
+\label{fig:nakakoji}
+\end{figure}
+
+Huom! myös sturmer esittää suunnilleen vastaavan mallin joskin hieman yleisemmällä tasolla
+
+tehokäyttäjät (pätsit ym.) merkitys! (lead user? power user)
+
+\cite{michlmayr07} s.17 viite howisonin malliin (sipuli kuten muutkin), \cite{khatib06} s. 27, \cite{robles06} (huom! GIMP mukana), \cite{mikkonen06} typologia -> volunteer, mixed, company, \cite{howison05} -> organisaationelikenttä
+
+Stürmer \cite{stuermer05} has provided an abstract model \ref{fig:stuermer} showing the main aspects of the structure of an open source project. The important thing to note is that the distance between a user and a developer can be almost negligible depending on a project. There is no a concrete role of a user or a developer in the most concrete sense.
+
+\section{Kehittäjät}
+
+kehittäjä sanan laajassa merkityksessä (myös ideoija, kääntäjä, graafikko tai dokumentaation laatija lasketaan)
+
+\subsection{Motivaatio}
+\cite{hars01}, \cite{maxwell06}, \cite{khatib06} s. 35-37, \cite{krishna02} -> BCG, \cite{lerner05}
+
+\subsection{Evoluutio}
+
+\subsection{Kaupallisuus}
+(esim. Linux (suuri osa kehittäjistä kaupallisia!))
+
+\section{Käyttäjät}
+michlmayr07!
+
+\subsection{Motivaatio}
+
+\subsection{Evoluutio}
+
+\subsection{Kaupallisuus}
+
+\chapter{VALO-projektit}
Raymondia \cite{raymond01} mukaillen ``Kukin hyvä ohjelmistoprojekti lähtee liikkeelle omasta tarpeesta.''\footnote{Alkup. Every good work of software starts by scratching a developer's personal itch.}. Esimerkiksi GNU-projekti ja Linux ovat hyviä esimerkkejä tästä. Fogel \cite{fogel05} huomauttaa, että tämä pätee myös organisaatioiden tasolla.
@@ -552,7 +581,7 @@
\end{tabular}
\end{table}
-Kuten taulukosta \ref{organisaatiotyypit} voi havaita, voi VALO-projektien organisaatio vaihdella hyvinkin paljon. Howison \cite{howison05} jakoi organisaatiot nelikenttään niiden hajautuneisuuden sekä vapaaehtoisuuden välillä. Jaottelu on varsin karkea, mutta antaa hyvän kuvan siitä, millaiset organisaatiot ovat mahdollisia. Mainittujen tyyppien lisäksi on mahdollista, että projekti yhdistelee useampia, ellei jopa kaikkia, tyyppejä samanaikaisesti.
+Kuten kuvasta \ref{organisaatiotyypit} voi havaita, voi VALO-projektien organisaatio vaihdella hyvinkin paljon. Howison \cite{howison05} jakoi organisaatiot nelikenttään niiden hajautuneisuuden sekä vapaaehtoisuuden välillä. Jaottelu on varsin karkea, mutta antaa hyvän kuvan siitä, millaiset organisaatiot ovat mahdollisia. Mainittujen tyyppien lisäksi on mahdollista, että projekti yhdistelee useampia, ellei jopa kaikkia, tyyppejä samanaikaisesti.
Tyyppi vaihtelee tilanteen mukaan. Esimerkiksi nelikentässään Howisonin \cite{howison05} mainitsemat sprintit ja 'hackathonit' ovat hyvä esimerkki tällaisesta. Toisinaan hajautettu projektitiimi voi kokoontua samaan paikkaan lyhyen kehitysorientoituneen session ajaksi. Tällainen sprint voi olla esimerkiksi muutaman päivän tai viikon mittainen. Olennaista tämän kaltaisessa kehitystavassa on se, että tällöin voidaan ratkoa tehokkaasti erityisen haastavia ongelmia, joiden ratkaisu olisi muulloin vaikeaa eri kommunikointiväylien puutteiden ja ajan vähyyden vuoksi. Toisaalta sprint voi rakentaa tiimihenkeä.
@@ -571,11 +600,13 @@
\begin{quotation}``In the long run every program becomes rococo - then rubble. (käännä!)'' -- "Epigrams in Programming", Alan J. Perlis (lisää tarkka viite!)\end{quotation}
-IEEE:n elinkaarimalli (A staged model for the software life cycle, rajlich00)
+IEEE:n elinkaarimalli (A staged model for the software life cycle, \cite{rajlich00})
+%\begin{center}
+\begin{landscape}
\begin{table}[h!b!p!]
\caption{VALO-projektien tyyppejä \cite{nakakoji02}}
-\begin{tabular}{| p{2.4cm} | p{1.8cm} | p{1.8cm} | p{2cm} | p{2.2cm} | p{2.0cm} | p{2.1cm} | }
+\begin{tabular}{| p{2.4cm} | p{2.8cm} | p{1.8cm} | p{2.8cm} | p{4.2cm} | p{3cm} | p{2.5cm} | }
\hline
Tyyppi & Tarkoitus & Kontrollin tyyppi & Evoluutio\-malli & Yhteisön rakenne & Suurimmat ongelmat & Esimerkkejä \\
\hline
@@ -590,6 +621,10 @@
\end{tabular}
\label{nakakoji_table}
\end{table}
+\end{landscape}
+%\end{center}
+
+huom! laajensin yo. mallia Blenderillä oman kokemuksen perusteella (esimerkki tapauksesta, jossa lähti hyötyorientaatiosta ja päätyi projektiorientaatioon.)
liittyy senyard et al. malliin! -> fysiikan tilasiirtymät + hystereesi
@@ -597,7 +632,7 @@
\section{Evoluutio}
-e-tyypin-projekti. kts. godfrey-tu (linux), fernandez-ramil et al.
+e-tyypin-projekti. kts. godfrey-tu (Linux), fernandez-ramil et al.
\section{Markkinointi}
@@ -609,69 +644,38 @@
kaupallisuus osa kehitystä (kehitystyön rahoittaminen, luotu kysyntä! -> tuki (kirjat ym.))
-\chapter{Yhteisöt}
-
-\begin{figure}[!ht]
- \centering
- \includegraphics[width=75mm]{kuvat/sturmer.png}
- \caption{A Very Abstract Picture of an Open Source Project \cite{stuermer05}}
-\label{fig:stuermer}
-\end{figure}
-
-Periaatteessa jo vain yhden hengen projekti muodostaa oman mikroyhteisönsä. Kun projekti saavuttaa näkyvyyttä, sen yhteisö myös kasvaa. Kuten Senyardin ja Michlmayrin \cite{senyard04} mallista näimme, kaikki projektit lähtevät liikkeelle katedraalimaisina...
-
-yhteisön jako rooleihin!
-
-- huomaa kehittäjien ja käyttäjien duaalinen rooli + roolin vaihtelevuus. kts. \ref{fig:gacek}
-
-\begin{figure}[!ht]
- \centering
- \includegraphics[width=75mm]{kuvat/udclassification.png}
- \caption{A Classification of Open Source Users and Developers \cite{gacek04}}
-\label{fig:gacek}
-\end{figure}
-
-Goldman and Gabriel \cite{goldman05} note that it is usual for people to come up with code centric view on project structure. Nakakoji et al. \cite{nakakoji02} have developed one fitting this description. Goldman and Gabriel highlight the importance of designers and separate it as a group of its own. Their main observation is that there is more to a project than just the code.
-
-It is also important to remember the connections between separate open source projects \cite{goldman05}. As mentioned earlier it is natural for an open source project to make use of existing work. Therefore when studying some specific project it does make sense to look at the whole to understand what kind of an effect the environment has on the project.
-
-\section{Rakenne}
-
-\begin{figure}[!ht]
- \centering
- \includegraphics[width=100mm]{kuvat/nakakoji.png}
- \caption{VALO-yhteisön yleinen rakenne \cite{nakakoji02}}
-\label{fig:nakakoji}
-\end{figure}
-
-Huom! myös sturmer esittää suunnilleen vastaavan mallin joskin hieman yleisemmällä tasolla
-
-tehokäyttäjät (pätsit ym.) merkitys! (lead user? power user)
-
-\cite{michlmayr07} s.17 viite howisonin malliin (sipuli kuten muutkin), \cite{khatib06} s. 27, \cite{robles06} (huom! GIMP mukana), \cite{mikkonen06} typologia -> volunteer, mixed, company, \cite{howison05} -> organisaationelikenttä
-
-Stürmer \cite{stuermer05} has provided an abstract model \ref{fig:stuermer} showing the main aspects of the structure of an open source project. The important thing to note is that the distance between a user and a developer can be almost negligible depending on a project. There is no a concrete role of a user or a developer in the most concrete sense.
-
-\section{Kehittäjät}
-
-kehittäjä sanan laajassa merkityksessä (myös ideoija, kääntäjä, graafikko tai dokumentaation laatija lasketaan)
-
-\subsection{Motivaatio}
-\cite{hars01}, \cite{maxwell06}, \cite{khatib06} s. 35-37, \cite{krishna02} -> BCG, \cite{lerner05}
-
-\subsection{Evoluutio}
-
-\subsection{Kaupallisuus}
-(esim. Linux (suuri osa kehittäjistä kaupallisia!))
-
-\section{Käyttäjät}
-michlmayr07!
-
-\subsection{Motivaatio}
-
-\subsection{Evoluutio}
-
-\subsection{Kaupallisuus}
+\chapter{VALO-menestystarinoita}
+
+\section{BIND}
+
+\section{Sendmail}
+
+\section{LaTeX}
+
+\section{Apache}
+
+\section{Mozilla Firefox}
+
+\section{Linux}
+
+\cite{moody01} \cite{raymond01}
+
+Linusin laki.
+
+\begin{itemize}
+\item 1987, Andrew Tanenbaum julkaisee Minixin. Minix on UNIX-versio, joka on tarkoitettu PC, Mac, Amiga sekä Atari ST alustoille. Sen mukana tulee myös lähdekoodi.
+\item 1991, Linus Torvalds julkaisee 0.02 version uudesta UNIX-variantista. Hän kutsuu versiota Linuxiksi Minix-uutisryhmässä.
+\item 1993, FreeBSD 1.0 julkaistaan. FreeBSD pohjautuu BSD UNIXiin ja se sisältää verkkotoiminnallisuutta sekä tuen virtuaalimuistille, suorituksen vaihdolle (task switching) sekä suurille tiedostonimille.
+\item 1993, Ian Murdock luo Debian Linux-jakeluversion.
+\item 1994, Marc Ewing muodostaa Red Hat Linuxin. Red Hatista tulee nopeasti johtava Linux-jakeluversio.
+\item 1994, Bryan Sparks perustaa Calderan entisen Novellin CEO:n Ray Noordan tuella.
+\item 1995, Apache ryhmittymä (Apache Group) kehittää uuden web-palvelimen, Apachen. Se pohjautuu NCSA:n (National Center for Supercomputing Applications) HTTPd 1.3:een ja kokoelmaan korjaustiedostoja (patch). Apache on nykyään johtava HTTP-palvelinohjelmisto.
+\item 1998, Merkittävät ohjelmistojen tuottajat, mm. Computer Associates, Corel, IBM, Informix, Interbase, Oracle sekä Sybase, ilmoittavat suunnitelmistaan portata ohjelmistojaan Linuxille. Sun ilmoittaa suunnitelmistaan julkaista Java 2:n lähdekoodi kehittäjille.
+\item 1999, Linuxin käyttäjien määräksi arvioidaan 7.5 miljoonaa.
+\item 2000, Yhä useammat ohjelmistojen tuottajat, kuten Novell ja Real, julkaisevat ohjelmistoistaan versioita, jotka toimivat Linuxilla.
+\end{itemize}
+
+olennaisia pointteja: Minix olisi voinut olla Linux, jos Tanenbaum olisi ollut kehityksen suhteen avoimempi (Linusin "innovaatio"). Vrt. myös OpenBSD (kaatui laitevaatimuksiin?) ja Hurd (kaatui kompleksisuuteen?). Olennaista huomata, myös kuinka Linux-organisaatio kehittyi (Linus ei skaalaudu! -> rakenne skaalautuu (jaettu vastuu)). Distribuutiot (Debian, Red Hat ym.). Ubuntun nousu (ubuntuismi terminä? chege, Ubuntuism, Commodification, and the Software Dialectic.). Menestys mobiili/serveripuolella. KDE vs. GNOME. monoliittisyys vs. monimuotoisuus (kernel, ikkunointijärjestelmät, standardit)
\chapter{Menestys}
@@ -694,7 +698,7 @@
millaisia ohjelmistoja löytyy? \cite{healy03}
-kartoitetaan ``ekosysteemiä'' tässä vaiheessa. sitten jollain sopivalla tavalla valitaan tarkasteltavat seuraavassa kappaleessa
+kartoitetaan ``ekosysteemiä'' tässä vaiheessa. sitten jollain sopivalla tavalla valitaan tarkasteltavat seuraavassa alaluvussa
jotain myös kirjastoriippuvuuksista jossain kohtaa???
@@ -722,7 +726,7 @@
tarvitaanko muita projekteja vertailtavaksi? samba (avoimen ja suljetun rajapinnassa!), inkscape (nuori, nopeasti kehittynyt projekti)
-\chapter{Menestysmalli}
+\chapter{VALO-menestysmalli}
tähän oma "merkittävyysmalli" (mitkä tekijät vaikuttavat merkittävyyteen ja miten? -> menestys)