This is part one in a series exploring how Tryton might fair as the heavy-lifting portion of an e-commerce package. This first part describes Tryton - architecture, features, community, license.
Upcoming parts (as planned, anyway):
I want to call Tryton an open source ERP system, and it is, but I like their description of the project better: A three-tier high-level general purpose application platform released under the GPL-3 license, written in Python, using PostgreSQL as its database engine.
That’s a lot of descriptors, but basically what it says to me is that it’s a platform for building stuff, made from tech I like, and licensed under the GPLv3. And when you look at the base modules that come with Tryton, you can see it has an emphasis on ERP: accounting, invoicing, sales management, purchasing management, inventory management.
[Note to past self: In the future, you're going to get excited about this stuff. No, not anxious. I said excited.]
[Note from past selves: Did you forget your first professional programming project - 1985 - was calculating economic order quantities? And your first industrial automation job - 1991 - counted feet of magnetic wire coming off 50 machines for integration with their business systems? Loser. We're ready. You're the anxious one.]
So Tryton is made up of three main components (tiers): A client, a database, and some code stuck in the middle to make things go smoothly.
That middle layer between the client and the database is also the reason Tryton isn’t just an ERP system, because really, you can use it to manage any data-intensive application. There’s nothing about Tryton that intrinsically says “You must have an Certified Public Accountant involved in this project” – Tryton’s design lets it manage schools and hospitals and music festivals and motorcycles and people and emails and whatnots just as easily procurement orders or P&L statements.
While the middle tier provides the magic, there’s an important consideration in the client, too. The client doesn’t have to be human. If I had my druthers, I’d no longer develop any web applications that don’t provide an API, or Application Programming Interface. Tryton’s server, known as trytond or “the Tryton daemon”, connects to the regular old client using a protocol known as XML-RPC, or “eXtensible Markup Language – Remote Procedure Call”. trytond uses XML-RPC to tell the client what to show, and the client responds in XML-RPC to tell the server what to do. Well, that means that any program that knows the secret handshake and how to speak XML-RPC can be a Tryton client. (For accuracy’s sake, I’d like to point out that Trytond is like, trilingual. It’s fluent in XML-RPC, JSON-RPC, and Net-RPC. It’s also gets by with WebDAV, psycopg, and even some OpenOffice – you know, enough to ask where the bathroom is, how to hail a cab, what’s safe to order at a restaurant.) The upshot of this, of course, is that I can create an e-commerce site running on MODX Revolution or Django that interfaces completely with Tryton because my website is the client.
I feel like I should mention something about what Tryton actually does, which is an interesting concept. I almost think of it like I would a programming language – not what it does, but what you can do with it. Given enough time.
Despite my inclination to see multiple uses for it, Tryton focuses on business systems. Install the standard modules and it will handle the business of a catalog retailer, for example:
There are certainly some things that Tryton doesn’t do, that a typical ERP system might (or should, or maybe I wish it would) do:
That’s not to say Tryton can’t do these things. It can – some assembly required, please allow six to eight months for delivery.
Looking at my target application, however – performing as the backend for a large-scale e-commerce system – Tryton has much of what I need:
Alas, there are a few things I’d want to add to that list:
While I might not expect it to be part of Tryton, there’s always the rest of the e-commerce site too – content management, templates, dynamic content outside of the store, etc. I think it could be interesting to see a merger between these elements, but I am not convinced it’s a good marriage. Should an ERP system provide internet and intranet, online document management, institutional knowledge management? Sounds like a question for another blog post. Meanwhile there’s MODx and Django.
I’ll discuss community more in the next post, but Tryton seems to be developed under what’s called a Community Open Source model. If you ask me, that’s the old school way of doing it. You know, the right way, before the new fangled methods came along and perverted the process. (I’m not opinionated or anything.)
Tryton is developed by a federation of companies and individual developers. There seem to be at least five main companies involved, all of which also provide commercial services for the system as well. Of course, there is a strong argument that these companies are most expert in the software. This expertise translates into demand, and revenue.
In contrast, some open source projects (examples include OpenERP and Magento) follow what’s called a Commercial Open Source model. In this model, one company typically calls the shots (or “edits”) the software. They often do most of the development, especially early on, but they also draw upon work done by users and developers of the system. If the editor likes your code, they pull it into the main branch. If they like your idea but not your code, they might implement your idea themselves. If they don’t want either your idea or your code, it sits out there for others to find and use. Often, the commercial open source model matures into a dual-release model, where the package is released in a community (open source) version, and an enterprise (proprietary) version.
I’ve developed in OpenERP and already had that uncomfortable discussion with the client where you teach them how to read a specification, especially the section defining how the code is licensed. OpenERP is, curiously, licensed under the GNU Affero General Public License version 3.0. It’s just like the (in)famous GNU General Public License version 3.0, except it adds a bit of text closing what’s called the “Application Service Provider Loophole”. That is, the user of a system licensed under the AGPL has a right to the source code for the system, even if they’re accessing the system over a network. Even if it’s been customized. Even if it’s got trade secrets in it. In practice (and I Am Not A Lawyer) this seems to mean that the people using the OpenERP client to connect to an OpenERP server over a network should be able to retrieve the source code for custom modules. Generally speaking, this would be the customer who paid a developer to create the modules, and of course they should get the code. Likewise, the person who owns a website that connects to an OpenERP server should be able to get any custom OpenERP module code that supports the website connecting to it. Phew. But I don’t think it goes farther than that – I don’t believe this means that the website needs to be licensed AGPL, or that visitors to the website should be able to download code for the website, or any custom OpenERP modules.
Tryton, on the other hand, is licensed under the regular old GNU General Public License version 3.0, complete with ASP loophole. That tells me that the source code for any customization made to the Tryton code (a custom module, for instance) used by a client over a network does not need that custom code offered to the client. I don’t have a problem playing nicely with others. I like to share. I appreciate those subtle shades of difference between the AGPL and GPL. But when it comes to splitting the hairs of freedom, it seems that distributing custom code to lowly users causes palpitations among some clients, typically those with legal departments.
If I’ve inspired a response from you (probably the type of response that deserves an apology), mention @version2beta on Twitter and I’ll see it there. Or, if you can’t comment in less than 126 characters (my handle takes 14 characters with a space), blog about it and tweet that.
Three-tiered architecture structures applications so that the data, business logic, and presentation are separate modules, independently maintained and applied, with all actions passing through the business logic tier. Wikipedia also has an article on multi-tiered architectures. ↩
Have I mentioned how much I like PostgreSQL before? I really did discount and ignore it before I had to start using it on a project, and that's all it took. I prefer PostgreSQL now over every other SQL database I've used. ↩
Wikipedia's article on object oriented programming is a good primer. My first class on OOP, back in the early 90's, was interesting. The instructor started to describe an object like a telephone. "It has a phone number associated with it, that's a property. It has the ability to call out, and that's a method. It can also receive incoming calls and ring, and that's an event." Just then, the phone in the back of the room rang. Everyone looked around to see if it was a prop, or a real call, and eventually someone got up and answered it. They listened for a moment and then called out, "Is there a Rob Martin here?" It was my office, sending me to California. I had three hours to pack and get to the airport. I managed to pick up object oriented programming on my own later. ↩
CyberSource is like Authorize.net, but for companies with over US$3M a year in sales. Actually the local salesperson might think that number is higher. I brought them a customer with nearly double that, and we gave up on her ever sending a contract after three months. ↩
Django is a Python-based web framework for delivering content efficiently. Originally developed by newspaper publisher The World Company in Lawrence, Kansas, it's not used in a wide variety of applications throughout the internet. The largest Django site right now is Disqus, which will host comments for my blog when I get around to implementing that. ↩