path: root/2007/linux-development-model/linux-development-model.mgp

%include "default.mgp"
%default 1 bgrad
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
%nodefault
%back "blue"

%center
%size 7


Introduction to the
Linux Development Model
for Hardware Companies

%center
%size 4
by

Harald Welte <HaraldWelte@viatech.com>
VIA Open Source Liaison


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page 
The Linux Development Model for Hardware Companies
Introduction

Who is speaking to you?
		an independent Free Software developer, consultant and trainer
		13 years experience using/deploying and developing for Linux on server and workstation
		10 years professional experience doing Linux system + kernel level development 
		strong focus on network security and embedded
		expert in Free and Open Source Software (FOSS) copyright and licensing
		digital board-level hardware design, esp. embedded systems
		active developer and contributor to many FOSS projects
		thus, a techie, who will therefore not have fancy animated slides ;)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
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
The Linux Development Model for Hardware Companies
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
The Linux Development Model for Hardware Companies
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
The Linux Development Model for Hardware Companies
Development Process

	"Rough concensus and running code"
	Decisions made by technically most skilled people
	Reputation based hierarchy
	Direct Communication between developers
	Not driven by size of a target market
	Release early, release often


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Motivations

	gaining reputation (like in the scientific community)
	(students) gaining development experience with real-world software
	solving problems that the author encounters on his computer
	fighting for Free Software as ideology
	working on exciting technology without having to work at company XYZ
	work in creative environment with skilled people and no managers ;)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
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
The Linux Development Model for Hardware Companies
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
The Linux Development Model for Hardware Companies
Weak Points of FOSS

When foss is entirely volunteer-driven
	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

	Thus, FOSS really improves when organizations/entities get involved the right way!

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Windows driver development model


		MS defines stable APIs and ABIs for drivers and releases SDK (DDK)
		All interfaces are specified by a single entity
		The interface between driver and OS core is designed as binary interface
		Hardware vendors develop drivers for their hardware component
		Hardware vendors compile and package drivers for their hardware component
		Hardware vendors sell bundle of hardware and software driver (object code)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Linux driver development model


		A community-driven process creates in-kernel driver API's
		Drivers are written against those APIs
		Drivers are submitted to the kernel developes for inclusion into the OS source tree
		Because all (good) drivers are inside one singe source tree, OS developers can (and will) refine the APIs whenever apropriate
		There are no stable in-kernel API's, and especially no stable in-kernel ABI's
		Linux development community releases kernel source code
		Hardware vendor sells hardware only.  The Windows driver CD is unused.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Linux driver development model


		Without proper support from HW vendor, Most hardware drivers are developed by people inside that community
			sadly most of them have no relation to the HW manufacturer
			even more sadly, many of them have to work without or with insufficient documentation (reverse engineering)

		Good HW vendors understand this and support Linux properly!

		Linux is a big market by now
			Servers
			Embedded devices (est. > 40% of all wifi/dsl router + NAS appliances)
			Increasingly popular on the Desktop
			Recently: Netbooks

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Linux driver development model, bad case timeline


		Hardware vendor produces and ships hardware 
		Users end up getting that hardware without any Linux support
		Somebody will start a driver and inquire about HW docs
		Hardware vendor doesn't release docs
		If hardware is popular enough, somebody will start reverse engineering and driver deevlopment
		With some luck, the driver is actually useable or even finished before the HW product is EOL

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Linux driver development model, good case timeline #1


		Hardware vendor starts Linux driver development for new HW during HW R&D
		Hardware vendor submits Linux driver for review / inclusion into mainline Linux kernel before HW ships
		User installs HW and has immediate support by current Linux kernel
		Hardware vendor publicly releases HW docs when the product ships, or even later
			This enables the community to support/integrate the driver with new interfaces
			It also enables the community to support hardware post EOL, at a point where the HW vendor 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Linux driver development model, good case timeline #2


		Hardware vendor releases HW documentation during HW R&D or no later than the product start shipping
		Somebody in the Linux development community might be interested in writing a driver
			in his spare time because of technical interest in the HW
			as a paid contractor by the HW vendor
		In such cases it helps if the HW vendor provides free samples to trustworthy developers
		That driver is very likely to get merged mainline

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Why submit your code mainline?


		Quantity-wise, most users use some Linux distribution
		Every version of every distribution ships a different Linux kernel version
		Most end-users are not capable of compiling their own kernel/drives (but way more than you think!)
		Thus,
			teaming up with one (or even two, three) Linux distributions only addresses a small segment of the user base
			distributing your driver independently (bundled with hardware, ...) in a way that is ready-to-use for end-users is a ton of work and almost impossible to get right
			the preferred option, with the least overhead for both user and HW vendor is to merge the driver mainline.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
How to submit your code mainline?


		The FOSS code quality requirements are _extremely_ high
		It's not a surprise that Linux is generally considered much more stable than competitors
		Code needs to be maintainable
			Linux supports old hardware ages beyond their EOL
			Thin of MCA, VLB, Decnet, IPX networking, ...
		So unless you respect the development culture, your code is likely to get rejected!
		Post your driver at the respective mailing lists
		Release early, release often
		Don't hesitate to ask for feedback and suggestions if you are not 100% sure what is the right way to implement a certain feature

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
What about other FOSS OS's


		There are quite a number of other non-Linux FOSS OSs, among them
			FreeBSD, OpenBSD, NetBSD, ...
		Those are not as small as you might think
			FreeBSD often used for internet severs (web, mail, ...)
			OpenBSD often used in high-security environments
			NetBSD a little more prominent in embedded
		So how does this affect a HW manufacturer
			In case the OS is used in a targetted market, developing a driver might make sense
			In most cases, open docuentation is all those projects need
			In other cases, dual-licensing a driver (GPL+BSD) makes sense so *BSD can use code from the Linux driver

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Techncal differences


		In the MS world, almost all interfaces are MS defined
		In the Linux world, Linux is only the OS kernel
		All other interfaces are specified by their respective projects
		Often there are many alternatives, e.g. for graphical drivers
			X.org project (X11 window server, typical desktop)
			DirectFB project (popular in embedded devices like TV set-top boxes)
			Qt/Embedded (popular in certain proprietary Linux-based mobile phones)
		Every project has it's own culture, including but not limited to
			coding style
			patch submission guidelines
			software license
			communication methods

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
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
The Linux Development Model for Hardware Companies
Practical Rules

	2. Interfaces
		If there is a standard interface, use it
		If insufficient: 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
The Linux Development Model for Hardware Companies
Practical Rules

	3. Merge your code upstream
		Initially you basically have to 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
The Linux Development Model for Hardware Companies
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 self-contained module

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Practical Rules

	5. Binary-only software will not be accepted
		yes, there are corner cases like FCC regulation on softradios
		but as a general rule of thumb, the community will not consider object code as a solution to any problem

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
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
The Linux Development Model for Hardware Companies
Practical Rules

	7. Show your support for the Community
		By visibly contributing to the project
			discussions
			code
			equipment
		By funding developer meetings
		By making rebated hardware offers to developers
		By contracting / sponsoring / hiring developers from the community



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model for Hardware Companies
Thanks


	Please share your questions and doubts now!

	Please contact me at any later point, if you have questions

	I'm here to help VIA understand Linux and Open Source!

	HaraldWelte@viatech.com

%center
Thanks for your Attention