I haven’t been active in backgammon for a couple of years, for various reasons, but the most important one is probably lack of adequate, modern software. Don’t get me wrong, I like gnubg, but certainly not for its looks. ;)
Why is computer chess so much more popular than computer backgammon? For chess, there is a completely free, fresh, modern online platform lichess.org <http://lichess.org/> which can easily compete with its most successful proprietary and commercial counterpart chess.com <http://chess.com/>. There is a very active forum talkchess.com <http://talkchess.com/> which covers all kinds of computer-chess-related topics. There is a ”protocol” UCI - albeit an ugly hack - that makes it really easy to develop a new chess engine because connecting it to a GUI or to a bot playing on Lichess is a piece of cake. And - my impression - the big success of computer chess, especially since the pandemic also gave a popularity boost to over the board chess. So, what is actually missing for backgammon? 1. A Connection Protocol Chess has UCI and CECP. Both are ugly and not very nicely documented. It should be really easy to come up with something better. 2. Server-Side Evaluation and Analysis Chess doesn’t need a library for that. Everybody is just plugging in arbitrary engines via UCI and/or CECP. In order to turn gnubg into the backgammon equivalent of Stockfish, only client code for the new protocol is required. 3. Client GUI Not strictly necessary but Chess has a couple of desktop clients that allow plugging in one or more UCI/CECP compatible engines. They are mostyl used by strong players and developers that need advanced features. The vast majority of players are happy with what lichess.org <http://lichess.org/> or chess.com <http://chess.com/> has to offer. Anyway, writing such a desktop and/or mobile client with Electron or so shouldn’t be too hard. 4. Browser-based Evaluation and Analysis The project https://www.npmjs.com/package/@nodots-llc/gnubg-hints has already made the core of the backgammon logic in gnubg available as a TypeScript/JavaScript library by separating the backgammon logic from the GUI. It should be possible make the run in the browser with Emscripten. 5. Cheat Detection I’m not an expert for this. And I don’t know to what extent cheating is a problem in backgammon, but I guess that every server that offers online matches will sooner or later face the problem. 6. Free Backgammon Server Yes, there is FIBS, but it has drawbacks: - requires a client, and the existing ones are all ugly and outdated (correct me if I'm wrong) - uses a ”protocol” that was designed to be used by humans and is also not documented - is closed-source - is telnet based, which makes it awkward to implement a browser-frontend - seems to be fallen out of time - … If I were to implement a free backgammon server in 2026, I would probably use the Lichess source code as a starting point. The backend is written in Scala, based on the Play framework. The frontend code doesn’t use any of the heavy-weight frameworks like React, Angular, Vue, Svelte but relies on Snabbdom which allows powerful DOM manipulation in about 200 SLOC. 7. Discussion Forum Maybe I have missed something but I’m not aware of anything like talkchess.com <http://talkchess.com/> for backgammon. This mailing list is not the right place to discuss such things because the list is meant for bug reports. Besides, it’s a mailing list, and not many users will go through the process of subscribing to a mailing list in 2026. Discord would be an option. I personally don’t like it, and I also don’t think that it’s not appropriate for free software but it’s maybe just me being old-fashioned. -------------- These projects look promising in developing solutions for some of the missing parts: https://github.com/nodots. However, I havent’ tried out any of them. But they do look actively developed which is a big plus. Apart from that, nothing else looks like a massive challenge to me, neither technically nor financially, at least for a team of motivated developers. Point 6 is probably the biggest challenge but my impression is that it should feasible for a couple of developers with a solid DevOps background. I know that a lot of these things have been discussed before. But I don’t see any real progress, and to me it makes sense to check back from time to time. Cheers, Guido
