This document discusses two modes of product development: head-oriented and release-oriented. Head-oriented development focuses on continuous development with no releases, while release-oriented emphasizes stable releases with quality assurance. The number of developers versus users affects which mode is appropriate. Head-oriented works best initially when developers outnumber users, while release-oriented requires more users and corporate backing. Open source projects often transition from head-oriented to release-oriented as their user base grows.

1. Two modes of Product Development
Head-oriented vs. Release-oriented
Masayuki Hatta
Faculty of Economics, Surugadai University
Debian Project / GNU Project
mhatta@gnu.org

2. Case
● 2 (or more) FLOSS projects competing in the
same area
– Linux vs. *BSD or GNU HURD
– KDE vs. GNOME
– OpenOffice.org vs. LibreOffice
– MySQL vs. PostgreSQL
● Some win, some lose

3. “Win”?
● There can be many definition
● For now...
– Winning popularity
– Attracting developers
– Attracting users

4. Some win, because...
● It was superior?
● It was promising?
– The initial design was good?
● It had genius hackers?
● It got great marketing?
● It got no legal problem?
● Pure coincidence?
– Surely there are external reasons

5. The Enigma of Linux
● The Linux Kernel == The most successful
FLOSS project in the history

6. The Enigma of Linux
● Linux was NOT promising project in its
inception
– Tanenbaum / Torvalds debate (1992)
– Was Linus “genius”?
● There are (better?) competitors in the FLOSS
world
– Hurd (promising architecture)
– *BSD (looser licensing)

7. The Enigma of Linux
● Linux didn't win because it was great
● Linux became great because it won
● ...so now we go back to the starting point

8. Skyrocketing & Sudden death
● Skyrocketing
– Some projects suddenly gain momentum
● Sudden death
– Some projects suddenly lose momentum
– ...Not really immediate “death”, but fiasco and
possible slowdown for a while
– Happens usually when the new major release is
out

9. KDE4.0 Fiasco
● KDE4.0 was released in 2008
● Developers love it
– A lots of new ambitious features
● Users don't love it
– Unstable, buggy
● Release manager in trouble
– Finally resigned

10. A KDE developer's cry
“KDE and open source is not ever obligated to
please users. We are not obligated to fix bugs.
We are not obligated to implement things that
you demand. We are not obligated to provide
open forums for you to attack us personally.”
– Troy Unrau

11. KDE4.0 Fiasco
● Interestingly, GNOME 3.0 suffers similar kind
of muddle recently

12. Hypothesis
● The preference and priority of developers and
users might differ
– Things users think important are sometimes not
that important for developers
● Developers love hacks, but only certain kind of
hack
– Things willing to do / Things needs to be done

13. Hypothesis
● There are several “modes” of software
development
– Mode == a way of thinking, manner
● Sometimes there are mismatches of expectation
between users and developers
– The preference of “community” might be changed as
time goes by
● Projects are doing great if they employ the right
product management scheme in the right time
– Vice Versa

14. Release-oriented

15. Release-oriented
● Focused on good, attended Quality Assuarance
– QA works don't add new features
– QA is somewhat boring, believe me
– QA is needed to be done
● Stable(not so buggy, secure, etc), but not cutting-
edge
● Good for stable environment
● Basically for users who appreciate “usable” projects
● Most products (not only software) go this way

16. Head-oriented

17. Head-oriented
● Continuously developed
– No release, just “snapshots”
– “always beta” (O'Reilley 2008)
● e.g. Wikipedia
– Facebook?
● Users & developers share the same codebase
– Thanks to Version Control System and so on
● Good for rapidly changing environment
● For developers(and advanced users)

18. Release vs. Head
● Surely there are hybrid release pattern
– Minimum QA are always there

19. Typical FLOSS development
dilemma
● Gaining momentum
● Gaining new users
● New users(e.g. Corporate users) appreciate
stable releases
● Developers appreciate cutting-edge snapshots
● Conflict!
– Sometimes it leads the loss of developers

20. Evolution of a community
Users
Developer

21. Head-Oriented Release-Oriented
N of Developers >> Users Developers are happy Developers are not happy
Too difficult for ordinal users Too bureaucratic
Rapid development, but
the user base might remain
relatively small
Suited for initial phase
N of Developers << Users Developers might be happy Developers are not happy, but
but most users are not users might be
And ultimately developers Needs corporate backing?
suffers conflict with users

22. Head-Oriented Release-Oriented
N of Developers >> Users Developers are happy Developers are not happy
Too difficult for ordinal users Too bureaucratic
Rapid development, but
the user base might remain
relatively small
Suited for initial phase
N of Developers << Users Developers might be happy Developers are not happy, but
but most users are not users might be
And ultimately developers Needs corporate backing?
suffers conflict with users

23. Some thoughts
● Linux
– Head → Release went smoothly
● Others not
– Even/Odd numbering → mainline/stable release (w/ Git)
– Corporate backings
● Debian
– Long release interval → The rise of Ubuntu
● Mozilla
– vs. Google Chrome
– Is there still “community” development?
– Limited N of developers employed by limited N of corporations
● Web applications
– No deployment cost
– Many users, almost no outside developers

24. Some thoughts
● Japanese manufacturing companies
– Traditionally very Release-oriented
● “Monodukuri”
– Maybe one of the reason they have hard time to
adjust to the era of the Net

25. References
● See proceedings
● Or wait for full paper ;-)

26. Thanks for listening
mhatta@gnu.org
http://about.me/mhatta
Twitter/Identi.ca: @mhatta (in Japanese, English for Identi.ca)
Twitter: @masayukihatta (in English)