Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "ECE2011/Starting an Eclipse Project: The first 90 days… and the year that follows/Content"
(→Community) |
(→Three Communities) |
||
Line 204: | Line 204: | ||
==Three Communities== | ==Three Communities== | ||
[[Image:ThreeCommunities.png]] | [[Image:ThreeCommunities.png]] | ||
+ | |||
+ | ==Transparency and Openness== | ||
+ | * A '''transparent''' project invites participation | ||
+ | * An '''open''' project accepts it | ||
+ | A diverse community of contributors and committers is the best way to ensure the longevity of your project | ||
+ | |||
+ | ==Examples== | ||
+ | * All bugs/issues/features in Bugzilla | ||
+ | * Answer questions in forums/mailing lists/IRC | ||
+ | * Speak at conferences | ||
+ | * Webinars on EclipseLive | ||
+ | * FOSSLC, Parleys, ... | ||
+ | * Hang out where your community lives... | ||
==Why community is so important== | ==Why community is so important== |
Revision as of 09:48, 3 November 2011
{Copyright:Copyright © 2011 Eclipse Foundation, Inc. and BREDEX GmbH, Made available under the Eclipse Public License v 1.0}
Contents
Starting an Eclipse Project: The first 90 days…
Wayne Beaton, The Eclipse Foundation
Markus Tiede, Bredex
Agenda
- What is Open Source?
- Intellectual Property Management
- Configuration Management and Build
- Community
- Process
- Results
What is Open Source?
The term open source describes practices in production and development that promote access to the end product's source materials. Some consider open source a philosophy, others consider it a pragmatic methodology.
The Four Cs of Open Source at Eclipse
- Code
- Community
- Cleanliness
- Cwality
(Okay... Three Cs and a Q...)
Code
Code is... well... code.
Community
- Transparency invites participation
- Openness accepts it
Cleanliness
- Who owns the copyright?
- Is the owner really the owner?
- What license does the owner grant?
More later
Cwality (Quality)
- Transparent issue tracking, dev list discussion
- Reviews
- Inviting and accepting participation
- Diversity
BREDEX - Who we are & what we do...
- Jubula and EPP >> Eclipse for Testers
- BREDEX GmbH medium sized company located in Braunschweig, Germany - founded in 1987
- Eclipse events: Get-Togethers, Demo-Camps, Testing-Days
- since 2004 tool for automated GUI-testing - GUIdancer
Why open source? - Why Eclipse?
- commercial tooling does not sell well
- consulting, customizing and extending does
- open source tools outclass commercial tools
- BX good at development & consulting
- bad at sales
Why open source? - Why Eclipse?
- large companies require long term support
- lack of trust in small & medium sized companies
- entering the Eclipse world
- mature&stable ecosystem + large community
- BREDEX Eclipse based - GUIdancer RCP based
The beginning - day 1 (-14)
- 14th October '10 - initial public "Jubula" project proposal
- http://www.eclipse.org/proposals/jubula
- gathering interested parties
- internal processes
- restructuring - scalpel or chainsaw?
- extract ~ 95% functionality >> Jubula
- relocating - single SVN repository >> 3 git repos
- renaming - *.guidancer.* >> org.eclipse.jubula.*
- reviewing - What's ours? - What's not? ...
- restructuring - scalpel or chainsaw?
Intellectual Property Management
The Basics
- I am not a lawyer
- Ask your lawyer for legal advice
Intellectual property (IP) is a term referring to a number of distinct types of creations of the mind for which a set of exclusive rights are recognized—and the corresponding fields of law.
Assumption
Open Source Project wants to be successful
Assertion
Intellectual Property Management is important in every open source project
Clarification
Intellectual Property Management is important in source project that cares about adoption
Management?
- Who owns the copyright?
- Is the owner really the owner?
- What license does the owner grant?
- Does the license allow what we need to do?
- Is the license valid?
- If I use this code, will I be sued?
Contributions
Question
Do you care about adopters?
Third-Party Libraries
Pre-req
- Required library
- Provenance/license check is required
Exempt Pre-req
- Required library
- Exempted from provenance/license check
- Requires approval of PMC and EMO(ED)
Works with
- Optional dependency or one option of many
- Exempted from provenance/license check
- Requires approval of PMC and EMO(ED)
A CQ is required regardless of how the library is obtained
Welcome to the real world... 350k LoC
- Oct. - Dec. 2010 - analyze API / 3rd-party code usage
- Identified > 30 non-critical libraries / licenses
>> piggyback CQ in IPZilla + reuse / adjust API usage from Orbit >> low risk & cost: known API only different version
Welcome to the mean world...
- Identified critical (non-EPL conform) libraries / licenses
- GNU Lesser General Public License (LGPL):
- Hibernate
- Jubula main data storage: backend database
- replace ORM-Framework
- move to JPA and EclipseLink as persistence provider
- high risks & costs: three man weeks for API change
- JTopas - java string tokenizer and parser
- replace parsing library + subtle syntax changes
- use of SableCC (also LGPL) artifacts which are non-LGPL
- Hibernate
>> do things early! - high risk & cost & test effort
Opening (y)our source - day 1 to 95
- first feedback of initial triage
- conforms to Parallel IP >> preliminary approval
- though > 20 textual references to clarify / adjust
- second source code contribution: 5th Jan
- initial source code check-in: 13th Jan
Eclipse infrastructure and build environment
Application Lifecycle Management at Eclipse
- Bugzilla
- Git
- Hudson
- Test hardware
- Windows, MacOS, Linux
- Maven/Tycho
- Eclipse/Mylyn
Jubula's release engineering requirements
- Kill two birds with one stone - Jubula & GUIdancer
- single source: share & reuse the same Jubula core
- manage different targets / platforms / environments
- Jubula: maintenance (3.7.0, ...), current (3.7.1) & upcoming (3,7.2, 3.8, ..., 4.2, ...) versions
- GUIdancer: last stable major Eclipse service release
Jubula's release engineering requirements
- simple artifact creation
- bundle, fragment, feature, product, p2
- simple artifact signing
- multiple artifact packaging levels
- developer build
- build in local and remote infrastructure
- Eclipse Packaging Project artifacts
Releng of Jubula @ eclipse.org
- Maven3/Tycho 0.12.0
- CI @ eclipse: hudson.eclipse.org - nightly builds
- Works like a charm!
- automagical dependency management
- p2-based target platform definitions + maven profiles
- git - fast, reliable & powerful
- currently ~70+50 artifacts: bundles, features, p2-repos
- constantly growing >> scales very well
- but: recent stability issues in remote CI proved / required flexibility
Community
Three Communities
Transparency and Openness
- A transparent project invites participation
- An open project accepts it
A diverse community of contributors and committers is the best way to ensure the longevity of your project
Examples
- All bugs/issues/features in Bugzilla
- Answer questions in forums/mailing lists/IRC
- Speak at conferences
- Webinars on EclipseLive
- FOSSLC, Parleys, ...
- Hang out where your community lives...
Why community is so important
- we successfully entered stage 1 - getting used & being promoted
- currently: issue single sourcing
- huge synergy potential
- BREDEX ~ 5 committers
- Eclipse ~ 4 million users
- 1% potential users >> 40k
- 1% participate / extend >> 400
- collaboration / integration with other Eclipse projects ( > 60)
Community channels
- for beginners / advanced / experts
- Website eclipse.org /jubula
- Forum eclipse.org/forums /eclipse.jubula
- Webinars live.eclipse.org /node/1031
- Wiki wiki.eclipse.org /Jubula
- Blog(s) planeteclipse.org
- for developers
- Mailing lists
- for testers
- Bugzilla bugs.eclipse.org/bugs
- for people like you: talks at conferences, demo camps ...
Process
Joining the release train - side effects
>> being a part of Indigo - www.eclipse.org/downloads >> create an own Eclipse Package "Eclipse for Testers"
Joining the release train - side effects
>> Eclipse schedule - very well planned / structured >> long beforehand integration / aggregation runs
Joining the release train - side effects
>> externally determined timeline >> largely unknown requirements = costs
Joining the release train - side effects
>> major problems synching in- and external deadlines and requirements
We are agile (again)
- recovered from these effects after 4 months
- In sync with the Eclipse schedule + 1 week
- accepted external timeline
- focus on internal requirements
- completion of major technical & process adjustments
- 100% compatible: Jubula, "Eclipse for Testers" and GUIdancer
Results
Jubula downloads - (no) rocket science
- BREDEX downloads - pre open source ~ 50 per month
- Eclipse for Testers
- Indigo ~ 25k downloads (8k per month)
- Indigo SR 1 ~ 13k downloads (8k per month)
Our plans for the future
- EclipseSource: RAP - ARIA collaboration
- extend community
- awaiting feedback & requirements
- increase Eclipse inner-/inter-project usage
- e.g. EPP testing
- open more source
- non EPL conform code jubula_lab @ eclipse labs
- functional UI tests and AUTs
- participate Juno