We need to build a few things for that, most importantly peering (so that all gateways are available in V2 and V3 at the same time) and a V2 compatibility layer around the V3 Identity Server so that V2 services keep working. Then, we start deploying V3 PCN clusters to which you can migrate your applications.
Currently, our first priorities are getting a 3.0.0 tagged release out, fix development tooling and finish the Console.
I think V3 PCN clusters become available in preview in May.
No, you need to set that up yourself for the time being. We’re gonna do that, but we’re only going to do that right, i.e. with peering and the same user accounts, for a smooth experience.
Thanks for raising this.
We believe that there is no commercial value in a proprietary LoRaWAN stack. It is a solved problem. There are other open source LoRaWAN initiatives too. Note that all successful development tools (web servers, databases, frameworks, compilers, IDEs, etc) are open source. Offering a proprietary LoRaWAN server stack is either creating vendor lock-in for no apparent reason, or hiding a mess of a codebase.
When building an open, crowd sourced and decentralized network, we want to do that in a transparent way, i.e. doing it open source. Our stacks have been open source from day 0.
As for the community setting up their own networks; I rather have them use The Things Network Stack V3 for that than another stack. This is because V3 is built for the future, scalable, and it will support peering with the public community network, so that still it becomes part of the global network. Also, should these private networks one day be migrated to the public community network or to a commercial private network, then no APIs are changed and devices can be migrated seamlessly.
As for our commercial initiative setting up own open source networks; for the context, The Things Industries provides services and proprietary functionality for enterprise use. TTI offers SLA, commercial support, some advanced monitoring and alerting features, a scalable Kubernetes self hosted or private cloud hosted deployment, multi-tenancy, advanced integrations with commercial cloud platforms, an on-premises Join Server with HSM support, etc, then that is where value is added. And here again, if businesses start using the open source distribution but want commercial services later, we can do that seamlessly. Finally, our larger customers are happy that our stack is open source, because it is a more sustainable model (anyone can become a maintainer by forking) and it allows for easy quality assurance and auditing.