- 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