Where are we going with Tessel? Rust, Reach, and Fractal
The Tessel Project's mission is to create a fully open source hardware & software platform that makes it easy and intuitive to develop Internet-connected devices.
With Tessel 1, we tackled the "easy and intuitive" part of that mission statement. This is the main strength of the Tessel platform. Thus far, we've best fulfilled these two of our core philosophies:
Developer experience is paramount. Tessel should be the fastest way to build an idea, regardless of your background (or lack thereof) in electrical engineering or computer programming. Branding, documentation, and engineering design decisions should always take this into account.
Device design should focus on user experience rather than on implementation. Tessel uses high level languages and modular plug & play hardware (see philosophy here) so that device creators can fully prototype and test device functionality before worrying about optimization and implementation specifics.
We kept these values with Tessel 2, and began efforts to help developers scale. This pushes toward another core belief:
Tessel should be practical to use. Tessel as a platform cannot have a big impact unless it is cost effective, reliable, and available for purchase. It needs to be possible to purchase Tessel hardware at affordable prices, from quantity one up to production-level quantities (10,000+).
Where we are: the vision of Tessel 2
When we designed Tessel 2, we envisioned it as the basis of full-scale products. At the core of its design was the key idea:
People should be able to scale the tools they use for prototyping all the way into production.
If you're a Node developer, this prototyping --> production path feels familiar. Design is an iterative process; you understand technology and needs better as you build. Modularity lets you swap out packaged components according to your needs. Both Node.JS and Tessel subscribe to modularity. Node has proven out that this approach can scale to production.
In hardware, this is nearly unheard of. It is common to build a first prototype to show technical viability, then throw it out. For production, you start again from scratch to design a PCB that works with parts you can get at the x1000 scale.
With Tessel 2, we say: you shouldn't have to. This concept drove the following design decisions:
We chose components so that you can use the same ones in production. Every part used for Tessel 2 will continue to be manufactured and supported for a few years. Each can be sourced in low (100x) quantities.
Tessel 2 was designed in KiCad. This is perhaps the only free, open, fully-featured electrical engineering design tool available. Beyond publishing our design files, we want to make sure you can change and build on what we've created.
Tessel 2 is physically laid out so that you can easily remove features. A block diagram of Tessel's hardware corresponds to its physical layout, so if you don't need e.g. the ethernet port, you can remove it from the design (and save yourself the cost of the header) in your final product.
This takes open source hardware (OSHW) beyond just licensing. We want you to take our designs and use the parts of them you need in your own products. With your help, we can push the boundaries of OSHW. OSHW should be a platform for serious product development, not only a sharing marketplace for makers.
Openness promotes innovation. Tessel is fully open source, hardware and software, so that developers can create and build on these efforts, as projects and as products, without worry of legal hassle. This project seeks to expand and promote openness as a movement in both software and hardware, and be a leader in community developed hardware.
Now that we've shipped Tessel 2, there are several things we could do:
Keep adding features in software, like support for more languages or features
Build more modules to expand the platform
Work on a "Tessel 3" that is an evolution of the board
Work on a "Tessel X" that uses some of the same tooling but suits a different niche
Something else, which approaches the mission in a different way
This is where the Steering Committee comes in: we determine the project's vision and create plans for future development. This is our first major vision decision since we moved to an open governance model.
Here are the factors that drive this decision:
Mission and core principles
Logistical implications of our decisions
Critically, we need to pick projects that are well-scoped and highly focused. This lets us make measurable progress with the time and person-power we have available.
All of these projects are arguably worthwhile. Which is best?
Coming back to the core, we want to build the OSHW movement through our platform. Tessel 2's vision is well suited to this problem: the product lets people from varying backgrounds create products quickly and easily.
We've come some of the way towards making Tessel 2 the base for a product you can take to market. But we're not all the way there yet. Here are some of the issues we see:
It's not easy for most of the Tessel community to take the tools we've created so far and go to market. What do you do after you have a prototype– efficiency changes? Printing your own boards? Even if you knew what to do after building a prototype on Tessel 2, you might not know how to do it.
Connected device products tend to exist in a networked configuration. This usually involves several low-cost, low-power devices. A standard for usability in this vein is the ability to run on a battery for months to years. This makes Tessel 2 not well suited to a lot of product applications.
You can optimize to a point, but at the end of the day you are running JavaScript. This might not be as efficient or as reliable as you want your product to be. Additionally, you might have needs that are not supported in the language.
A path forward: Rust, Reach, and Fractal
We think we can work on these problems such that their solutions build upon each other. Here's the idea:
Work on improved Rust support. The Rust language executes code much faster and more robustly than JavaScript. It should serve well in production. The code is pretty legible, and it's a welcoming community with good documentation. We've already begun tooling for this on the tessel-rust repo. Work on Rust doesn't mean reduced support for or interest in JavaScript. We think they have the potential to play well together. Both will have first-class support.
Build on this for our Tessel Reach project: cheap, low-power boards. Think of a Reach board as a wireless extension cable from a Tessel 2 to a module– this is how it should feel to use one. You can see a bit more detail on this issue.
Use the JavaScript --> Rust compilation work to begin building the Fractal project. Fractal is software tooling to help you optimize your prototype into production. Explicit hardware requirements and memory-efficient software can let us begin to suggest hardware optimization. This would move toward comprehensible messaging. Examples might be: "Compile to Rust and reduce your file size of X to Y." "You aren't using Module Port B, remove it?" and "You're only using Y memory- you may want to consider this cheaper chip (link)".
This is the beginning of a plan. It's an outline of a roadmap of a vision, and it's going to be a lot of work.
For me, it's an inspiration. I want to work in the context of a grand plan. And it's my hope that this grand plan excites and inspires you, too.
When it comes down to it, that's the crux. What do you think? Is this something you're excited about building, and do these tools feel like they would be useful to you? Per our final core philosophy:
Community matters. This project should be a welcoming, inclusive, and respectful place. It’s important to communicate, to question, and to come together.
Please reach out on this issue, share your knowledge and use cases, and let us know what you think. We need to hear if you're excited, if you're unexcited, or if there's something in particular you want to do. Because in the end, the Tessel Project is built out of the community, and we can't do it without you.
Kelsey Breseman, on behalf of the Tessel Project Steering Committee
