Hacker News new | ask | show | jobs
by dsr_ 997 days ago
Open Source project O will cost your team X hours of time to develop expertise in managing it.

Enterprise product E will cost your team X hours of time to develop expertise.

O requires install time. E either requires install time or integration time.

When O breaks, it is likely that the community has already seen this problem and can provide suggestions via docs, mailing list archives, discussion fora, blogs... Your team's expertise will increase. If your problem is interesting, the developers will likely get involved.

When E breaks, you will open a ticket. Within 24 hours, someone from the E company will try to diagnose your problem, going down a flowchart that they will not share with you. If your problem is in the FAQ or flowchart, it will get solved within a week, probably. If your problem is interesting, it may eventually be solved in a future release. Your team will spend less time working on it, but E will be broken for longer.

You will pay dollars to your team to support O, which will make them happier.

You will pay dollars to the E company to support E, which will make them happier.

2 comments

E will invite your execs to dinner at the E conference.

O will never invite anyone to anything.

This is the secret.

E will also conduct award ceremonies and invite the suits - "Best Practices Journey Award 2023".

O will have a virtual hackathon broadcast on their self-hosted Jitsi.

You forgot the cost of Y hours your developers could have spent on A.

This is the actual, non-cynical driver for many of these decisions. An exec is looking at devoting developer time to building or curating software that isn't part of the core competency of the business, and balancing it against staffing product development or IT aimed at the business's specialization.

To make avoidance of E palatable, you have to show that use of O will not only cost significantly less that E, but that using it will also make up for the lost time that you would have spent building A.

I say this as someone who constantly has to justify why we don't just grab some SaaS offering off the shelf and groom it * cough * um... integrate it, rather than continuing investment in the purpose-built "commodity" my team runs.