© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 11

Open Source en “U”-Apache-

Dirk-Willem van GulikPresident of the Apache Software Foundation

dirkx@apache.org

Senior Partner,The Tribal Knowledge Group,

Alta, WY-USA, Leiden, NL<http://www.ttkg.comt/>

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 22

Open Source en “U”-Apache-

Dirk-Willem van GulikSenior Partner - The Tribal Knowledge Group

dirkx@ttkg.com

http://www.ttkg.com/

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 33

Overview

u A bit of history

u What binds them all

u The Apache Software Foundation– Projects

u Interaction with the outside world

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 44

Disclaimer

The ASF is a volunteer organization

So we all have two hats - our real live one,and the apache feathered cap

We’ve got good release procedures forcode; but prefer to talk about Apache andthe ASF rather than ‘for’ it.

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 55

History

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 66

Apache HTTP Server Project

u Founded in 1995 with a common goal– To maintain an open source, secure, efficient and

extensible server that provides HTTP services in syncwith non-proprietary World Wide Web standards

u Apache Group (now the HTTP Server PMC)– Self-selected volunteers that guide the project and

perform most of the development work

u Current status– #1 server

– Over 17 million web sites– 66% of the public/active Internet sites

– Focus on 2.0 release, with some minor changes to 1.3.x

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 77

ASF Members

u About 80 members– Roughly equally spread across all projects– 9 emeriti

u About 15-20 people with an organizational role– Board, PMC’s, press, maintenance

u About 700 committers

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 88

Projects (cont.)

u Main projects– The Web Server

– httpd, httpd-proxy, APR, apr-util– The Java engines

– Jakarta (Java-Apache)– XML/XSLT Parsers and generators

– Xalan, Xerces, …– Languages

– Java, Perl, TCL– Organizational: Conferences and Foundation

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 99

The projects (stack)

Tools

Libraries

Transport

Languages (Java, Tcl, Perl, ..)

Application Environments

Content generation

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1010

Why call ourselves Apache?

u No, it isn’t an attack helicopter– unless you happen to work for Microsoft

u A Patchy Server? Nope, that’s just a pun.

u A reference to our development philosophy:“Characteristic of both Eastern and Western Apache, with theexception of the Kiowa Apache, was the lack of a centralized tribalorganization. The band, an autonomous collection of small localgroups within a given locality, was the primary political unit aswell as the primary warring and raiding unit. The strongestheadman of the local groups was recognized as an informal chief,and several bands might be united under one leader. Chieftainshipwas thus not generally hereditary.” Encyclopaedia Britannica

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1111

What is apache

u A community with– Common goals and standards

– Good code, standards compliant– With little license restrictions.

– A set of release procedures

u A set of mailing lists

u A set of CVS repositories

u A web site

uAh- and the ‘Apache Software Foundation’.

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1212

Release process

Not your enterprise procedure.

1. Propose a release when no show stoppers

2. And people feel like it, no biggies left.

3. Slowly freeze out

4. Slip into vote then commit mode

5. Announce the final cut (and some testing)

6. Version++; then Tag (and build a tarbal)

7. Real testing

8. In case of a fault: Goto 1

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1313

Interaction with the outside world

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1414

Open Source and Free Software

Tiny License Primer

-just enough to understand apacheits peculiarities -

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1515

Licenses

Open Source

u BSD, Athena, X11, MIT,Apache and older.

u *bsd, apache, bind, sendmail,dhcp

u Short, legal

u Do not remove the license

u Do with it what you want.

u If it breaks, you cannot notsue me.

Free Software

u GPL

u Gcc, KDE, Hurd, “linux”,“perl”

u Long, Manifesto

u Do not remove the license

u If you give it to someone elseyou must give the source too.

u If it breaks you cannot sueme.

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1616

Result

Open Source

u Programmers can do what theywant.

u Does not dictate the businessmodel.

u Added/created IP may not makeit back to the community.

u Very low barrier for everyone.

u Contribution driven by economicneeds, ego, fun and lowering ofproductization cost.

Free Software

u Code stays free and open

u Creation of IP or Mixing withinternal IP will cause that IP tobe freely available when thecode is sold/given to anyone.

u Companies limited to support.

u Low barrier to small companieswith little IP

u High barrier/cleanroom for bigcorporates.

u Contributions forced by legalrequirement.

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1717

Academic Example

v1 v2 v3

v3

News Flash:Smart hacker proposes

Brilliant fix

v4*v4 v5 v6

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1818

Corporate Example (GPL)

v1 v2 v3

v3

News Flash:Smart hacker proposes

Brilliant fix

v3*

v4 v5

v6v4 v8

v6v6

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 1919

optional

Corporate Example (BSD)

v1 v2 v3

v3

News Flash:Smart hacker proposes

Brilliant fix

v3*

v4 v5 v6 v7

v7v4

v8

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2020

Apache License Philosophy

“A license can ruin a perfectly good

piece of software”

– Jon Stevens

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2121

Interaction with the outside world

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2222

Interfaces with Third parties

u Developers– Code in the boss her time.– Community service “Time”

-- and to a lesser degree --

u Contributions– Code, tools, hardware– Services, Infrastructure– Money

u Support, bug fixes, binary builds, QA

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2323

Slight shift in motivations

u Past– Too large/complex to do it by yourself– Little lost by collaborating on the code

u Today– Plumbing is boring technology– Interoperability gets really easy if you

base it off the same source.

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2424

Guiding Principle

u ASF License– You can do what you want with it

– Though you cannot claim you wrote it (orpretend that your private hack is ‘the’version of apache).

– And if it breaks you get to keep the pieces

That’s a lot of freedom !

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2525

Working with Third parties

u Possible use by a third party– Productizing and packaging.– Commercial Support– Mix and match strategy with local IP into a

product or a service– Bespoke products

u Relatively simple to track flow of IP– essentially one way only

u We probably do not know about even half of whatASF code ends up being used in.

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2626

Third party Rationale

u With networked systems– Interoperability crucial

u Todays protocols and formats– Quite complex– Everyone needs to have them– “Hostile internet” requires rare expertise

u No glory in ‘plumbing’

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2727

Tradeoffs for third parties

u Benefit– Instant access to mature, well written,

commercial grade, interoperable code andfield proven code.

u Cost– Integration of third party ASF code– Externalized part of your product

– Little control over release processes– Open source releases have different drivers

– Developers now have ‘two’ hats.– Fix the open source code ‘proper’– Get a release out of the door

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2828

More costly (but tempting)

u Adding your own IP within the ASF code– Internal patch management– Custom build procedures– Need to maintain it– IP review procedures

u Long term– At some point it is easier to just

contribute the code and make it part ofthe flow.

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 2929

Developer Motivation

u The past– Most developers had an operational

background and responsibilities.– Scratching their own ‘itch’ in their corporate

role.

u Today– Significant body of people ‘paid’ to work on

ASF code - less focus on ops

u The future– More private individuals floating from place to

place drawing on plumbing experience– More and more interoperability focus

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 3030

Success area’s

u Infrastructure and Plumbing– http, xml parsers, java engines

u Interoperability– Reference implementation– Defacto Standard– Shared space to work on the first

implementation

u When in house development is– Not core to the organization– No value - does not set one apart

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 3131

Code contributions

u Requirements on all ASF code– Under the ASF license– Developers ‘safe’ from any claims– Needs to be alive

u Most code is developed under ASF auspice

u Though some are donated; as pure ‘seed’sor in a very mature stage.

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 3232

Code contributions (cont.)

u New project– Community driven

u Does it make sense– Synergy with other projects– OS Limitations and strengths

u Does it fit within the ASF– Standards and interoperability

u Is it viable ?– A community or people to work on it– Maintainable - a future– Body of expertize

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 3333

Code contributions (cont.)

u Some projects start out with a code base from a third party– More careful with IP– Maintain neutrality– Extra careful to be standards compliant and

interoperability focused.– Doubly careful to ensure viable community.

u Bootstrap with new code– Enough people who understand it– Culture transfer / influx management– Work through a contributors license with current IP

holder

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 3434

After the contribution

u Code as contributed– “Hands off” legally and socially

u Release schedules are suddenly communitydriven and out of reach.

u However– The license allows parallel development in

house. The community might just choose notto accept the changes

– You can try to ‘pay’ your developers to work oncode as “part of the community”.

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 3535

That’s it

© 2001 Covalent Technologies – Commercial in Confidence – 29 January 2001 - 3636

Questions?