Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8

Dagstuhl seminar 08142The Brainstorming

Group:Practices and Architecture

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 The Context

• The participants divided themselves in two groups Our group subdivided again after a couple of

hours

• Participants Gary, John, Pentti, Patrick Jilles, Stefan, Daniel, Øystein

• We decided that Gary should take notes, but his machine died so these are Øystein’s imperfect notes

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 Jilles’ opening remarks

• Case studies? [Jilles] Motorola has examples of failures [Jilles] Sun would be a good company to

explore – they have been through all kinds of openness and closedness

• [Jilles] Inner Source is a step towards an even wider ecosystem approach where one applies software from the outside even more than your own

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 Open source practices into a

corporate setting • what should be open, when?• defining what “open” means (the scope of “open”)• culture differences of openness

[Haugen] America is secretive, Europe less, and Norway very open, too open

[Mc Gregor] American managers are driven by the quarter, while Japanese typically are more long future oriented

• COTS rather then inhouse? [Mc Gregor] not always profitable [Haugen] Whether a company makes their own software(-tools) is a

pendulum that move back and forth• What makes an open source project a success?

Apache, Linux [Haugen] When do you know they are successful? [Haugen] There is a (big) difference between “real” open source

and Inner Source by the possibility to increase the community that contributes positively to the software

• [Mc Gregor] There is some middle ground. Eclipse is basically made by paid people. [and so is Linux]

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 Open source practices in a corporate

product line setting

• Commonalities between open source and PL distributed development Is there a size limit to when the PL thinking

is useful• [Jilles] The known use cases of PL successes are

fairly small – less than one million lines of code

Distributed organization may also reflect distributed goals, which is not exactly the same in an Inner Source setting where the goals are probably more specified

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 Capitalism and Communism

• The open source people are accused of being communistic, but they are really the capitalists! the success of their efforts is determined

through a market mechanism of survival within the community

the traditionalists are the communists believing in long term plans and decisions up front

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 More Gold on Open Source

• Open source development will typically in case of potential conflict between two solutions be discussion double development and after a while a winner will emerge

• Open source development tools/platforms (for technical people) tend to be much more successful than open source on consumer goods

• Open source developers are motivated by reputation increasing their skills they are professionals (mean age 30) Google summer of code –very good drafting method

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 Statements on Product Lines

• Product lines represent the commonalities that is where the money lies but the PL may still be very diverse

• Is there a conflict between the open source style of distributed decisions and the need to isolate commonalities?

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 Then we split up in 2 subgroups

• The Inner Source group Gary, John, Pentti, Patrick

• The Really Open Source group Jilles, Stefan, Daniel, Øystein

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8

The Really Open Source Group

Jilles, Stefan, Daniel, Øystein

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 “An open source model for solving

variability – a bottom-up approach?” • Examples of handling variability by open source community

Configuration Files (the very simplest DSL) Build tools (Make, Ant, Maven) (Ruby) Ports/Interfaces (XPCOM, DBUS) Plugins, Add-Ons, Emacs-modules, components (OSGI, ..) (published API) Deployment configuration (RPM (Red Hat), DPKG (Debian, Linux), FINK (open

distribution OS10) Versioning tools

• Decentralized (GIT , MERCURY, SVK)• Centralized (CVS, SVN)

Metamodeling• Ruby on Rails

• Open source in product lines understand how open source typically does variability gain awareness of the tools that they use need to use the tools that your community can buy

• open source tools have more acceptance in open source communities– fear of being taken away

• Should augment our ambition to a kind of reference model/methodology/process

Talking about “variability” rather than “product line” because open source talk about products with variability, but not about product lines

Eur

eka

∑!

367

4 P

rogr

amm

e, I

TE

A2

proj

ect

ip06

035

SIN

TE

F /

Øys

tein

Hau

gen

, 0

4-A

pr-0

8 “An open source model for solving

variability – a bottom-up approach?”