Fuse is the most open, extensible connected-car system available. Extensibility is the key to Fuse giving people better control over their data, being interoperable with a wide variety of services and things, and being able to adapt to future changes.
Fuse is a connected car system. You might have noticed that there are a bunch of connected-car products on the market. There are several things that set Fuse apart from other connected-car products, but there's one that's especially important: Fuse is extensible.
When I say "extensible" I don't just mean that Fuse has an API, although it does have that. Fuse is extensible in four important ways:
- Fuse has an API — the Fuse API allows anyone to write applications that use Fuse.
- The Fuse API is user-extensible — Anyone can write services that Fuse users can install to extend the capabilities of Fuse.
- Fuse is open-source — Not only is Fuse open-source, it's based on an open stack including KRE and CloudOS. Because it's open-source, you can replace or modify it at will
- Fuse can be self-hosted — being able to self-host means that people have choices about their data and who controls it.
Fuse's extreme extensibility has important implications:
- User Control of Data — the architecture necessary to create Fuse's extensibility also supports selective data sharing through relationships with it's owner, manufacturer, drivers, and others.
- Openness and Interoperability — Fuse is a model for an open, interoperable Internet of Things rather than the closed Compuserve of Things that vendors are currently offering.
- Future Growth — Fuse can change and grow as connected-car products come and go. Fuse owners are not solely dependent on Kynetx to make Fuse work with new ideas, products, and APIs but can take matters into their own hands.
The following describe some of the ways that Fuse can be extended.
Using the Fuse API to Build an App
Fuse has an API that, much like any other API, accesses the core functions of the Fuse platform. Using the Fuse API, developers can add connected-car features to existing applications or even completely replace the stock Fuse app with something more to their liking.
The API isn't, strictly speaking, RESTful. Instead it's an event-query API. This is a result of the Fuse architecture and is necessary to support the more advanced forms of extensibility I describe below. We're still experimenting with Event-Query APIs to determine how best to design, use, and document them.
Extending the API with New Services
Fuse is constructed of persistent compute objects, or picos. You can think of a pico as a container for microservices. There is a pico for the owner, for the fleet, and for each of the vehicles in the system as shown below:
Because each of these picos can contain different sets of services, each behaves differently and presents a unique API to the world. Note that this is not just true of a class of picos (i.e. "owner" picos have a different API than a fleet pico) but of each individual pico as well. That is, my Fuse API could be distinct from yours based on the set of services that are installed. In this way, they feel more like personal computers than traditional Web 2.0 web services that present the same, single, non-extensible API for everyone.
Consequently, developers can build and distribute their own services on the Fuse platform. If the Fuse API doesn't do what you want, you can write an extension of the API that your users can install to enable that service.
One example of why you might do this is to add support for devices besides the Carvoyant devices that Fuse is based on now. You could, for example, add a service to Fuse that uses the Automatic device instead. Because each pico is a separate service container, you would then be able to have Carvoyant devices in some of your vehicles and Automatic devices in others and still see them in a single app with consistent vehicle and fleet functionality.
Replacing Existing Services
A direct consequence of the ability to extend the existing API and the fact that it's open source is the ability to replace parts of it wholesale. This allows keeping the old API for interoperability with other apps while completely changing out the code below it.
You could, for example, fork an existing service ruleset on Github and fix bugs, extend it's functionality. If the Fuse maintenance service doesn't suit your needs, but you want keep the existing API so that apps can continue to use it, it's possible to simply replace the maintenance service with one of your own.
Your new maintenance service could be just for you (i.e. installed on your own Fuse picos) or distributed more widely for other Fuse owners to use.
Our goal with Fuse is to create a connected-car platform that belongs completely to the owner of the vehicles. We've architected Fuse to respect privacy and let people choose what happens to the data about their cars and yet supports sharing and data transferability at the same time.
One important component of owner-control is the ability to self-host, even if most people don't take advantage of it. As an analogy, the fact that I can self-host email, if I choose, is an important part of the control I feel over my email account, even though I might choose to let someone host email for me at the moment.
Fuse is open source and is based on an open-source software stack:
Fuse and it's underlying pico architecture are based on an open source pico container system called KRE (GPL license) that runs a language called KRL. KRE runs on Apache. Anyone can install and run KRE anywhere they like.
Fuse uses a pico-management system we call CloudOS that will be open-source (as soon as I find time to fix some code issues). CloudOS provides core functionality for picos like lifecycle management, communications, and storage.
The software that provides Fuse functionality, the Fuse API, is also open-source (MIT License).
The Fuse app is not yet open source, but will be once it's done.
Using these freely available packages, you can not just self-host Fuse, but set up your own Fuse system if you choose.
One important benefit of self hosting is users are not even beholden to the account system that we're using for Fuse. They can use the code to create their own accounts in a system they control.
We've tried to make Fuse the most open, extensible connected-car system available. Extensibility is the key to Fuse giving people better control over their data, being interoperable with a wide variety of services and things, and being able to adapt to future changes.
Fuse and Kynetx
Fuse is an open-source project that's supported by Kynetx. Kynetx is behind KRL, KRL, CloudOS, and Fuse. Kynetx makes money by supporting Fuse and through selling Fuse devices and hosting.
The easiest way to get involved is to use the API. The Fuse App will be opened up to other developers soon and we welcome help in developing it and adding new features. If you're interested in extending the API or running your own Fuse system, contact me and I'll point you in the right direction.