import of old now defunct presentation slides svn repo

1 files changed, 107 insertions, 0 deletions

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
+