[Tinyos-alliance] Some thoughts on the structure of the Alliance/Forum

[Ramesh Govindan]

Folks,

In trying to summarize for myself the discussions from last Tuesday, I 
came up with the following writeup. This lists the things I thought we 
converged on, things that we didn't achieve consensus, and my own 
opinions on the various aspects.

Just thought I'd post it in case others find it useful to have the issues 
framed this way.

Regards.
-- 
Ramesh
http://cs.usc.edu/~ramesh/

What should be the goal of the Forum?
-------------------------------------

It would help to define the goal precisely, since that might help us
resolve some of the tensions related to the other choices.

We discussed several possible goals, and combinations of these. I
didn't get the sense that we converged on one or the other.

	- provide a forum for the development of tiny OS with
	continued support for innovation as well as industry
	advancement
	- develop an enterprise-class TinyOS: highly stable code base,
	with carefully vetted extensions
	- provide a forum for standards development
	- engage in marketing and advocacy for TinyOS and embedded
	systems in general.

My own take:

It seems to me that the immediate problem seems to be to turn over the
development of TinyOS (and related software) to a community-governed
organization, what the right kind of structures and IP agreements in
place to foster the industry that is developing around TinyOS.

This seems like a good starting goal.

I do expect, as the years go on, that the organization will morph into
one that either provides a forum for standards development, or one
that develops software, and/or one that engages in advocacy. However,
it seems too premature to attempt include any of these as goals for
this fledgling organization. However, I think it is crucially
important to put in place mechanisms by which the organization itself
can evolve.

Charter of our group
--------------------

If we buy the above discussion, it seems to me that at the very least
the charter of our working group should be:
	- to define the corporate structure of the organization
	- to define the work structure of the organization (how work
	gets done: working groups, who gets to participate etc.).

We then have two choices:
	- we can, in addition, work out other details (e.g. the IP
	structure, the funding structure)
	- or, we can *recommend* the high-level principles for these
	structures (e.g. TinyOS should use an XYZ source license), but
	leave the details to the new organization.

I prefer the latter, but not strongly.

Corporate structure
-------------------

Perhaps there are more, but I can think of two distinct functions in
this organization:

	- a technical advisory function that keeps an eye on the
	evolution of the TinyOS architecture overall, and tracks the
	progress of the technical development of TinyOS, the outputs
	of its working groups etc.

	- an organizational advisory function that concerns itself
         with industry interaction, legal and IP issues, evolution of
         the organization itself, membership issues and so on.

There are, of course, several possible structures that can accommodate
these functions. A single board of directors can do this. Separate
technical and organizational boards can also do this.

I don't have a preference, but it seems like the issues are complex
enough that we might have two separate boards to start with.

Industry issues
---------------

There are several issues that I don't have expertise with that were
discussed on Tuesday, but it seemed to me that we were leaning
towards:
    - allowing corporate membership
    - setting up the IP structure so industry can benefit, and setting
    up some incentives for membership (so members get more
    than non-members).

Working group structure
-----------------------

If we agree that our goal is to define a community supported
organization for TinyOS development, and most of the work of the
development happens in working groups, then participation in the
working groups should be open to any or all individuals (and
participants participate as individuals, not as representatives of
their company).

How do we structure the working groups? There are, again, two choices,
and these are perhaps not mutually exclusive.

- Long-standing working groups that are chartered to develop various
   software subsystems (Routing, Management etc.).

- Short-term working groups with a fixed mandate (develop a routing
   protocol for this; advise on what the IP structure of the
   organization should be etc.), and a fixed duration (usually 1 year to
   18 months). These working groups could be constituted in a couple of
   ways:
      - grass-roots: e.g. someone has a neat idea for a piece of software,
   has already developed a preliminary version of it, and wants to make
   it part of the TinyOS core.
      - board-chartered: e.g. the technical advisory board could charter a
   group to architect TinyOS N, the organizational board could charter
   a working group to examine whether the forum should morph into a
   standards organization.

Either way, the outputs of a working group would be documentation AND
(for technical groups) a working implementation that has been deployed
in a nontrivial environment, perhaps?