A presentation I gave in 2006 on my publication "Raiding the Noosphere: the open development of networked RAID support for the Linux kernel", from Software - Practice and Experience, 36(4) pages 365-395, published April 2006. The preprint of the full paper is available at http://www.academia.edu/1413581/Raiding_the_Noosphere_the_open_development_of_networked_RAID_support_for_the_Linux_kernel .

1. Raiding the Noosphere
Peter T. Breuer
Universidad Carlos III de Madrid

2. Open Source projects
● Noosphere : "Universe of the Internet"
– inhabitants
– social processes
– economics.
● Open source projects require a
Noospheric development process.
● Code is part of the process, not its product.

3. Life cycle
● No:
– waterfall
– spiral
– v-cycle
– rapid prototyping
● Yes:
– working code is the starting point;
– project can redefine itself as it evolves;
– requirements: live long and prosper.

4. Success
● Successful project
– generates effort from the resources available on
the internet, not only from its internal resources
● others may request features, offer patches,
documentation, argue designs, generate
discussions
● Unsuccessful project
– dies
● is stability death?
● Cex? Apache 1.3 is stable, 60% of Apache
deployments, but 80% of the code is untouched
for 5 years or more.

5. FR1
● Fast RAID type 1
– avoid full resync in favour of intelligent resync
using bitmap technology
– detect old components automatically on
reinsertion and respond appropriately
unattended
– increased robustness in a variety of situations
with the aim of avoiding operator intervention
● recover automatically from network brownouts
for networked components
● tolerate and correct read and write errors

6. Initial Resource Estimation
● 1 month, 100 lines/day (changes + additions)
– 30-40 function points assuming max speed
● Component analysis shows18-21 function points
● 42 "hunks" in patch
● Effort depends on
the number of
individual system
modifications
required

7. Other Effort Estimations from FR1
● Study kernel code -40% of effort
● Test hand in hand with development 30%+30%
– avoid postmortem debugging
● Writing kernel code is 4 times as hard as writing
application code
– 1:4 frequencies of changes kernel/non-kernel
● Limits from psychlogical exhaustion apply
– number of reboots per day
– number of tests per day

9. Communication
● OS project has increased communication burden
– potentially need to communicate with whole
Internet
● persuade others to adopt code
● convince others to add hooks for code
● take in patches, send out patches, discuss ...
– marketing
● in other types of project, at least the authors are
agreed on what they are doing
● Dissemination takes place with and shouldbe
considered part ofdevelopment

10. OS Life-Cycle Model

11. Point Zero
● Model takes project
– from
point zero
the point at which a prototypeworking code is
made available
– to the
expansion point
where the project grows on its own

12. Comparison with V-cycle

13. Differences to V-Cycle
● OS model is inherently
– cyclic
– continuous
● Includes a
– strong marketing component
● V-cycle has no initial publicity-generating phase
● marketing classically has 2 phases
– strategy (brainstorming ideas)
– communications (poster design, advertising
placement etc.)
– OS cycles these two phases continuously

14. OS Stage 1 - settng up stall
● Eric Raymond calls this "home-steading" in the
Noosphere
● Make project announcements on freshmeat and
sourceforge
● Notify core kernel authors for that area
● Announce on relevant mailing lists
Webster's Unabridged dictionary, 1913: Stall, n. 1. A stand; a
station; a fixed spot.
... 4. A bench or table on which small articles of merchandise are
exposed for sale

15. OS Stage 2-Pitching a Sale
● Open source competes in 2 markets
– market for clients/users
– market for authors/collaborators
● Use fora to advertise in
– encourage discussions
– rely on "lurkers" to tell others
Wordnet r1.7: pitch n. ... 3: (British) a vendor's position
(especially on the sidewalk); 4: promotion by means of an
argument and demonstration [syn: {sales talk}, {sales pitch}]

16. OS Stage 3 -Feeling the Pulse
● Gauge responses
– silence may mean"throw it away and rewrite from
scratch"
– analyse responses to extract unvoiced information
– take note of informed opinions
Webster's Revised Unabridged Dictionary (1913): {To feel one's
pulse}. (a) To ascertain, by the sense of feeling, the condition of the
arterial pulse. (b) Hence, to sound one's opinion; to try to discover
one's mind.

17. OS Stage 4 -Taking Stock
● Make a high level description of the design
– seek comments
● Make a hunk by hunk description of the patch
– post separately
● Obtain feedback and apply it.
WordNet (r) 1.7: take stock, v : to look at
critically or searchingly, or in minute detail.

18. Code Balances for Fr1
● 2500 LOC in 1 month
– this is "point zero"
– written from scratch duplicating kernel
functionality
● 800 LOC after 2 months
– written as patch to existing kernel functionality
– comprises stages 1-4
– "expansion point"
– changes in month 2 also total 2500 LOC so effort
is the same

19. Summary
● Life Cycle model for Open Source projects
– covers "point zero" to "expansion point"
● before point zero the project is hype
● after the expansion point it takes care of itself
– continuous cycle of managing a market-oriented
development
● set out stall - announce to market
● pitch a sale - convince and cajole clients and
contributers
● feel the pulse - analyse maket responses
● take stock - apply lessons learned