We use Asana for this. (It’s broadly great, and I don’t understand how Jira isn’t getting its lunch completely eaten. And I’m not just saying that because of my funder.)
I agree with a lot of this, though I think the mental attitude here is still extremely useful. For example, you may be dealing with something outside of your usual ticket system, or a ball may be smaller than something that would justify an Asana ticket.
My model of Atlassian business model goes like this: Take a popular open-source product, and make a crappy version of it with half the functionality and inconsistent UI, but make it possible to create plugins and sell them at your marketplace (where you take a cut). Then sell it for lots of money, and when anyone asks whether it has some functionality X, say “there is a marketplace with many plugins, I am sure there are many high-quality implementations of X”. Write in the contract that you only provide support for the basic installation without any plugins; if plugins are installed, proper functioning of the system is no longer your responsibility, and the customer should call the author of the plugin instead!
This seems to somehow work in practice. On one hand, you can check the checkbox “we provide support”, and also check the checkbox “our product supports X” when someone makes a plugin for X (so you soon provide more functionality than the original open-source project you copied… so when someone later proposes to replace your product with open-source, some manager will ask “but does the open-source solution provide integration with SharePoint?” or something like that), but when the customer installs the plugin for X, the support is no longer your problem. In theory, your product can be configured to do anything, but in practice, the customer is supposed to configure it in their own time, which most customers will refuse to do (somehow, spending $100,000 to buy your software is okay, but spending $10,000 to pay their employee his salary until he figures out how to configure it properly is not), so most customers will use the default settings, or the default settings plus a plugin. (And the integration with SharePoint does not work anyway, but no one is complaining about that, because the people who actually use the software do not care about SharePoint integration.)
This is too cynical, but I haven’t heard a better explanation that would fit the known data.
We use Asana for this. (It’s broadly great, and I don’t understand how Jira isn’t getting its lunch completely eaten. And I’m not just saying that because of my funder.)
I agree with a lot of this, though I think the mental attitude here is still extremely useful. For example, you may be dealing with something outside of your usual ticket system, or a ball may be smaller than something that would justify an Asana ticket.
My model of Atlassian business model goes like this: Take a popular open-source product, and make a crappy version of it with half the functionality and inconsistent UI, but make it possible to create plugins and sell them at your marketplace (where you take a cut). Then sell it for lots of money, and when anyone asks whether it has some functionality X, say “there is a marketplace with many plugins, I am sure there are many high-quality implementations of X”. Write in the contract that you only provide support for the basic installation without any plugins; if plugins are installed, proper functioning of the system is no longer your responsibility, and the customer should call the author of the plugin instead!
This seems to somehow work in practice. On one hand, you can check the checkbox “we provide support”, and also check the checkbox “our product supports X” when someone makes a plugin for X (so you soon provide more functionality than the original open-source project you copied… so when someone later proposes to replace your product with open-source, some manager will ask “but does the open-source solution provide integration with SharePoint?” or something like that), but when the customer installs the plugin for X, the support is no longer your problem. In theory, your product can be configured to do anything, but in practice, the customer is supposed to configure it in their own time, which most customers will refuse to do (somehow, spending $100,000 to buy your software is okay, but spending $10,000 to pay their employee his salary until he figures out how to configure it properly is not), so most customers will use the default settings, or the default settings plus a plugin. (And the integration with SharePoint does not work anyway, but no one is complaining about that, because the people who actually use the software do not care about SharePoint integration.)
This is too cynical, but I haven’t heard a better explanation that would fit the known data.
Sounds like a plugin-centric version of embrace and extend.