summaryrefslogtreecommitdiff
path: root/2004/relation-community-lb2004/notes
diff options
context:
space:
mode:
authorHarald Welte <laforge@gnumonks.org>2015-10-25 21:00:20 +0100
committerHarald Welte <laforge@gnumonks.org>2015-10-25 21:00:20 +0100
commitfca59bea770346cf1c1f9b0e00cb48a61b44a8f3 (patch)
treea2011270df48d3501892ac1a56015c8be57e8a7d /2004/relation-community-lb2004/notes
import of old now defunct presentation slides svn repo
Diffstat (limited to '2004/relation-community-lb2004/notes')
-rw-r--r--2004/relation-community-lb2004/notes107
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
+
personal git repositories of Harald Welte. Your mileage may vary