[Tinyos-alliance] mission/structure thoughts

[Kristin Wright]

Here are my opinions. Look forward to reading others' opinions.

Mission
--------
I think the first mission of the alliance (versus the alliance working
group) should be to facilitate user/developer community growth.
Generally speaking, the goals stated by attendees of Tuesday's kickoff
mtg included 1) stable base, 2) easing contribution, 3) growing the
community, and 4) promoting TinyOS as a marketing force. As an
open-source project, growing the community is probably the first step
toward achieving the others. Stability, for example, can be achieved
by first attaining critical mass of a base of developers and
users. This base communicates such that that the user-community's
needs are met by the developer community with respect to functionality
and stability. Contributions are evaluated by others, suggestions
made, code improved upon, code becomes reasonably stable.

Marketing presence may become a very important goal of the alliance, but
I think first we should focus on having something to market.

Corporate structure/Funding
------------------------------
I favor an approach more similar to the IETF where the finances are
separate from the technical. Funding-based influence stemming from
financial support may not always result in the best technical,
intellectual product because those making decisions are not
necessarily the best qualified technically -- they just have the most
money. Likewise, a talented interface designer may not be the right
person to decide how to market TinyOS. Obviously there has to be some
funding, but separate the financial issues from the technical issues.

Any stakeholders in TinyOS can have a membership in the TinyOS
Alliance funding branch; participation in one group would not
necessarily preclude or include membership in the other.

It would be important to have well-defined communication channels for
the financial arm to express their needs to those developing
interfaces and code and vice-versa. Too much control of the
interface/code from the financial branch may stifle innovation,
however. It would behoove both branches to cooperate with the other
since neither could exist alone.

The marketing of TinyOS would best be tackled in the funding branch.

Product
----------
In addition to an open-source code base, I believe that the technical
arm should create working groups that in turn create interfaces and
tackle problems.

Membership
-----------
Code base: Anyone can contribute code; meritocracy to me seems the right
answer for controlling code base. Two years ago, a diverse group agreed on
a reasonable policy we could revisit.

Funding branch: Anyone can join for a fee; it might be all right in
this branch to have more money buy more votes in marketing policy,
steering committee, etc, but not at the expense of design choices. The
funding branch is all about market reality and the almighty dollar (or
won or mark or...).

Participation
--------------
Code base: Minimal barriers to entry for code contribution will maximize
innovation and participation. Code should conform to certain interface
specifications, but I don't believe that we should require tests or
stability claims. Requiring testing might inhibit many innovative
contributions from the academic community which are often written by
already time-pressured students. Whereas a student would have normally
contributed their project, requiring stability tests might tip them to
the side of not contributing at all. We do want stability, but I
believe that can be achieved via other means.



Funding branch: $$ required.