View
219
Download
0
Embed Size (px)
Citation preview
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