Blockchain development on TON is more than just smart contracts in FunC and Tact. TON developers rely on many libraries and diverse dev tools to compile and test their smart contracts whenever they want to build anything, from dApp frontends to bots.

These libraries and tools are implemented in various languages, from TypeScript/JavaScript to Python. Each language usually has a library distribution channel like NPM.

Who maintains the libraries?

TON is a decentralized ecosystem; many significant contributions originate outside the core team. This has many advantages, like exponential growth and a fast pace of innovation, but it does come with a few challenges.

Libraries often originate from one of the businesses active in the TON Ecosystem. Let's take Jetton Minter as an example - this tool was initially created by Orbs. The project that invents a library usually maintains and owns it. Even if somebody in the community wants to propose a PR, it's up to the owning project to decide whether to accept it or not.

But what happens when one of these libraries becomes popular and other projects rely on it? This turns the library into some sort of shared infrastructure. Who should maintain it in this case?

The problem with single ownership of shared libraries

Let's consider the example of Orbs to examine the issues that arise when libraries are developed in private repositories or repositories of individual companies within the TON Ecosystem.

In the first days of Jetton Minter, the tool was hosted on an Orbs-owned repo and served from an Orbs-owned domain. The tool isn't really a core part of Orbs' business model. Orbs doesn't earn any money from it. It was created for the benefit of the community.

It works perfectly fine, so why not leave it under single ownership in the hands of Orbs?

Well, there are a few concerns:

• Orbs is developing other products that are core to its business model. Their core business activities will always be prioritized over something unprofitable or not at the core. What happens if they become too busy to maintain this tool properly?

• What happens if Orbs decides to use the popularity of this tool to benefit their business interests? For example, by introducing a Jetton listing fee.

• What happens if they fail to recognize a security vulnerability in this tool since they focus on other things? This will create a domino effect of vulnerabilities in all the other projects that depend on it.

The beauty of the open-source model

The open-source model gives simple answers to the above questions. The tool is only popular as long as its users find it beneficial. Many projects will depend on this tool only as long as there's a clear benefit from using it.

Shared libraries should always be published under a permissive open-source license like MIT. This provides a strong guarantee to the library's userbase that this library will never be abused. A permissive open-source license eliminates lock-in. If the library's maintainer fails its userbase, somebody will fork the library and create a better version.

The open-source model keeps libraries honest.

Surrendering shared libraries to shared ownership

Once a library or a tool becomes a popular shared dependency of many projects, it should transition away from single ownership. It is never in the community's best interest to keep relying on tools that are controlled by a single entity. This single point of failure comes with a high level of risk. You only need one malicious actor to cause major damage to a large part of the ecosystem.

The challenge with NPM

When you publish a TypeScript/JavaScript library for import by other developers, you normally publish it to NPM. The problem with NPM is that it doesn't follow the open-source no lock-in model. NPM packages have a well-known name that people import. This name, similar to a domain name, cannot be forked.

NPM names are given for free on a first-come, first-serve basis. This means that they're very prone to squatting. Names we could use are often registered, even if they're unused or abandoned. This also brings up a series of potential security issues. Is the NPM library ton-crypto official or not? Can you use it safely with your secret mnemonic? There's no way to know.

A stable home for shared TON libraries

To make the TON Ecosystem safer and more stable for developers, we have been looking for a home for popular shared libraries that can be transitioned to shared ownership.

The main requirement is that this place cannot be owned by a single company or person. It must operate under a code of conduct where a group of well-known contributors trusted by the TON Community makes decisions together for the benefit of the ecosystem. Whenever unresolved disputes arise, the TON Foundation should be invited to help resolve the issue to satisfy the included parties.

This home is for peripheral libraries and tools. Many of those are not maintained by the core team, so this home should be able to give write access to external contributors. Nevertheless, representatives from the core team will have admin privileges.

To achieve this, we created a new GitHub organization labeled after the primary ton.org domain.

We've intentionally chosen a destination outside the ton-blockchain GitHub organization since the latter is reserved for the core node infrastructure and protocol and is primarily maintained by the core team and not external contributors from the community. We've also chosen a destination different from the ton-community GitHub organization so it can focus on a smaller and more official list of core libraries, whereas the community is open for almost anything.

Additionally, we finally acquired the @ton NPM organization!

TON is now on par with other prominent blockchain ecosystems, like Solana, that list all of the official core libraries under one namespace.

Using an NPM organization gives us complete control of all names under this namespace. This resolves many of the challenges we had with NPM. Since all sub-names are ours, and users can easily identify safe official libraries, squatting is impossible under this namespace.

Migration

Many popular JavaScript/TypeScript libraries in the TON Ecosystem, like ton, ton-core, blueprint, and ton-crypto, were developed by different teams, such as TonWhales, Orbs, and Ton Tech, and maintained by them - credit given where credit is due. But now, those libraries have successfully transitioned to shared ownership where multiple contributors from multiple entities can collaborate.

• The shared ownership version of main JS/TS libraries are hosted on ton-org GitHub
• The shared ownership versions of those packages are published on NPM under the @ton organization

We urge all developers to transition to the new NPM packages, as the old ones will soon cease to be supported and be marked as deprecated.

In the spirit of decentralization, we call on teams to support this transition of popular shared libraries to shared ownership and move the original repositories to avoid unnecessary forks.

Happy coding!

Special thanks to Tal Kol for his help with the article and migration.