Not bad, but I’d actually advocate what you denigrate. Open source tools allow you to evaluate exactly what you /do need/. They can typically be installed with under 100 keystrokes and configured with certainly no more difficulty than commercial systems. If you then decide that they don’t scale or don’t offer a Really Required(C) feature, by all means go out to a proprietary system.

The Really Required(C) refers to those features Orgs claim to need, but in the end actually don’t. My org has spent >100K on such software (trouble ticketing, wikis, CMS systems) only to actually use fewer features than what the best of breed OSS systems offer. Integrated Knowledge bases are empty, scheduling systems uninitialized (bc we also have use another calendaring system), ‘enterprise indexing systems’ have at most a few MBs of docs to index.

So on that point we agree. Your org //should define what it needs//. However, it’s almost impossible to do that unless you /use a system for a while/ and the best way to do that is to start off with a well-regarded OSS system and see where it fails rather starting with the top of the line ‘Enterprise’ system and find out that it’s a massive overkill (or that the people you depended on to support it or for content would rather use a lighter weight, headspace-amenable, OSS product.).