on making standards organizations & open source communities work hand in hand
TRANSCRIPT
On making standards organizations and open source communities work hand in hand Benjamin Cabé, Eclipse Foundation@kartben - [email protected]
IEEE Open Source eventAustin, TX – May 20, 2016
Agenda
➔ What is the Eclipse Foundation?
➔ Eclipse Working Groups
➔ Keys to a successful standard
➔ Case studies / Success stories◆ LWM2M
◆ MQTT
Eclipse History
● Launched by IBM in 2001
○ Initial release of the Eclipse technology platform (Platform, JDT, PDE)
○ Founding consortium board comprised Borland, IBM, Red Hat……
● Eclipse Foundation formed in 2004
○ Independent not-for-profit organization formed in 2004
○ Definition of bylaws, membership model, initial IP process
Eclipse at a glance
● Organization○ 501(c)6 not-for-profit, USA (Delaware) incorporated,
headquarters in Ottawa, Canada
● License○ Eclipse Public License is the default ○ Other licenses possible by approval of the Board
● Focus areas
○ Most project implementations are in Java, but moving into web (JavaScript), C/C++, …
○ “Eclipse plug-in model”
○ Development tools, modeling tools, runtimes, web development, geospatial, Internet of Things, ….
● $5.0 million annual budget● ~250 members (13 strategic)● 25 staff● 75 events per year● 7 collaborative working groups
Eclipse Foundation by the Numbers
● 300+ projects (50+ new in past 12 months)
● 130 MLOC/year code change velocity● ~1200 committers● 9 million active users of Eclipse IDE
○ Leading IDE in Java, C/C++, PHP, …
● 1.5 million downloads/month (average)● 2.4 million unique visitors/month
Eclipse Community by the Numbers
The members of Eclipse
● 250+ members○ 13 Strategic Members
● 1200 committers, representing 60+ organizations
Strategic members:
Governance
IP Mgt
Projects & Process
Licensing ModelInfra-structure
Community&
Ecosystem
Foundation Services
Eclipse Development Process
● Proven process for creating successful open source projects and communities
● Open, Transparent, Meritocratic
● Vendor-neutral● Supported by professional
staff with years of experience
Eclipse IP Management
● The components that are identified as needed are submitted for review.
● Each component is examined from the standpoint of:○ Provenance○ License Suitability○ Patent searches are not done
● We use tools to help us
● Our committers do much of the work
Collaborative Working Groups
● Self-governing consortia and community managed under the Eclipse umbrella
● IP Policy and Development Process apply
● Can have their own brand
● Can have their own forge
● Can have their own licensing
● Dues can be zero or more depending on the needs of the group
PolarSys
● Focused on Open Source tools for the development of Embedded Systems○ Open Innovation to create better methods and tools
○ Computer Assistance and Automation
○ Certification to ease the tools qualification in complex certification processes
○ Very Long Term Support – up to 10 and 75 years
●
It is all about innovation
Open Source enables:
•Permissionless innovation
•Innovation through integration
•Far higher levels of experimentation
● You show progress with intermediatereleases
● You reach consensus (v1.0) ASAP, and your standard doesn’t arrive too late
SDO
Deliver in a timely manner
● Standard (including V1!) coversuse cases of the targeted industry/domain at large, not only of those companies involved in the standardization process
SDO
Be relevant
● You have a community of users
● You have a community of developers/integrators
● You have a community of solutions/services vendors
SDO
Community
● The IPR and licensing model can (almost) be understood by mere mortals
● The standard allows open source implementations
Adopter
Licensing
● There are other users of the standard
● You can recruit developers knowledgeable about the standard
● The standard enables new business models (integration/collaboration with other vendors using the same standards, etc.)
Adopter
Ecosystem
● You can evaluate the standardfreely
● There is a large variety of existing implementations of the standards (giving you even more freedom)
Adopter
Low entry barrier
Example #1OMA Lightweight M2MHow going for an open approach can
accelerate standard adoption & time to release
Example: OMA Lightweight M2M
● OMA LWM2M is a REST API for device management
● Based on CoAP and DTLS (IETF standards)
TimelineMay 2013: first OSS implementation in C
March 2014: contributed as Eclipse Wakaama
Jul. 2014: first public sandbox
Sep. 2014: new Eclipse Leshan project (Java)
Jan. 2015: OMA starts using Github
May 2016: 67 “issues” addressed, 17 Eclipse committers on LWM2M projects (from different companies), commercial adoption
Looking back…
Eclipse Leshan sandbox is used by many vendors for early prototyping,
integration tests, etc.
LWM2M takeaways
● Release often / have public drafts
● Support the community (e.g sandbox, testbeds, …)
● Encourage diversity (e.g multiple implementations)
● Listen to community input
MQTT?
● A Publish-Subscribe protocol for the Internet of Things○ Simple to implement
○ Quality of Service
○ Lightweight & Bandwidth Efficient
● Invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom)
● Version 3.1 released royalty free in 2010
● Open Sourced in 2011
IPR / Licensing
● No essential claims behind the MQTT (OASIS) standard (this is by design of the OASIS Technical Committee)
● Eclipse Paho source code is dual licensed:○ Eclipse Public License
○ Eclipse Distribution License (BSD-3)
⇒ redistributing the source code is not mandatory (important for embedded)
Eclipse Incubators - Paho
“ A permanent incubator is a project that is intended to perpetually remain in the incubation phase. Permanent incubators are an excellent place to innovate, test new ideas, grow functionality that may one day be moved into another project, and develop new committers.
⇒ Can be used to experiment with upcoming standard features ahead of the release⇒ May be used to feed the standard with new use cases, requirement, etc.
MQTT takeaways● Standard bodies complement the work of
open source communities
○ Writing code ≠ writing standards
● Open source can literally boost adoption of a standard
● More developers on the market
● OSS projects can fuel your standardization work with use cases, requirements, …
Key takeaways
● Growing an ecosystem is key, and OSS is one lever
● Open Source foundations have decades of experience in creating thriving communities of contributors, users and adopters
● Developers are the new kingmakers