3 ms·

But for any software used by a business it seems pretty simple. You simply need to match the free software in features (or get pretty close) and compete on sup

But for any software used by a business it seems pretty simple. You simply need to match the free software in features (or get pretty close) and compete on support. The key question is "What if something goes wrong?" Because a business owner can’t really use open source stuff unless they (a) know enough to edit the source competently or (b) can afford to hire someone who does. Assuming there’s a large market of founders who can’t edit source code themselves and don’t want to pay $100+ an hour to have someone else do it you end up with a pretty wide open market. Corporate America will always be risk adverse which means the deck will always be stacked against free stuff. The trick to competing is just stoking the fires of that fear and then making your software look like the remedy to all of them.

tptacek 18y ago
I think that might depend on the value proposition of your product. For the kinds of products that need the whole dance of vendor selection, budgeting, pilots, and rollouts, then yes: feature parity, or even a small feature deficit, is easy to overcome with a strong support pitch. That's because the sales process for these products gives you the opportunity to lay out a business case. But a lot of software doesn't get deployed that way. They may have a more casual value proposition, they may be more "niche-y" (and thus less visible to the pointy hairs), or they may be early adopter products. In this second category, I think it's harder to make a "support" pitch. If your prospect isn't 100% sold on the value of the product (and companies buy "phase 1" deployments of products to test the water all the time), they're a lot more likely to optimize for cost. I think it's worth being cognizant of which category you fall in to. I think if you're in the second category, the right play might be to open source yourself. Again, just because you open up your code, doesn't mean enterprises will be significantly more resistant to pay for it.

tptacek 18y ago

I think that might depend on the value proposition of your product. For the kinds of products that need the whole dance of vendor selection, budgeting, pilots, and rollouts, then yes: feature parity, or even a small feature deficit, is easy to overcome with a strong support pitch. That's because the sales process for these products gives you the opportunity to lay out a business case. But a lot of software doesn't get deployed that way. They may have a more casual value proposition, they may be more "niche-y" (and thus less visible to the pointy hairs), or they may be early adopter products. In this second category, I think it's harder to make a "support" pitch. If your prospect isn't 100% sold on the value of the product (and companies buy "phase 1" deployments of products to test the water all the time), they're a lot more likely to optimize for cost. I think it's worth being cognizant of which category you fall in to. I think if you're in the second category, the right play might be to open source yourself. Again, just because you open up your code, doesn't mean enterprises will be significantly more resistant to pay for it.