* long term support (e.g. don't EOL something just because it's 5 years old, etc)
* immediate support (have someone you can call 24/7 if your system blows up)
* responsive support (have engineers on staff to close support tickets fairly quickly. This applies especially to bugfixes)
* good QA process so that you do not use your enterprise customers as free QA but pay people to test the product thoroughly before releasing it. This ties into the notion of long term support as something that stays in the QA matrix and receives bugfixes/updates.
* good documentation, in multiple languages
* A supporting ecosystem of certifications/training materials, so a business can hire people qualified to use the product
All of the above boils down to having people on staff doing all the boring, costly things that reduce the pain of companies using the software. Those things are not fun, so they tend not to happen consistently by open source volunteers, so they have to be paid for, hence "enterprise", as end users don't value these enough to pay for them over free but big businesses do.
> e.g. don't EOL something just because it's 5 years old, etc
How about "Don't say at release time that you'll support something for 10 years, and then change your mind a year later and say that you'll be dropping support in a year?"
For the purposes of avoiding trademark infringement all RHEL clones go out of their way to avoid mentioning Red Hat, thusly Red Hat Enterprise Linux and all derived from its sources tend to get lumped together as “Enterprise Linux”
* Long-term stability and ABI guarantees. A software / hardware stack for a platform that isn't going to change or break underneath your feet while still receiving bugfixes and security updates for multiple years.
* A software stack that large third-party vendors of software and hardware are willing to certify their products against, e.g. SAP, databases, etc.
rsj_hn|4 years ago
* immediate support (have someone you can call 24/7 if your system blows up)
* responsive support (have engineers on staff to close support tickets fairly quickly. This applies especially to bugfixes)
* good QA process so that you do not use your enterprise customers as free QA but pay people to test the product thoroughly before releasing it. This ties into the notion of long term support as something that stays in the QA matrix and receives bugfixes/updates.
* good documentation, in multiple languages
* A supporting ecosystem of certifications/training materials, so a business can hire people qualified to use the product
All of the above boils down to having people on staff doing all the boring, costly things that reduce the pain of companies using the software. Those things are not fun, so they tend not to happen consistently by open source volunteers, so they have to be paid for, hence "enterprise", as end users don't value these enough to pay for them over free but big businesses do.
LambdaComplex|4 years ago
How about "Don't say at release time that you'll support something for 10 years, and then change your mind a year later and say that you'll be dropping support in a year?"
(Yeah, I'm still not over that)
Tsiklon|4 years ago
mimsee|4 years ago
dralley|4 years ago
* A software stack that large third-party vendors of software and hardware are willing to certify their products against, e.g. SAP, databases, etc.
* Support contracts
mrweasel|4 years ago
ForHackernews|4 years ago