[Contiki-developers] Contiki 3.x roadmap

Hi all,

(tldr: Contiki 3.x will be totally awesome, hard work needed by all of us,
let's look forward but let's start making some noise right now)

Now that the Contiki 2.7 release is done, we should start to look at the
future. Contiki has always been a cool platform, but it hasn't been all it
can be. We have a great system, with a large amount of developers pushing
improvements (so much that we have a hard time handling it - something we
need to fix), and the overall concept of using IP networking and low-power
radios really has shown itself to be very powerful. But we can go further.

Personally, I'd like to see that Contiki 3.x becomes the default choice for
low-power wireless systems and products built in 2014.

Building a disruptive connected product? Doing a cool Kickstarter project?
Doing a small personal project? Embarking on a large-scale wireless system?
Contiki should be the obvious choice.

This would be extremely cool to achieve, but will require a lot of work.

When we started Thingsquare, we knew that Contiki needed quite a bit of
work to become a production-quality platform and we dug into it. After 1.5
years, I think we've reached a point where the approach that we took with
Thingsquare has shown to be really, really useful. I'd now like to take
everything that we at Thingsquare has done and use that to form the basis
for Contiki 3.x. Here are the steps I'd like us to take:

* Make connectivity dead easy *

Contiki is supposed to make it easy to connect devices, but that dreaded
border router has always made this near-impossible. With Thingsquare, we
have taken a different approach that has turned out to work *extremely*
well: we let the RPL root be a simple IPv6-to-IPv4 translator. This device
has an Ethernet connection and just attaches to an IPv4 network and the
Contiki devices now are able to reach the IPv4 network, directly. This
approach is currently used in a number of commercial products and systems,
and there is already hardware available:
http://www.redwirellc.com/store/node/13

And, having seamless IPv4 access like this makes accessing a cloud backend
really easy, as we've demonstrated with the Thingsquare kit:
http://thingsquare.com/kit/

* Focus on IPv6 *

Contiki has a great IPv4 stack and a great proprietary Rime stack but for a
long time the IPv6 infrastructure in Contiki just wasn't up to speed. The
IPv6 stack code was hard to follow. The RPL mesh code wasn't very well
tested and neither was the 6lowpan fragmentation code. This last year, a
lot has happened in the IPv6 infrastructure: parts of the IPv6 stack has
been rewritten to be much easier to follow. The RPL code has gotten a
couple of significant overhauls. The 6lowpan code is finally stable. I
think we should now finally take the step fully into IPv6 land. The IPv4
stack and the Rime code will still be around, but we'll explicitly
focus much more on the IPv6 stack from now on.

* Focus on the ARMs *

Historically, Contiki has been possible to run on some really tiny devices.
While this is not bad per se, enforcing this constraint has sometimes
limited us. With an increasing amount of ARM-based microcontrollers and
systems-on-a-chip being available, we should leverage this. Most of the
recent ports in the Contiki tree are ARMs. At Thingsquare, we have looked
at ARM support for Cooja and while it seems like it is technically doable,
there is quite a bit of work left to make it come true in a reliable and
useful way. Nevertheless, larger chips is the way of the future and we
should embrace this.

* Leverage radio channels *

Contiki has always been bad at leveraging the plurality of radio channels
we typically have at our disposal. We need to change this. In fact, on the
sub-GHz bands it is even a requirement to use multiple channels. At
Thingsquare, we have a simple multi-channel protocol that works well, but
adding multi-channel support to Contiki needs us to get that radio API
finalized.

* Encryption support *

Encryption and security was always missing in Contiki. At Thingsquare, we
have successfully been using AES encryption in the netstack with great
success, and we're starting to see patches coming in that take advantage of
hardware-accelerated AES encryption on devices such as the CC2538. Time to
include all this in the mainline Contiki.

* Better TCP and UDP APIs *

The uIP stack was cool once, but it exposes a horrible API. At Thingsquare,
we have developed much simpler APIs for TCP and UDP sockets that makes life
a lot easier. Others have already successfully implemented protocols such
as MQTT on top of these abstractions. Having this in Contiki will make life
easier for a lot of us.

* General cleanup *

There are a bunch of old, bad examples and old, unused and unmaintained
platforms in the tree. Time to remove them.

* Larger group of mergers *

With an ever-increasing amount of pull requests, we should expand the group
of people with merge privileges to make the development go faster.

* More noise *

We all need to make more noise about Contiki. Tweet about Contiki. Blog
about Contiki. Talk about Contiki. Brag about your cool Contiki-based
projects. Post links to Reddit and Hacker News. This is something all of us
can do - it doesn't require a deep knowledge of the Contiki code.

Let's start talking about how to achieve all this, and what more is needed
to make Contiki 3.x the success is deserves.

/adam
-- 
Adam Dunkels, CEO
Thingsquare http://thingsquare.com/