[Tinyos-alliance] TinyOS alliance - my point of view.

[Adam Wolisz]

Here come my statements

Mission:
-----------
In my opinion:  development and dissemiantion of SYSTEM SOFTWARE for
sensor and actuator networks based on/developed around the TinyOS.

WE have discussed quite a bit the scope (just the OS; also 
protocols,,etc,) In my opinion
this should be a dynamic process, organized around defining TECHNICAL 
WORKING GROUPS
(having - like in IETF or IEEE) a clear statemtn of mission within the 
general mission of
the Alliance.
I will further refer to the scope of this system software as T+

Corporate Structure - FUnding 
I beleive that there are three separate communities which we have to 
account for while
discussing this issue.
a/ the research community involved in technical aspects of the T+
b/ the industrial community interested in (different forms!) of adopting 
T+ in its products,
c/ the community at large, which will START thinking about using 
relevant technologies, which should have
    easy entry to usage, become attracted, and might - later - move to 
the cathegory a/

I believe that the ALiance has to include - in deifferent ways! - the 
community a/ and b/ while having
in mind and addressing the need of c/

I believe that the whole aliance should be composed of:
i/ board- elected for a period of ???  (my vote - 3) years.
ii/ working groups - established for a fixed time, with 
extension/renewal/redefinition possibility,
    with a clear mission.
iii/ office ....long term staff.

In fact, I believe that we need to types of membership: corporate and 
personal.

Corporate members offer money. This are companies interested in 
exploiting T+,
or just wanting to support T+ or...    should
be accepted purely on the basis of their paying dues.
 This would entitle them to proper acknowledgements,
links...etc....and possibility to nominate (jointly, as the community of 
corporate members!) a minority
- say 2o%?  - of the board members. Money from the dues is used for the 
office (assuring running the
services, publicity, editing documents.. and - possibly supporting some 
technical work , see under
 technical inout/output) . Staff is hired by the board.

Personal members are individuals who offer their active contributions!
They declare the willingness to join and achieve so the Candiadte member 
status,
for achieving full memeber status they have to show some - predefined -
level of activitiy in at least one of the working groups. (this might be 
like  in IEEE - attending a given amount of
meetings, or attending a given amount of meetings plus some 
contribution.... ) should be pretty informal,
in my opinion managed by the working group itself.  The eprsonal 
memberschip is ended by a declaration
of the person, or - after a dermant period - because of longer time 
inactivity....(ruzles to be defined)

Working groups are created by the decision of the Board - on basis of a 
proposal presented by a group of
members.
Personal members will nominate - in some voting process - 60 % of the 
members of the board.
The old board will nominate 20 % of the memebrs of the new board (care 
of continuity).


THE FIRST INSTANTIATION of the board - for a shorter - one year? - 
organizational period
will be nominated completly by the initative group...(or extended 
initiative group).

Intellectual Property rules - cooperation with the INdustrial partners

I am in favour of allowing free acess to the results achieved/collected 
by the Alliance.
In case of the code proper open source policy should be introduced.

On the other hand, Industrial companies are encouraged to develop 
products including the
"professionalised" T+
I am not an expert on the legal issues... but could get some of our 
experts involved in the discussion
once we agree on general line...

Companies should be also interested in developing porducts "around T+" - 
management tools,
installation support...etc  

Input/output
 
Any candidate member (i.e. person who registers with her/his personal 
data and declares the willingness
to contribute) can contribute code. THis code will be placed in a 
properly maintined (by the office)
UNVERIFIED CODE REPOSITORY:

In parallel I strongly believe that we need also a REPOSITORY OF 
RELIABLE CODE
Movement to the later should be preceded by checking- enhancing the 
quality of the documentation
and a dependable  testing process - this might be a peer-testing
within the working group community, or  a process supported by the staff 
(if we will have enough resources, and
subject to selection of items considered of proper importance/interest.

The special , most important output will be definitions of interfaces, 
requirements and tests for conformity
with the definitions. developed by the working groups. Again the office 
might offer some help of one. two professionals
to the working groups.

I consider also the proper information about T+ (maintaining a 
repository of informative
material - papers, tutorials) etc.   as an important output. 

best
Adam Wolisz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-alliance/attachments/20060122/d7134625/attachment.htm