1 / 12

Dagstuhl seminar 08142 The Brainstorming

Dagstuhl seminar 08142 The Brainstorming. Group: Practices and Architecture. 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

idania
Download Presentation

Dagstuhl seminar 08142 The Brainstorming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dagstuhl seminar 08142The Brainstorming Group: Practices and Architecture

  2. 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

  3. 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

  4. 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]

  5. 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

  6. 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

  7. 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

  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?

  9. Then we split up in 2 subgroups • The Inner Source group • Gary, John, Pentti, Patrick • The Really Open Source group • Jilles, Stefan, Daniel, Øystein

  10. The Really Open Source Group Jilles, Stefan, Daniel, Øystein

  11. “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

  12. “An open source model for solving variability – a bottom-up approach?”

More Related