diff options
Diffstat (limited to '2004/relation-community-lb2004/notes')
| -rw-r--r-- | 2004/relation-community-lb2004/notes | 107 |
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 + |