4 ms·
At my company I take a very different view depending on where in the stack the tech is used: Developer tooling (Developer machines, IDE's, source control, CI,
by matharmin 7y ago
At my company I take a very different view depending on where in the stack the tech is used:
Developer tooling (Developer machines, IDE's, source control, CI, issue tracking, etc): Pay for the best.
The product: Only use FOSS. Give back by contributing and by making some of our work available as FOSS.
For the product, especially for the client-side, I just see it as too risky to include proprietary software. Even if the pricing is fine for right now, it can easily change later (got burned by both Google Maps and Mapbox years ago), and in some cases even prevent you from using different pricing models because of base costs it may add per user.
On the infrastructure side I'm more flexible, but even there:
1. Stick to commoditized services as far as possible, where the pricing is predictable. I'd include most cloud services in this, and most "enterprise" offerings not.
2. Avoid hard vendor lock-in if feasible, but only up to a point (don't build something from scratch just to avoid the lock-in).
- inapis 7y agoThis is what everyone’s approach should be. The product itself should be standing on the shoulders of FOSS giants. Everything else is just quality-of-life improvements and tools which should be paid for if they speed up your productivity or decrease your mental load. Proprietary software lock-in in your product can generally be very damaging when things go wrong. I know of one company which was so throughly fucked over that they had to halt all feature development for 6 months while they were busy building a replacement. Cost them enough time and customers to a competitor. For non-product stuff, replacing proprietary software is a bitch but far less disrupting.
- deleted 7y ago[deleted]