Question

Following the popular topic of reusing the Leshan Demo in a production environment

#1614
#1598
#1260
#926
this is even addressed in the first lines of the F.A.Q.: https://github.com/eclipse-leshan/leshan/wiki/F.A.Q.#is-there-a-rest-api-for-leshan-server-demo-

Rationales

I have been recently contacted by a company that wants to make this a reality: a simple open-source lwm2m server usable in production.

First, after implementing something like that in closed source somewhat four times in the past (for different companies/customers), I find the idea of not re-coding the same thing every time appealing.

Also, there is a problem for people with smaller fleets or with on-premise requirements, because the solutions on the market are quickly quite expensive if you have only a hundred/thousand devices. This is preventing the adoption of LWM2M: it makes using the protocol difficult at a small scale and limits maker-style innovations.

In general, the feedback I got is that LWM2M is complicated, the spec is not light for sure, but building a solution is quite complicated. I think on the embedded device side we start to have more mature open-source solutions, some vendors selling ready-to-use LWM2M sensors, but for the server side, we just have Leshan library or proprietary SaaS solutions.

Ideation

I would limit the effort to an LWM2M device frontend being able to manage device connections and expose a stable API.

The server should be able to be started quickly and be self-contained (no external dependency like installing a database, or message broker) but still be capable of handling 100k of connection with H.A. with the right setup/configuration.

The demo UI would use the API of the server and we should limit it to what the demo is doing: a simple exploration/debugging of the LWM2M protocol. Writting a full-blown device management UI would be a different project than Leshan but the demo UI would give a starting point (and is actually what people are doing by either reusing the code or the UX)

Pro/Cons

In a nutshell, the main advantage would be:

• fostering LWM2M and Leshan adoption by allowing everybody to get to production quicker
• stop having multiple companies building somewhat the same LWM2M device server, and concentrate on building a shared better solution (I would prefer being paid to contribute to open-source than rebuilding the same proprietary code)

Of course, there are some drawbacks:

• the first one is scope creep for the project
• release cycle, which should probably be different than the LWM2M library
• maintenance efforts that need to be funded (I will contribute some, some of my customers probably too)
• business collision with current companies contributing to Leshan (even if it's not the same scope in my mind)

If the idea gathers some interest, I would probably proceed by prototyping and designing the core interface of such a server