tep120.txt

tinyos-2.x.rar

==============================================
TinyOS Alliance Structure
==============================================

:TEP: 120
:Group: Alliance Working Group 
:Type: Informational
:Status: Draft
:TinyOS-Version: All
:Authors: Philippe Bonnet, David Culler, Deborah Estrin, Ramesh Govindan, Mike Horton, Jeonghoon Kang, Philip Levis, Lama Nachman, Jack Stankovic, Rob Szewczyk, Matt Welsh, Adam Wolisz 
:Draft-Created: 17-April-2006
:Draft-Version: $Revision: 1.7 $
:Draft-Modified: $Date: 2007/06/21 19:38:42 $
:Draft-Discuss: TinyOS Alliance <tinyos-alliance at mail.millennium.berkeley.edu>


.. Note::

   This memo documents a blueprint for an open alliance aroung
   TinyOS for the TinyOS Community and requests discussion and
   suggestions for improvement.  Distribution
   of this memo is unlimited. This memo is in full compliance with
   TEP 1.

Abstract
====================================================================

This memo describes the goals and organization structure of the TinyOS Alliance.
It covers membership, the working group forums for contribution, intellectual
property, source licensing, and the TinyOS Steering Committee (TSC).

1. Charter
====================================================================

.. TinyOS Alliance Charter::

Formulate a legal and organizational framework for an alliance that
can facilitate the continued advancement of the open embedded network
ecosystem around TinyOS and support the activities, interactions, and
development of the worldwide academic and industrial TinyOS community.

2. Overview
====================================================================

This memo defines a blueprint and conceptual foundation for an open
alliance that fulfills the above charter. It defines the following ten
aspects of the alliance:

   * Mission
   * Legal structure
   * Organizational structure
   * Membership criteria
   * Working group processes
   * Election process
   * Intellectual property
   * Source licensing
   * Funding
   * Work products

We (the Alliance) recognize that each of these aspects contributes to the 
whole, is inter-related and needs to be consistent overall.  This document 
attempts to address them sequentially, recognizing that each depends on the 
others.  It draws on lessons from several related
organizations, although each of these also has significantly
different goals from those set out in the charter.

1) IETF - Open protocols, technical documents 
2) OSDL - Stable, Enterprise Linux
3) Apache - Suite of open source tools
4) Zigbee - Network layer and marketing for 15.4
5) OSGI - Service layer
6) FSF - Foundational software

Examining the structure and policies of these organizations helps
determine what the Alliance can borrow from them, what it must
do differently, and why.  We (the Alliance) draw most strongly upon the 
IETF, even though that organization was
focused around creating and standardizing protocols, rather than
developing a code base.  Its emphasis on rough consensus AND
running code placed issues akin to those we face near the fore.  We
share the view that technical excellence is a primary goal and that
the organization should be structured to sustain and overall cohesive
architecture.  In our case, it is represented by high quality
reference implementations and standard APIs, as well as techical
documents and protocols.  We share an emphasis on broad participation
centered on the contributions of individual members.  

We encourage industrial involvement, industrial development, and
industrial support.  The organization is welcoming to companies, but
it keeps financial support and marketing activities (while both
important) at arms length from the technical process.  We share the
concept that proper behavior of participants and member companies is
most strongly shaped by code of ethics, captured in organization rules
and social norms, rather than threats of legal repercussions.  The
broader marketplace is a more effective enforcement body than any
technical organization.  Thus, we ask that participants declare
relevant intellectual proprt (IP) that they are aware of, rather than 
force a strict
accounting of potentially relevant IP.  We encourage the development
of open solutions that are implemented without the need for particular
proprietary IP.  In the IETF, this is addressed by the requirement of
multiple interoperable implementations before standardization.  If
such implementations can be developed without legal issues, it is
likely that other non-infringing implementations are possible.  Like
IETF, we seek a lean bureacracy and mostly volunteer organization.

From OSDL, we share the goal of developing a stable, high quality
version of an open source system.  This suggests that the alliance
have a strong role in developing test suites and broadly accessible
testbeds, as well as structures for sharing development resources.
However, we avoid the OSDL structure of the scale of monetary
contributions dictating technical oversite.  We are not constrained by
a GPL license structure, as is the OSDL.

From Apache, we draw the strong sense of a technical meritocracy
centered on individual contributors.  We seek to permit a loose enough
consortium that there can be a lot of individual innovation,
especially in areas of tools, devices, and new platforms.  We also
seek to retain the notion that credit should be given to authors.  In
Apache, giving the copyright to the Apache organization exchanges the
value of the brand for technical contributions.  For a broad alliance
representing many universities and large companies, such a copyright
scheme is likely to be an untenable barrier.  Instead, we seek to
provide a simple source license regime with technical tools for giving
credit and strong social pressure to comply.

From Zigbee, we share the goal of providing marketing support for the
accomplishments of the alliance and that we should seek to define
standardized services, not just protocols.  We recognize that the
alliance serves a useful function in being a point of allocation for
various namespaces, but that this important function should not be a
tool for extracting financial contributions.  We see the value of an
IP pool to give confidence that the standard can be adopted without
becoming entrapped later by IP terms, however, we also see that such a
pool presents a very significant barrier.  Moreover, it does not
prevent members from obtaining IP to use it to their advantage with
other members of the alliance.  It also does not constrain non-members
from obtaining blocking IP.  It does discourage contributions that
might pull IP into the pool.  We prefer a process of declaration and
multiple implementation. Section 7 goes deeper into how the Alliance
manages the issues and complexities of IP in an open organization.

3. Mission
====================================================================

The mission of the TinyOS Alliance is to provide a forum to facilitate:

  * the continued growth of a healthy TinyOS developer and user community
    with support for innovation as well as industry advancement, 
  * the development and maintenance of a stable, technically-sound base of
    TinyOS technology and surrounding tools through the creation of
    standard interfaces and protocols, vetted extensions, open reference
    implementations, technical documents, testing and verification suites,
    and educational materials, 
  * the contribution of innovative technology from a world-wide research 
    community and the maturation and dissemination of these
    contributions, and
  * the promotion of the technology, the community, and the impact of networked 
    embedded systems.


4. Organizational Structure
====================================================================

The Alliance has a technical advisory function: guide the evolution of
the TinyOS architecture, formulate and track progress of working
groups, and provide an open and impartial process for technical
documentation.  It also has an organizational advisory function:
manage industry interaction, legal and IP issues, evolution of the
organization itself, membership issues and so on.

We follow an approach that starts small and grows the structure as
needed. The focus should be on the working groups. Working groups are
not limited to technical functions; they can be formed to promote
developments, markets, etc. Beyond the working groups, the
organization should remain lean, relying primarily on volunteers. We
want to avoid creating a situation where the organization becomes
focused on its own growth and pre-eminence at the expense of the
larger community and technical agenda.

Technical directions should be driven by merit and overall soundness,
and built on consensus.

The Alliance consists of a non-profit corporation with a Board of
Directors, a small support staff (primarily volunteer or outsourced)
and a Steering Committee. The Steering Committee oversees a collection
of Working Groups, each with a Chair and Members.

4.1 Steering Committee
---------------------------------------------------------------

In the steady state the Steering Committee will consist of the chairs
of working groups plus a handful of elected members at large. Tenure
of a position on the Steering Committee will consist of two years with
opportunity for renewal. We want to see a vibrant, engaged, and
constantly evolving leadership while allowing for long-term and
committed members.

Initially the steering committee would be formed from working group
chairs plus some subset of the Alliance working group members.  This
initial committee will be responsible for putting in place the
membership and elections processes, which will then be utilized to
form the regular Steering Committee.

The primary role of the Steering Committee (SC) is to oversee the Working
groups (WGs). This means establishing WG policy, providing appeals
process, managing WG creation/extinction, arbitrating between WGs, and
supervising activities to resolve conflicting directions and moving
the process towards overall architectural coherence.

The SC is also responsible for reviewing and approving all TinyOS