Thinking about an RDKit support model

One of the the ways that I think T5 Informatics is going to generate revenue is by offering support contracts for the RDKit. I say “I think” because that’s still just a hypothesis. This post is part of starting to test that hypothesis.

Support for the RDKit is currently provided via the mailing lists, github, and, to a lesser extent, the Slack channel. Oh, and via email to me directly. I tend to direct people who send me personal email to the mailing lists so that other members of the community have a chance to answer and both the question and answer end up being publicly findable via a search, but I do directly answer the occasional direct question, particularly those coming from companies. This system isn’t perfect, but it does work reasonably well thanks to the helpfulness and openness of the RDKit community (we have a great community). It can, however, make things difficult for organizations to report problems or ask questions: often they need to invest effort in making sample structures/inputs generic before asking. I believe that the lack of formal support offerings can also be a barrier to adoption of the RDKit in some organizations. Some of you will know this problem: the person somewhere in IT who insists that you can’t install software without having support available.

Another dimension of all of this is deciding what gets worked on next: which new features are added, which bugs are fixed, which documentation is written, etc. At the moment these decisions are done in a “somewhat” ad hoc manner. I tend to prioritize new features based on what I need, what I perceive the priority to be, how much work they are, and how interesting they would be to work on. Prioritization of bug fixes is primarily driven by my assessment of the severity of the bug and the amount of work required to fix it. In addition to the work that I do, an increasing number of bug fixes and new features are coming in directly from members of the community. This is an excellent way for people to “scratch their own itch” and Github makes it easy but it doesn’t help organizations that don’t have development resources available.

The idea of offering support contracts is to address both of these dimensions, along with a few others. Let’s start with the basics: what does a support agreement get you?

• A CDA in place to make reporting problems easier and a private, secure file-transfer area
• Email and online support for X contact persons. Support otherwise is via public routes like the mailing lists and github
• Support customers participate in prioritization of bug fixes, new features, and new documentation
• Support customers can request off-cycle patch releases and binaries
• The opportunity to demonstrate, in a direct and concrete way, that the RDKit is important to your organization

There will be some additions to this as the new RDKit release model evolves (details coming in a future post), but this covers most everything.

At the moment, I think the base price for this is on the order of $10K per year for a single contact person and a limited number (possibly one) of standard platforms. Standard platforms include modern versions of Windows, Linux, or Mac OS X. The price for supporting additional standard
platforms, as well as non-standard platforms, still needs to be figured out; it’s likely to be related to the difficulty of supporting that particular platform. In the event that a support customer would like to have more than one person able to directly contact T5 Informatics for support, additional contacts are around $2K/year.

As I’ve already mentioned, this is still all at the hypothesis stage. I’m really looking for input and suggestions, so please let me know what you think by either posting a comment or sending me email.