Not Really Forking Tryton

I have a customer in desperate need of a service that a customized deployment of Tryton can provide. This is a normal thing in Tryton Land. In fact, Tryton itself is merely a framework and useless without extensive module installation. But even with quite a lot of module installation Tryton is generally still useless, and indeed requires an ERP expert’s (or more likely a team of ERP experts’) attention to do anything positive for a business.

The reasons for that are pretty basic. On the one hand every business is pretty different from any other business, and the use cases for an ERP system are so varied that there is almost no way the same ERP solution would ever fit everybody. On the other hand, some of the design decisions embodied in Tryton seem to conspire at times to make default/raw deployments of Tryton particularly user unfriendly even for basic use cases like double-entry accounting or just organizing customer contact information.

But again, Tryton never claimed to be anything other than a framework — the canonical modules provided at the centrol Tryton repo were never purported to be anything more than a free, example-oriented fleshing out of the underlying bones.

And that brings me to what I’m about this month. I have a semi-urgent need to get some major time sinks my customer is experiencing to go away and Tryton is not just a good way to do this in the short-term, it is also a great way to start them on the road to solving a lot of time-wasting, ankle-biter problems across the long-term as well because of the way data work can be centralized in a single system this way.

I mentioned above that there are a few awkward-seeming design features to Tryton. That is true for nearly every project, particularly open source ones where it isn’t very unusual for too many cooks to be spoiling many versions of the same family of broth willy-nilly (and occasionally producing masterpieces in the chaos — which is the real point).

But there is a different set of unfortunate situations surrounding Tryton development, problems that cause Tryton to be a little bit confusing to bugtrack, follow development, contribute to, etc. The first problem is the choice of version control system.

Most projects, including the Linux kernel and LibreCAD are developed using Git, and a huge number of such projects either are fully hosted on sites such as GitHub or SourceForge or at least show their face one of the two places (or both). But Tryton uses Mercurial for version control, which drives some developers away (it would have driven me away as well if Tryton weren’t as perfect a fit for my client).

The big issue here is that Mercurial does nearly exactly the same things as Git, in nearly exactly the same way, but colors its nearly identical commands in slighly incompatible ways in an attempt to appear to not be a Git clone and the documentation is laced with (inaccurate) FUD on Git and SVN, which just makes reading it try my patience (and if the comments on the site are any indication I’m not alone). The functional differences between the two being minimal, the presence of two similar, competing systems makes learning the otherwise trivial differences between the two irritating and merely a pain in the ass rather than being something forward and productive to do.

The other major problem with Mercurial is that while it does provide built-in features to make serving private repositories via Apache or other webservers realtively easy, almost nobody does this in practice — and when people do serve their own getting access to actually push to the project is a much more convoluted process than simply doing it on a content management site such as SourceForge or GitHub which already have well understood, well documented and easily discoverable mechanisms for publicly forking, pulling, branching and pushing branches and changes around wherever one likes. People get more antcy about hosting everyone’s forks publicly when its their own “private” repo they are hosting on their own hardware. That is just human nature, but it really makes open source projects turn very closed in a sense.

There is, sort of, a place to do this at mercurial.intuxication.org, but despite the benefit of a cool name, the site itself is rather opaque and weird to use — and breaks down (today, for example, even the FAQ/help page gave me 403 errors). As is somewhat normal for open source projects, the existence of Tryton as a project extends way beyond intuxication. The problem, though, is that Tryton is abnormally nebulous in nature and to a newcomer is very difficult to track — actually, it extends to far that finding all of it across the web is a sub-task of its own — and there is no bounce page maintained anywhere I could find that explains the situation, and much of the existing wiki documentation is not very up to date (part of this being because the wiki is maintained at google and seems to have a very limited set of eligible editors, a pain I fully sympathize with…).

So all of this sucks.

Without spending any more time getting into details I am simply going to state that for the above reasons and others related to the difficulty/complexity of contributing directly to Tryton as a project and getting modules included in the central repo I am putting up a Tryton repo on GitHub, based on the changes I need to make for my client. This is not a fork of Tryton, however. I am not proposing to hack on core Tryton code, or even make big changes to existing key modules (I was originally intending to, but Udo Spallek graciously showed me that this is not as necessary as I originally thought it to be).

So my GitHub goals are not to fork the project, but rather to provide a public window into my otherwise private Tryton module customization and development in a way that is easier to access, understand and contribute to than the current canonical Tryton project. By the end of my project I intend to have a working set of features that include a pass management module (“pass” as in access and vehicle passes/badges for access to restricted areas that expire on a set timeline), contract management module that links to projects, a way for heirarchal groups of parties to relate to one another in a customer -> prime -> super -> sub-contractor sort of relationship (strongly tied to the functionality necessary for contracts and projects to work correctly), and new features to handle the quirks inherent in Japanese language environments where up to four spellings of the same name are correct and should be uniformly searchable.

That’s a lot of work. Its a lot of testing. I don’t have all year to discuss this with a committee, either. So I’m putting this on GitHub as a public window into my private efforts against this problem set, again, not as an actual fork of Tryton. Hopefully once the dust settles I’ll have a set of features that is workable enough to push for inclusion back into the central Tryton project. Of course, GitHub being what it is it wouldn’t be unusual at all for others to fork things on their own and play around — but that’s the beauty of a place like GitHub.