

Reflections on Buy vs. Build - gk1
http://blog.dominodatalab.com/reflections-on-buy-vs-build/?hn=1

======
marcosdumay
Sorry, but I can't agree with most of it.

\- Using open source is a completely different choice from the build vs. buy
(false) dichotomy. Open source lets you have full control of your future,
while not needing to write all the code yourself. It's a best of both words
scenario that'll only create more problems than the alternatives if you have
licensing incompatibilities.

\- Yes, engineers are biased towards "build". And executives are extremely
biased towards "buy". Keep both in mind. I've lost count of how many times I
saw somebody spending 6 figures buying some software that didn't solve the
problem, just by having the problem solved later by a single engineer working
less than 6 months on it.

\- Yes, most of the cost of any software is maintenance. That true for buying
as well as building. Except that you can be sure that maintenance of built
software goes to making it better, on brought software that varies a lot (know
your suppliers).

\- Finally, that doubt about buying software that sustain your core domain...
If you can buy software that solves exactly your core domain, are are on the
wrong domain.

~~~
kiyoto
> Open source lets you have full control of your future, while not needing to
> write all the code yourself.

I disagree, and I say this as one of the maintainers of a decently popular
open source project ([https://www.fluentd.org](https://www.fluentd.org))

It's true that open source allows you to tinker and that it lets you jump
start your project. But as you point out yourself, a huge part of your
software cost is maintenance, buy or build, open source or proprietary. The
reason why open source is great is that as long as you can avoid forking the
project, you can reduce your maintenance cost by leveraging community
contributions and support.

However, the flip side is that you do not have full control: the community
often has different needs than your own, and it's not always easy to convince
the community so that the open source project caters to your needs. This is
double true if you are _just_ a user.

The alternative of course is to create a fork and either take it in-house or
try to get the community to rally behind your fork. In either case, you either
lose the community's support entirely or reduce its effectiveness, and the
same question/burden of long-term maintenance strikes you back.

~~~
marcosdumay
Yes fork it and it becomes just as expensive as building. Yet, you got all the
previous benefit for free, what makes open source strictly a cheaper choice,
anyway it goes.

And, of course you can get dependent on some open source code that you don't
have enough resources to fork. But that again is strictly better than either
buying or building, because you wouldn't be able to build it anyway, and it
still gives you much more control than buying.

------
nulltype
This strikes me as an amazingly rational approach to build vs buy. Including
trying to estimate the entire cost.

A solution you build yourself costs more than just the time of the engineer to
build the first version, the work revolving around maintenance and improving
it, when that could be borne by an outside company, could be quite high. Also,
when an outside company makes it, they can amortize the cost of a new feature
across multiple customers. And people will often build things that work with
that product, saving you even more effort.

The cost of buying though, is also of course not just the money you pay (free
and open source still have a significant cost). How complex is the bought
system vs the one you would build? How hard is it to replace with something
else? How well tested is it? I've done the 'buy' approach with some open
source things and services before and super regretted it when it took longer
to debug than writing my own and maintaining it would have.

