TinyOS is an open source, BSD-licensed operating system
designed for low-power wireless devices, such as those
used in sensor networks, ubiquitious computing, personal
area networks, smart buildings, and smart meters. A
worldwide community from academia and industry use,
develop, and support the operating system as well as its
associated tools, averaging 35,000 downloads a year.
TinyOS has three mailing lists: help, devel, and commits.
Search Mailing List Archives
TinyOS is an open-source, open-community effort. As such, the design
direction of TinyOS is directed as much as possible by working groups
comprised of people with diverse experiences and backgrounds but a
common interest in TinyOS.
TinyOS Core Working Group (core)
TinyOS Network Protocol Working Group (net2)
TinyOS Tools Working Group (tools)
TinyOS IEEE 802.15.4 Working Group (15.4)
TinyOS ZigBee Working Group (zigbee)
TinyOS Host Mote Working Group (host-mote)
TinyOS TinyOS Alliance Working Group (alliance)
Sensor Network Testbed Working Group (testbed)
Sensor Simulation Working Group (sim)
Storage Working Group (storage)
TinyOS 8051 Working Group (8051)
Forming new Working Groups
The TinyOS Alliance provides a structure for individuals to become involved in the effort to establish and provide open code and protocols for embedded sensor networks. Working groups (WGs) are a major part of this structure. Working groups provide a forum for interested individuals from many different institutions and perspectives to collaborate on a common goal.
The TinyOS Alliance Steering Committee (SC) reviews proposals for the formation of new working groups, which should be sent to David Culler, the chair of the Alliance Working Group (culler AT eecs DOT berkeley DOT edu).
Working group proposals need not be long or verbose. Usually, a single page will do. A proposal should have 6 key pieces of information:
- Name: the proposed name of the working group.
- Charter: 1-3 sentences describing the scope and topic the group will work on.
- Members (and initial chair): A list of at least 3 people who will form the initial membership, as well as one additional person who will be the chair. The member list should include affiliations. While not a requirement, the SC strongly encourages that the initial member list include multiple perspectives. Working groups bring people together to work on a topic collaboratively; ideologically exclusive groups are contrary to this goal.
- Membership policy: A description of what process the group will use to admit new members. This can vary from group to group: core is based on consensus, net2 is voting, and alliance is invitation.
- Timeline: A description of the planned work products for the first six months or so. The purpose of the timeline is not to be a set of hard deadlines, rather to give more detail on the group's output goals as well as a general metric the group can use to assess its own progress. The timeline doesn't need to be aggressive.
- Overlap and Interactions: This identifies where and how work under the charter might overlap those of other working groups and how the new group plans to work with others.
Here is an example of what a proposal from net2 might look like if written in November 2006.
Working groups define the difference between what code is in tinyos-2.x-contrib and what code is in tinyos-2.x. A working group that includes implementations are part of its charter has one or more directories in the tinyos-2.x/ tree (generally but not always in tos/lib and doc/). Each directory is "owned" by a working group, who develops, improves, and maintains the code and documents therein. A working group confers with the core working group on how to name and were to put these directories. Generally, directories are created once a WG has files to check in, rather than when the WG forms.