%include "default.mgp"
%default 1 bgrad
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
%nodefault
%center, size 7, font "standard", fore "white", vgap 20

Dear Mr Brooks
%center, size 4, font "standard", fore "white", vgap 20

Alan Cox,  Red Hat 
%page

'Software Engineering'

Programming Teams
	Limited to about six people per team
	Hierarchical management structure
	Controlled access to other teams

Design Order
	Formal specification
	Design specification
	Detailed analysis of interfaces
	Marketing
	Code

%page

Free Software Projects

Programming Teams
	Small focused teams
	Hierarchy - formal or otherwise
	Access points between teams

Design Order
	Just about working prototype code
	Web Site (marketing)
	Working Product
	Documentation 

	Documentation often comes from third parties. 

%page

Communication

Software Engineering
	Communication is tree based. 
	Related areas in the same branch.
	Talking directly is often frowned upon
	Chinese whispers problem

Free Software
	Mailing list- Information hose-pipe
	Charismatic project leader
	Direct communication is common
	Connect people not pass messages


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page

Code Structure

Successful  free software is extremely modular

Interfaces favour isolation over speed

Interfaces are group maintained
	No one interface 'owner'
	All parties fix the interface
	Direct communication

%page

Evolution

Continuous evolution

Stupid interfaces/classes are not used

Complex interfaces are not used
	Programmers don't read manuals

Interfaces between modules are minimised 

Modules tend to interface to 'core' modules only

%page

Interface Reuse

Re-usability
	One interface has many users
	Many modules provide the same interface

Flexibility
	External 'plug ins'
	Unix tradition - call shell scripts

%page


Brooks Law

Free Software Is Generally Late
	Often a response to an event
	Classic example is GNOME
		Response to KDE
		KDE was well ahead
	Need driven software

%page

Brooks Law

Adding Programmers To Free Software
	Team sizes are fairly bounded
	Extra programmers - extra projects
	Modules fission
	Design and interface rules change
	Modules split along existing interfaces


%page

Downsides

Reduced Communication
	Can cause code duplication
	Causes bug duplication
	Example code most be good

%page

New model or old

Team Sizes
	Typically under six per module
	Generally has a clear leader
	Merit driven

Specialist
	Handle specific aspects of projects
		CVS
		Mailing Lists
		Autoconf
	Very much 'support staff'

%page 

New model or old

Modularity
	Aggressively modular
	Merit driven

Specialist
	Handle specific aspects of projects
		CVS
		Mailing Lists
		Autoconf
	Very much 'support staff'

%page 

New model or old

Modularity
	Aggressively modular
	Flexible simple interfaces
	Complexity is bad
	Subtle surprises are worse

Growth
	Growth by fissioning modules
	Interface specification changes

%page

Conclusions

Free software development has differences

Communications
	Communication reduction
	All information is freely available
	Filtered by developer not management

Management Structure
	Graph not tree based
	Continually makes/breaks nodes
	Project leaders act link people

%page

Conclusions

Code Structure
	Aggressively modular
	Simple functional interfaces
	All code is reusable
	Users of code/interfaces may change them
	Ugly code is only OK if localised


%center
Free Software Design Is About Avoiding Knowledge


.