summaryrefslogtreecommitdiff
path: root/2009/linux-development-model-kr2009/linux-development-model-kr2009.mgp
blob: 3df8d4712cb4f1e9488957d5b0c40e34b49e6d2a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
%include "default.mgp"
%default 1 bgrad
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
%nodefault
%back "blue"

%center
%size 7

Introduction to the
Linux Development Model


%center
%size 4
by

Harald Welte <hwelte@hmw-consulting.de>
hmw-consulting / gpl-violations.org / openmoko.org

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page 
The Linux Development Model 
Introduction

Who is speaking to you?
		an independent Free Software developer, consultant and trainer
		14 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 
Introduction


What is my affiliation?
		an independent freelancer, not speaking for any comany
		working in the Free Software community for many years
		used to be the maintainer of the Linux firewall netfilter/iptables
		started many Free Software and Open Hardware projects, e.g.
			OpenEZX - Open Source for Motorola EZX phones
			OpenPCD/librfid - 13.56MHz RFID stack
			OpenBeacon - 2.4GHz active RFID
			gnufiish - Linux for E-TEN PDA-phones
			OpenBSC - A GSM backend network BSC+MSC+HLR
		was employee #1 and Lead System Architect (HW+SW) of Openmoko
		consulting many companies on FOSS development + licensing	

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model 
Motivations (individual)

	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 
Motivations (corporate)

	not having to reinvent the wheel
	if FOSS provides 80% of your problem solution, you just have to add the missing 20%
	fully customizable, every aspect of the system can be modified/adopted/changed
	no per-unit royalties
		be aware, you have more one-time R&D cost


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model 
Who is "The Community"?


	Studies show
		the majority of the Linux kernel code is developed by professional, paid developers
		most of them work for large IT companies (Intel, Novell, IBM, RedHat, ...)
		those companies would not invest the development resources if there was no business case for it!
	So "the community"
		is not a random collection of individuals scratching their itch
		but is a group of very prominent professional developers working for some of the biggest IT companies worldwide

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model 
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 
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
		note: Samsungs manuals now under NDA :(


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model 
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 commercial entities get involved the right way!

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model 
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 
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 
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 
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 
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 
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 
Why submit your code mainline?

	In the PC world
		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 
Why submit your code mainline?

	In the embedded/ARM world
		there are more customers of your SoC than just the tier-1 customers
		the small/medium size customers do not qualify for your support
			but if documentation and/or source is availale, they can still buy and use your product
		the more developers know your product, the more will recommend it in their companies
			existing experience with a sertain SoC is very valuable, reduces lead time, helps solving problems quickly
		there are even way more custom distributions in the embedded world
			you can never support even the smallest fraction of them
			but all of them use the mainline kernel as base version
			if your driver + support code is in mainline, all of the distributions will easily run on your SoCs
		keeping all code in mainline reduces fragmentation of the codebase
		keeping all code in mainline means you get help with porting and integration with new kernel changes

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model 
Samsung LSI is part of the community


Samsung LSI is part of the community
	Linux exists because of massive, industry-wide collaboration
	Only because everyone contributes, Linux Grows
	Everyone helps to create a better platform
	If SLSI Linux drivers/support is good, Linux customers prefer SLSI over other vendors
	Don't only create drivers, but infrastructure (core OS/kernel)
	Every company does its small part of the Linux kernel R&D


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model 
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 
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 
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 
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 
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 
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 
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 
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 
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 Distribution Model
The "Linux" System


	What is a so-called Linux system
		The Linux operating system kernel
		The X.org X11 windowing system
		Various non-graphical system-level software
		A variety of different desktop systems (KDE, Gnome)
		A variety of GUI programs

	In reality, this is a "Linux Distribution"
		sometimes referred to as "GNU/Linux System"

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Entities in the Linux system


	Free Software projects and their developers
	So-called "Distributors" who create "Distributions"
	Contributors
	Users
	Vendors of proprietary Linux software


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
FOSS Projects


	Free Software projects and their developers
		Linux Kernel, Xorg, KDE, Gnome, Apache, Samba

	Role
		Development of the individual program
		Very focused on their individual project
		Portability and flexibility usually main concern
		Interact based on practical neccessity

		Usually they just provide source code, no object code

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Distributions


	Distributions (both commercial and community based)
		Debian, Ubuntu, SuSE, Fedora, RedHat, Mandriva, ...

	Role
		Aggregate thousands of individual FOSS programs
		Find stable and compatible versions of those programs
		Do 'software system integration'
		Offer bianary software packages and installation media
		Offer (security) updates to their users
		Offer free/best effort or commercial support for professional users

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Contributors


	Contributors
		are people not part of a specific development team
		usually "very active users" of a particular program

	Role
		find / document / fix bugs that they find themselves
		contribute bug reports, documentation or code
		participate in discussion on features or problems

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Users


	Users
		are people just using software

	Role
		using programs
		they usually just install+use a particular distribution
		they typically do not download+install software directly from the particular software project


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Vendors of Proprietary Software


	Vendors of proprietary Software (e.g. Oracle)
		remain a small niche in the Linux world
		usually driven by a very specific industry
		they can exist because kernel/userspace ABI is stable!

	Role
		feed-back some of their requirements to the Open Source developers
		help the operating sytestem development to make sure OS is good for them

	Note: This is not applicable for driver development!
		drivers are in the Linux kernel, not userspace

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Collaborative Software Development


	How do projects communicate internally
		Very rarely in physical meetings (people live too far apart)
		Very rarely in phone conferences (people live in different timezones)
		It's almost entirely text-based (e-mails, sometimes chat system)

	Mailing Lists
		Usually every project has at least one list
		Often there are separate lists for developers and users
		Participation in the mailing list (reading and posting) open to anyone

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Collaborative Software Development


	Project Management / Decision making
		usually there's a small group (coreteam) or one leader
		he is often the creator of the program, or it's maintainer
		he has the final say in what is accepted or not
		larger projects have 'subsystem maintainers' with delegated authority
		so quite often, the structure is more hierarchical than people believe
		rough concensus and running code
		

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Motivation of Software Developers


	Why do developers work on a FOSS project
		because they're interested in a certain area
		because it's fun to learn and improve skills
		because it's fun to co-work with world-class hackers

	How do people make money
		often by offering commercial support for their software
		by offering poerting or system integration
		by offering development of extensions/modifications
		by working for a company that uses/needs that program


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Linux and binary compatibility


	Linux and binary compatibility
		Drivers usually run inside the OS kernel
		Linux doesn't have any stable kernel-internal ABI
		Linux doesn't even have stable kernel-internal API
		Only the ABI to userspace is stable/fixed

	Thus, every minor Linux release can break in-kernel ABI+API
	This is why binary-only drivers simply don't work!

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Linux and binary compatibility


	I still don't believe! Why not binary-only drivers
		because every distribution has a different base kernel revision
		because every distribution can change their kernel version e.g. as part of a security update
		users will end up in incompatibility nightmare
		so please, don't do it.  It will never work for the majority of your users

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Implications for Hardware Vendors


	Implications for Hardware Vendors
		Users are used to get all software from the distribution
		They are not used to separate vendor-provided driver CD's
		Thus, drivers need to be in the distribution
		Goal: getting drivers into the distrubution

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Implications for Hardware Vendors


	How to get drivers into distributions?
		You can talk directly to the distributions
		But: Their code architecture/style requirements are high
		But: Many of them do not accept binary-only drivers
		But: There are many, many distributions.
		Linux is only a certain portion of the market
			Every distribution is only a small portion of the portion
			Thus, new goal: Get your drivers in the mainline project

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Distribution Model
Implications for Hardware Vendors


	Getting drivers in the mainline project
		ensures that all distributions will pick up the driver
		ensures out-of-the box support of your hardware on all distributions
		ensures best user experience
		ensures least internal R&D resources
			no need to provide binaries for 3 versions of 5 distributions
			no need to constantly try to catch up with distribution kernel updates


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
The Linux Development Model 
Thanks


	Please share your questions and doubts now!

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

	I'm here to help Samsung!

	hwelte@hmw-consulting.de

%center
Thanks for your Attention
personal git repositories of Harald Welte. Your mileage may vary