Search form

Technical Steering Committee (TSC) Charter

Section 1. Guiding Principle. The AllSeen Alliance, Inc. (the “Alliance”) will operate transparently, openly, collaboratively, and ethically. The Technical Steering Committee (“TSC”) shall ensure that all technical decisions are made in an open and transparent fashion, and that all communication between and within Working Groups will be fair, open and consistent.

Section 2. Terminology 
Project – The most fundamental organizational unit. There will be many of these in the Alliance. Projects may formally become a part of the Alliance following approval by the TSC.
Service – Modular units of code produced by a Project that extend the core project code.
Working Group” – Logical grouping of Projects in a way that makes sense. Grouping is done by the TSC.

Section 3. Evolution of the Alliance Governance. Most large, complex open source communities have both a business and a technical governance model. The Alliance's technical leadership contains both a TSC Chair and Chairs for its Working Groups (“Working Group Chairs”). The Alliance's business leadership is instantiated in a Board of Directors (the “Board”). This Technical Steering Committee Charter reflects a carefully constructed balanced role for the TSC and the Board in the governance of the Alliance. As both the Board and the TSC gain more experience with the Alliance’s specific operations, the Board and the TSC have the ability to amend this Charter, subject to the policies and By-laws of the Alliance. The normal amendment process is for the TSC to propose changes using a simple majority of the full TSC to resolve conflicts, with these proposed changes subject to review and approval by the Board.

Section 4. Board’s Role in Setting the Alliance Strategic Direction. The Board will set overall Working Group policies in consultation with the TSC. These policies will describe: the Alliance's scope (the aggregate scope of Projects and Working Groups); the Alliance’s technical vision and direction; Project release guidance to the TSC (e.g., deliver via regularly-scheduled release trains); and other appropriate matters. Typically the Board will have no say on technical issues, individual Working Group or Project scope and direction as long as they remain within the scope and direction of the policies established by the Board.

Section 5. Establishment of the TSC. There will be a single TSC that will span all Working Groups of the Alliance. 

  • Membership of the TSC is defined in section 5.5 (b) of the AllSeen Alliance Bylaws.
  • The TSC shall be under the leadership of the TSC Chair.
  • The TSC Vice-Chair shall lead the TSC when the TSC Chair is unable to do so and will serve as an advisor to the TSC Chair on the direction and running of the TSC..

Section 6. Responsibilities of the TSC. Subject to such policies as may be set by the Board, the TSC is responsible for simultaneous release dates, release quality standards, technical best practices, monitoring technical progress, mediating technical conflicts between Committers and Working Group Chairs, and organizing inter-Working Group collaboration. The TSC will define the Alliance’s release vehicles. The TSC will serve as the Alliance’s technical liaison with other consortia and groups.

Section 7. The Alliance Operations. The TSC will establish rules of operation and process (the Development Process) for the Alliance and present the Development Process to the Board for approval as the TSC’s procedures are established or updated from time to time. 

(a) Projects. There will be multiple Projects under the Alliance. Each Project must be within such policies as may be set by the Board, have a well-defined scope and must work within that scope. Each Project will have a maintainer and function as an open source Project.
(b) Working Groups. As necessary, Working Groups shall be established by the TSC in order to logically group and coordinate appropriate Projects. The Development Process will include a process for the TSC to oversee and approve the progress of a Working Group, which will include consideration of the following criteria:

  • Cleanliness of code base
  • Ample and diverse Contributors and Committers to assure vitality of the Working Group.
  • Stability (e.g., presence of test suites and use of an appropriate source-code control system).
  • Predictability of releases
  • Alignment with the Alliance’s goals.

(c) Voting. The Development Process will include provision for a voting process to be implemented for decision making in accordance with the following guidelines:

  • For election of persons (TSC Chair, Working Group Chairs, etc.), a multiple-candidate method will be used. Unless otherwise designated by the Board, an Instant-runoff election will be conducted. (For example:
  • Multiple-candidate methods reduce to simple majority when there is only one position to be filled.
  • For Project internal decisions where no consensus can be reached, a vote will be taken and a simple majority will prevail.
  • A majority of the members of the TSC who have active voting rights shall constitute a quorum for the transaction of business, and the act of a majority of such members present at any meeting at which there is a quorum shall be the act of the TSC pursuant to section 5.5 (c) of the Bylaws.
  • A member of the TSC with suspended voting rights can not vote in absentia via email and they can not participate in email votes.  

(d) Contributions. The Development Process will include such processes as may be specified by the Board from time to time relating to the intake and license compliance review of contributions.

Section 8. Working Group Roles. Each Project has one or more Contributors, who produce code, and one or more Committers, who control technical direction. Each Working Group will be headed up by a Working Group Chair who sets overall direction for the Projects within the Working Group and reports to the TSC. Contributors and Committers, including Working Group Chairs, remain in the pay of their respective employers. 

  • A Working Group Chair who is disruptive, or has been inactive for an extended period (e.g., six or more months) may have his or her Working Group Chair status revoked by the TSC.

(a) Committers. For each Working Group there is a set of people with rights to commit code to the source code management system, called Committers.

  • The Committers will be the decision makers on design, code, and patches for their Working Group. Each Committer must be an employee of (or expressly sponsored by) an Alliance member company (at any membership level) and responsibly participate in the consensus decisions of the TSC.
  • Committer rights are earned via code contribution and community trust. Committers select and vote for new Committers, subject to TSC approval. A standard meritocracy model with new Committers will be approved and implemented by the TSC which will include provision for fully open code submission, review, acceptance, build, test, delivery, and support model.
  • Committer rights are per Project; being a Committer on one Project does not necessarily give an individual Committer rights on any other Project or Working Group.
  • Initial Committers will be specified at Working Group creation. Additional Committers will be admitted by a vote of existing Committers, subject to TSC approval, with appropriate process to handle dissent. If a Working Group has no active Contributors or Committers, the TSC may designate a Committer for such Project.
  • Committers are the best available individuals, but usually full-time for any components in active development.
  • Committers will use the process established in the Working Group Lifecycle document maintained by the TSC in its Development Process to accept/force modifications/reject code submissions and to add/delete Committers (and other development details).
  • A Committer who is disruptive, or has been inactive for an extended period (e.g., six or more months) may have his or her Committer status revoked by the Working Group Chair.

(b) Contributors. Contributors will generally work with their Committer and their Project’s sub-community. They contribute code or other artifacts, but do not have the right to commit to the code base. A Contributor may be promoted to a Committer by the Working Group’s Committers. The Contributors should rarely be encumbered by the TSC and never by the Board.
(c) Working Group Chairs. The Working Group Chair is elected by the Working Group’s Committers to act as the head of the Working Group, and represent the Working Group and its Projects on the TSC. The Working Group Chair must be from a member company (at any level of membership), and may be a Committer selected by vote from the Committers in the Working Group. If there is initially only one member of the Working Group, then that member is automatically the Working Group Chair. It is possible, and in some cases desirable, for one person to take on roles of Working Group Chair, Committer, and Contributor.

Section 9. Working Group Principles. The following relate to the Working Groups initiated by the TSC and the artifacts created therein:

  • Singularity: To the extent possible, there should be no overlap between the goals of the various Working Groups and artifacts created by them.
  • Cohesiveness: The artifacts created within each mature Working Group should connect appropriately to other mature / core Working Groups to form a cohesive system. (It is understood that this will not apply to artifacts that are stand-alone by design).
  • Non-interference: Services should work in any configuration and not create negative interference with each other’s functionality.
Two Bulls

Aaron has over 9 years experience working as a software engineer at early stage startups. He was the original CTO of Two Bulls and during this time was tech lead of both Breadcrumb and Blokify which exited to Groupon and 3D Systems respectively. He was also heavily involved in Augmented Reality and lead the development of Yolk 'Em which was featured in the Apple App Store's Best of 2012 selection. In recent years he has moved to the forefront of the IoT space as VP Software Engineering at LIFX before being lured back to work with a familiar team on Higgns. In his opinion nothing beats the feeling of leading and inspiring a group of talented people as you try to build something that changes the world.


As Co-Founder and CTO of Affinegy, Art Lancaster drives the company’s technology strategy and oversees development of Affinegy’s portfolio of products. Affinegy's software brings together the Internet of Things into a single, converged experience for all connected devices and services. Affinegy’s smart network management solutions automatically provision, configure, and manage the network and devices that are at the heart of new cloud-based applications and services delivered to homes and offices. Leading broadband service providers, Internet-enabled device manufacturers, and application/service providers have deployed Affinegy’s solutions to over 35 million customers around the world. Lancaster spearheaded the development of key technologies with a number of patents issued and pending and identified important industry standards like TR-069 and championed commercialization within the industry and the company's products.


Betty Zhao is the standard manager at Haier Group. She is responsible for standardization activities management and the technical contact person of Haier Smart Home Innovation Center.

Prior to working on AllJoyn, Betty has worked on IEEE 802.11/15 since 2008 and in Wi-Fi Alliance since 2012, and mainly involved in the developments of a variety of low power MAC technologies, such as 802.15.4e and 802.11ah, as well as 60GHz MAC technologies.

Betty received the Master Degree of Engineering in Communications and Signal Processing from Imperial College London.


Burak is Arçelik R&D Office Manager at METU-TECHNOPOLIS.


Dino is a Program Manager at Microsoft.

Dominique Chanet
Qeo LLC / Technicolor

Dominique Chanet is software architect at Technicolor Connected Home. For the past four years, he has been working on the design of various iterations of a publish-subscribe communication middleware targeted at Internet of Things use cases. Before that, he participated in the development of the DLNA stack that ships with Technicolor's home gateway products. Dominique holds a PhD in Computer Science from Ghent University in Belgium. The subject of his doctoral research was the application of link-time optimization techniques for the reduction of the memory footprint of operating system kernels in embedded systems.


Fabrizio is a Project Manager at Electrolux HP Italy S.p.A.

AllSeen Alliance

Biography coming soon.

AllSeen Alliance

Inhwan is a Principal Research Engineer at LGE.

John Cameron

John is VP Product at LIFX, the first AllSeen Alliance member company to bring a certified product to retail. John has spent 18 years building products, partnerships and teams to showcase innovation at the interface of cutting-edge technology and real-world people.

John was a founding partner at Alliance member Two Bulls, overseeing design and delivery of digital products for some of the world's leading brands and innovators from the pre-seed startup stage to successful exit, global brand maturity and beyond. John directed product development in connected play & learning, 3D printing, device discovery, augmented reality, retail point-of-sale, Google Glass and Leap Motion for clients ranging from Sesame Street and Disney to Qualcomm, GE and Groupon. John's background is in Computer Science (Software Engineering) and UI design, successful spin-offs include Breadcrumb (device-connected point of sale, acquired by Groupon), Eiatrack (regulatory tracking for electronics sector, acquired by TIA) and Blokify (consumer 3D printing for Cubify by 3D Systems).

Qualcomm Connected Experiences, Inc.

Marcello Lioy is director of engineering at Qualcomm Connected Experiences, Inc. In this role he serves at the development lead for the AllJoyn Core software team. Marcello has been involved in various roles on the AllJoyn project since 2010. Prior to working on AllJoyn, Marcello was leading the Data Services software team for Qualcomm's cellular modem group, which was responsible for Internet connectivity for 2G, 3G and 4G cellular modems as well as supporting other IP bearers such as 802.11. He holds a Master's of Mathematics in Computer Science from the University of Waterloo in Canada where he focused on networking and distributed systems.

Ram Jeyaraman

Ram Jeyaraman is a Technical Diplomat at Microsoft Open Technologies, a wholly owned subsidiary of Microsoft Corp where he has focused for more than 9 years on open standards, open source, and interoperability initiatives. Ram has actively participated in software industry consortia and standards organizations including AllSeen Alliance, OASIS, W3C, Web Services Interoperability (WS-I), and Java Community Process, playing a pivotal role in the standardization of a number of protocols in the areas of Web services, messaging, open data, and Internet of Things. Ram currently co-chairs the Compliance and Certification (C&C) Committee and chairs the C&C Working Group of the AllSeen Alliance, co-chairs the OASIS Advanced Message Queuing Protocol (AMQP) and the OASIS Open Data Protocol (OData) Technical Committees, and serves as a member of the OASIS Board of Directors. In 2014, Ram was recognized as an OASIS Distinguished Contributor. Prior to joining Microsoft, Ram worked at Sun Microsystems Inc., where he was the Specification Lead for J2EE Connector Architecture 1.5 and contributed to the implementation of RMI-over-IIOP protocol.

AllSeen Alliance

Shinichi Yuga is a Chief and Senior General Manager at Canon Inc., and has all responsibility for communication (e.g. new business / technology and legal items) between Canon products: Camera, Consumer Printer, and Enterprise Printer and partners. Shinichi previous worked in printer R&D for over 30 years, primarily as lead controller and driver engineering with OS companies.

For future news and updates, please follow or visit
11 months 2 weeks ago