Investing in Our Developers Again

Let’s be honest about where we’ve been. For the last few years there hasn’t been much of a Tribot dev community to speak of. Collaboration between developers was rare, the path to becoming a scripter was effectively closed, and most good ideas died on the forums because there was nowhere for them to go. That’s on us, and this post is the first real step toward fixing it.

For a long time, building for Tribot meant fitting into a box we drew. If you wanted to write a script, you used the legacy-api or the script-sdk. If you wanted to share something useful with the community, your only real options were to copy and paste code into other people’s projects, or to convince us to bake it directly into the client or one of those APIs.

That second path was a trap, and we knew it. Every utility we pulled into the official APIs was one more thing we had to maintain, version, and carry forever. The APIs got heavier, so we got conservative about what we accepted. And being conservative about what we accept is, functionally, the same thing as telling the community their contributions aren’t welcome. Over time that quietly suffocated the dev scene. There was no real way to contribute, so people stopped trying.

We’ve spent the last while building our way out of that, and the picture is finally coming together. Here’s how Tribot development works now, and why we think it gives the community room to actually grow again.

The Problem With One Big API

The old model put us in the middle of everything. We were the bottleneck for every good idea. A scripter could write a fantastic pathing helper, an inventory abstraction, or a slick state machine, but there was no clean way for anyone else to use it without copy-pasting source or waiting for us to adopt it.

That centralization is what caused the bloat, and the bloat is what caused the caution, and the caution is what suppressed the community.

Breaking that loop meant giving developers a way to create and consume code without us standing in the middle of it.

Consuming Libraries With bundled(...)

The first piece is the tribot-dev-plugin, which is what your scripting setup will be using if you follow the Project Setup Guide. It introduces a Gradle function, bundled(...), that lets you pull open-source scripting libraries straight into your project as dependencies.

That’s a bigger deal than it looks. A useful library no longer has to live inside Tribot to be usable. You declare it as a dependency, and the plugin handles bundling it into your script the way the repo expects. If the library is published through JitPack, bundled(...) can even pull the source code, which makes it possible to produce repo-compatible source uploads from dependencies you didn’t write yourself.

So the unit of sharing is no longer a snippet someone pasted in the forums, or a feature we agreed to maintain. It’s a real, versioned library that anyone can depend on.

A Smaller Core, On Purpose: the automation-sdk

The second piece is our newest official API, the automation-sdk. It’s entirely interface-based, which lets us keep it open source while keeping our internals closed. A meaningful part of the API surface is now out in the open as a result.

Being interface-based comes with a real tradeoff: it isn’t as ergonomic as the legacy-api or script-sdk, and it’s missing a lot of the sugar we accumulated in those APIs over the years. That’s deliberate this time around. The automation-sdk is meant to be low-level, powerful, and basic, a foundation you build on rather than a finished, opinionated experience.

This changes how we think about the script-sdk too. The script-sdk stays as our mature, ergonomic base API, the one we still largely recommend for new scripters, and the automation-sdk sits underneath it as the lower-level, more powerful primitive. We’re done trying to pick one flavor and polish it into the one true API. We provide a solid base, and flavor lives on top of it where it belongs.

Bring Your Own Flavor: NullableLib

If the automation-sdk is deliberately unopinionated, then somebody has to supply the opinions. The good news is that now anyone can.

To show what that looks like, I released my own open-source scripting library, NullableLib. It’s my personal flavor of ergonomic scripting, extending the automation-sdk and adding back a lot of what feels “missing” when you work with the raw interfaces, shaped the way I like to write scripts.

What matters is that there’s nothing special about it. You can build your own ideal scripting API, your own set of utilities, or any kind of library you want, and release it through JitPack the same way, and other scripters can consume it with bundled(...). If you’ve ever wished the API worked differently, you don’t have to ask us to change it anymore. You can build the version you wish existed and share it.

As a result, your scripts can use any combination of libraries that developers like you have built and published!

To create your own, check out our guide on Creating Your Own Libraries.

A Path Back In: Tribot Community Automations

There’s also Tribot-Community-Automations, a new Tribot-maintained but community-driven collection of working open-source scripts.

These get uploaded to Tribot’s repo by staff, which means someone who isn’t a vetted scripter can still get their script in front of the wider community without making everyone run it as a local script. It gives non-scripters a way to contribute real, usable automations.

It also restores something we’d effectively lost: a path to scripter. Contributions to this collection are how we’ll evaluate new scripters going forward. If you want to prove you can write solid, trustworthy automation, this is where you do it. After years of that door being mostly shut, it’s open again. More details on this will be posted soon.

Somewhere to Show It Off

Finally, our Discord now has a dedicated open-source section for showcasing whatever you’ve built and want to share. If you’ve released script code under your own GitHub account, this is an easy place to promote it and get it in front of other developers.

It closes the loop on the whole thing: you can build a library, publish it, let others consume it with bundled(...), and show it off in a place built for exactly that. No approvals or vetting required.

Why This Matters

The common thread through all of this is that we took ourselves out of the middle.

• The automation-sdk gives everyone an open, low-level foundation.
• bundled(...) lets anyone consume open-source libraries without us adopting them.
• Libraries like NullableLib show anyone can ship their own ergonomic layer.
• Community Automations gives non-scripters a real way to contribute, and brings back the path to scripter.
• Discord gives all of it a place to live and spread.

We don’t have to be the gatekeeper for every good idea anymore, and we don’t want to be. By decentralizing the ability to create and consume script code, we’re betting that developers will collaborate more, share more, learn more, and build things we never would have thought to add ourselves.

We let the dev community wither for a while, and we’re not going to pretend otherwise. This is the first real step toward rebuilding it, and there’s plenty more to do. But for the first time in years, there’s room to grow on your own terms. If you’ve got something to build, we’d love to see it.

Come find us on Discord, and happy botting.