import of old now defunct presentation slides svn repo

3 files changed, 409 insertions, 0 deletions

diff --git a/2004/relation-community-lb2004/abstract b/2004/relation-community-lb2004/abstract
new file mode 100644
index 0000000..a52578c
--- /dev/null
+++ b/2004/relation-community-lb2004/abstract
@@ -0,0 +1,27 @@
+How to establish a 'business relationship' with the free software community
+
+If you're coming from a traditional business perspective, the Linux and Free
+Software development community might still seem quite a bit strange. 
+
+However, it is the authors' belief that it is very important for vendors of
+linux-based products and solutions to establish a healthy relationship with the
+free software community.
+
+Both parties can greatly benefit from such a relationship:  The businesses can
+reduce their maintainance cost by submitting their changes back into the free
+software project.  They also profit from new features developed within the
+community.
+
+The community benefits by increased number of users, more supported hardware
+and feedback about the real needs of the users.
+
+The author is a respected member of the Free Software development community,
+and at the same time working as technical consultant to a number of
+corporations working on Linux-Kernel related development.  From his past
+experience, very few businesses have managed to establish this 'healthy'
+relationship, simply because they didn't understand how free software
+developmen works, and how they fit into that development model.
+
+This presentation tries to explain the Free Software development model and give
+guidelines how businesses should interact with Free Software projects.
+
diff --git a/2004/relation-community-lb2004/interact-community-lb2004.mgp b/2004/relation-community-lb2004/interact-community-lb2004.mgp
new file mode 100644
index 0000000..62fce2c
--- /dev/null
+++ b/2004/relation-community-lb2004/interact-community-lb2004.mgp
@@ -0,0 +1,275 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+
+How to interact with the
+Free Software Community
+
+
+%center
+%size 4
+by
+
+Harald Welte <laforge@hmw-consulting.de>
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Contents
+
+	Introduction
+	What is Free Software?
+	What is the FOSS Community?
+	People / Groups involved
+	Development Process
+	Motivations
+	FOSS likes
+	FOSS disliks
+	Weak Points
+	Practical Rules
+	Thanks
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+How to interact with the Free Software Community
+Introduction
+
+Who is speaking to you?
+
+		an independent Free Software developer, consultant and trainer
+		who is a member of the free software community for 10 years
+		who has a background in both the community and the corporate crowd
+		who will therefore not have fancy animated slides ;)
+
+Why is he speaking to you?
+
+		because every working day he suffers the lack of understanding between the community and the business world
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+What is Free Software?
+
+	Software that is 
+		available in source code
+		is licensed in a way to allow unlimited distribution
+		allows modifications, and distribution of modifications
+		is not freeware, but copyrighted work
+		subject to license conditions, like any proprietary software
+		READ THE LICENSE
+
+What is Open Source?
+		Practically speaking, not much difference
+		Remainder of this presentation will use the term FOSS (Free and Open Source Software)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+What is the FOSS Community?
+
+	Diverse
+		any individual can contribute
+		no formal membership required
+		every project has it's own culture, rules, ...
+	International
+		the internet boasted FOSS development
+		very common to have developers from all continents closely working together	
+	Evolutionary
+		developers come and go, as their time permits
+		projects evolve over time, based on individual contributions
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+People / Groups involved
+
+	Really depends on size of projects
+	Small projects often a one-man show
+	Bigger project have groups / subgroups
+	Common Terms / Definitions
+		Maintainer
+			The person who formally maintains a project
+		Core Team / Steering Committee
+			A group of skilled developers who make important decisions
+		Subsystem Maintainer
+			Somebody who is responsible for a particular sub-project
+		Developer Community
+			All developers involved with a project
+		User Community
+			Users of the software who often share their experience with others
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Development Process
+
+	"Rough concensus and running code"
+	Decisions made by technically most skilled people
+	Reputaion based hierarchy
+	Direct Communication between developers
+	Not driven by size of a target market
+	Release early, release often
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Motivations
+
+	gaining reputation (like in the scientific community)
+	gaining development experience with real-world software
+	solving problems that the author encounters on his computer
+	fighting for free software as ideology
+	work in creative environment with skilled people and no managers ;)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+FOSS Community likes
+
+	generic solutions
+	portable code
+	vendor-independent architecture
+	clean code (coding style!)
+	open standards
+	good technical documentation
+	raw hardware, no bundle of hardware and software sold as solution
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+FOSS Community dislikes
+
+	monopolistic structures
+		e.g. intel-centrism
+	closed 'industry forums' with rediculous fees
+		e.g. Infiniband, SD Card Association
+	standard documents that cost rediculous fees
+	NDA's, if they prevent development of FOSS
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Weak Ponts of FOSS
+
+	often way behind schedule (if there is any)
+	already too late when projects start
+		started when there already is a real need
+	often a lack of (good) documentation
+		programmers write code, not enduser docs...
+	strong in infrastructure, weak in applications
+		traditionally developers interested in very technical stuff
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Practical Rules
+
+	1. Much more communication
+		It's not a consumer/producer model, but cooperative!
+		Before you start implementation, talk to project maintainers
+			It's likely that someone has tried a similar thing before
+			It's likely that project maintainers have already an idea how to proceed with implementation
+			Avoid later hazzles when you want your code merged upstream
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Practical Rules
+
+	2. Interfaces
+		If there is a standard interface, use it
+		Don't invent new interfaces, try to extend existing ones
+		If there is an existing interface in a later (e.g. development) release upstream, backport that interface
+		Don't be afraid to touch API's if they're inefficient
+			Remember, you have the source and _can_ change them
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Practical Rules
+
+	3. Merge your code upstream
+		Initially you basically create a fork
+		Development of upsteram project continues sometimes at high speed
+		If you keep it out of tree for too long time, conflicts arise
+		Submissions might get rejected in the first round
+			Cleanups needed, in coordination with upstream project
+			Code will eventually get merged
+		No further maintainance needed for synchronization between your contribution and the ongoing upstream development
+		Don't be surprised if your code won't be accepted if you didn't discuss it with maintainers upfront and they don't like your implementation
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Practical Rules
+
+	4. Write portable code
+		don't assume you're on 32bit cpu
+		don't assume you're on little endian
+		if you use assembly optimized code, put it in a plugin
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Practical Rules
+
+	5. Binary-only software will not be accepted
+		yes, there are corner cases like FTC regulation on softradios
+		but as a general rule of thumb, the community will not consider object code as a solution to any problem
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Practical Rules
+
+	6. Avoid fancy business models
+		If you ship the same hardware with two different drivers (half featured and full-featured), any free software will likely make full features available on that hardware.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+How to interact with the Free Software Community
+Practical Rules
+
+	7. Show your support for the Community
+		By visibly contributing to the project
+			discussions
+			code
+			equipment
+		By funding developer meetings
+		By making cheap hardware offers to developers
+		By contracting / sponsoring / hiring developers from the community
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+GNU GPL - Copyright helps Copyleft
+Thanks
+
+	Thanks to
+		Alan Cox, Alexey Kuznetsov, David Miller, Andi Kleen
+			for implementing (one of?) the world's best TCP/IP stacks
+		Paul 'Rusty' Russell
+			for starting the netfilter/iptables project
+			for trusting me to maintain it today
+		Astaro AG
+			for sponsoring parts of my netfilter work
+		Free Software Foundation
+			for the GNU Project 
+			for the GNU General Public License
+
+%size 3
+	The slides of this presentation are available at http://www.gnumonks.org/
+
+
diff --git a/2004/relation-community-lb2004/notes b/2004/relation-community-lb2004/notes
new file mode 100644
index 0000000..4d2b2d3
--- /dev/null
+++ b/2004/relation-community-lb2004/notes
@@ -0,0 +1,107 @@
+- free software community
+	- definition of free software
+		- requires source code access
+		- everybody can make modifications
+		- everybody can redistribute
+	- diverse
+		- any individual can contribute
+		- no formal membership
+	- international
+		- the internet boosted free software development
+		- very common to have developers from all continents in one project
+
+	- development process
+		- rough concensus and running code
+		- decisions made by technical most skilled people
+		- reputation-based
+			- important to have good reputation as business
+		- direct communication between developers, no manager-meets-manager situation
+			- email
+			- mailing lists
+		- not driven by size of a target market (yes, I'm running GNU/Linux on Apple/PPC and Sun/Ultrasparc hardware, of course!)
+		- release often, release early
+
+	- people / groups involved
+		- depends on size of project
+		- small projects often one-man show
+		- bigger projects have groups/subgroups
+			- maintainer
+			- core team / steering committee
+			- subsystem maintainers
+			- developer community
+			- user community
+
+	- motivations for developers to participate
+		- gaining development experience
+		- solving problems they encounter on their systems
+		- fighting for free software as ideology (religion?)
+		- gaining reputation (much like scientific community)
+		- work in a creative environment with skilled people and no managers ;)
+	- FOSS community likes
+		- generic solutions
+		- portable code
+		- vendor-indepent architecture
+		- clean code (coding style!)
+		- open standards
+		- technical documentation
+			(remember the times where a 9-dot-matrix printer came with 300pages of documentation?)
+		- raw hardware, no bundle of hardware and application sold as solution
+	- FOSS community dislikes
+		- monopolistic structures
+			- intel-centrism
+		- closed 'industry forums' with rediculous fees
+			- Infiniband
+			- SD Card Association
+		- standard documents that cost redicolous fees
+			- see above
+		- NDA's, if they prevent free software
+		- solutions, like 'e-mail buttons' at scanners
+
+	- weak points
+		- often way behind schedule (if there is any)
+		- always too late (development starts when there is a need, rather when marketing predicts a requirement)
+		- often a lack of (good) documentation
+		- strong in infrastructure (operating system, networking), but weak in end-user apps
+
+practical issues:
+
+- modification to existing project _need to be submitted upstream_
+	- if you develop something out of tree, you create a fork
+	- development of your upstream tree proceeds at high speed
+	- at some point, they can get too out-of-sync to make an easy merge
+	- submission may be rejected in first round
+		- cleanups needed, coordination with upstream project
+		- code finally gets included
+	- no further maintainance, kernel developers will modify it in case
+	  API's change
+
+- binary-only linux applications / drivers DON'T COUNT!
+	- you will never cover all platforms
+		- different cpu architecture / endianness
+		- different kernel versions
+		- different distibutions
+		- different library environment
+		- what about FreeBSD, OpenBSD, NetBSD, and all the other free OS's?
+	- the community lives by source code modification
+	- either publish source code or documentation, but no binary crap
+
+- offload at least part of your support to the community
+	- have support staff use public mailinglist where 
+
+
+- much more communication
+	- it's not a producer/consumer model, but cooperative!
+	- you don't have to work 
+	- before you start implementation, talk to project maintainers
+		- it's likely that someone has tried a similar thing before
+		- it's likely that project maintainers have already an idea how to implement your feature
+		- avoid hazzles when later merging the code back upstream
+	- if there is a standard interface, use it instead of inventing your own
+	- if the standard interface is insufficient, you can actually change the API, rather than working around it
+
+- show your support for the community
+	- by visibly contributing to the project (discussion on lists, code, ..)
+	- by funding developer meetings
+	- by making cheap hardware offers for developers
+	- by contracting or even hiring developers from the community
+