Blog post: extra benefits of open sourcing
This commit is contained in:
parent
f48877f66a
commit
b82a451cdb
2 changed files with 56 additions and 0 deletions
|
@ -1,3 +1,6 @@
|
||||||
|
- file: posts/extra-benefit-of-open-sourcing.md
|
||||||
|
title: An extra benefit of open sourcing
|
||||||
|
day: 2016-12-13
|
||||||
- file: posts/haskell-documentation-2016-update.md
|
- file: posts/haskell-documentation-2016-update.md
|
||||||
title: "Haskell Documentation, 2016 Update"
|
title: "Haskell Documentation, 2016 Update"
|
||||||
day: 2016-11-28
|
day: 2016-11-28
|
||||||
|
|
53
posts/extra-benefit-of-open-sourcing.md
Normal file
53
posts/extra-benefit-of-open-sourcing.md
Normal file
|
@ -0,0 +1,53 @@
|
||||||
|
This isn't any deep thought, and I'm sure others have mentioned it
|
||||||
|
before. But I haven't seen it called out explicitly, so I thought it
|
||||||
|
was worth getting it down.
|
||||||
|
|
||||||
|
Recently I was working on a customer project which required a specific
|
||||||
|
feature
|
||||||
|
([generate a Docker image with some libraries precompiled into it](https://github.com/fpco/stack-docker-image-build)). I'll
|
||||||
|
probably blog more about the specific case later, and give credit at
|
||||||
|
that time to the company that gave permission for the code to be open
|
||||||
|
sourced.
|
||||||
|
|
||||||
|
It turns out this is a problem that various FP Complete engineers have
|
||||||
|
solved for customers (and internal purposes) a few times
|
||||||
|
already. Creating a single open-source tool that can be shared among
|
||||||
|
projects is a clear win, and plays to all the strengths of open source
|
||||||
|
software. (And in this case, the initial version was
|
||||||
|
[really simple to implement](https://github.com/fpco/stack-docker-image-build/blob/v0.1.0.0/app/Main.hs),
|
||||||
|
so it was almost a no brainer.)
|
||||||
|
|
||||||
|
Not long after I released that first version, I needed to update some
|
||||||
|
Docker image build code for a _different_ customer, who until now had
|
||||||
|
been using a custom solution. So I moved them over to the new tool,
|
||||||
|
added some features that they needed, and got to the goal of a working
|
||||||
|
Docker image quicker than expected. Yay code sharing! And now others
|
||||||
|
can take advantage of this work, and contribute patches that both
|
||||||
|
projects using it will be able to take advantage of.
|
||||||
|
|
||||||
|
However, these are all the standard benefits of open sourcing. In this
|
||||||
|
process, I rediscovered something I've seen happen multiple times:
|
||||||
|
|
||||||
|
__When you're forced to separate out a tool or library, you create a
|
||||||
|
more general solution, and make your code more maintainable in the
|
||||||
|
long run.__
|
||||||
|
|
||||||
|
When you write a "throw-away" tool or a "internal" library, odds are
|
||||||
|
you won't think very hard about an extensible interface. You may embed
|
||||||
|
assumptions into its design. And then the code will sit in a
|
||||||
|
closed-source codebase for months or years, likely without anyone
|
||||||
|
touching it in the interim. When it turns out one of your assumptions
|
||||||
|
was wrong, or the interface needs to be extended, it's often times
|
||||||
|
much harder than updating a general purpose tool or library.
|
||||||
|
|
||||||
|
That's not to say that everything that _can_ be generalized _should_
|
||||||
|
be generalized and open sourced. There are some thing which are so
|
||||||
|
specific to a project that it's unlikely that any other use case will
|
||||||
|
exist. Or that the cognitive overhead of figuring out a good interface
|
||||||
|
is simply not warranted.
|
||||||
|
|
||||||
|
But for those sweet-spot cases where the overhead of doing something
|
||||||
|
general isn't too high, you have the prerogative to open source, and
|
||||||
|
there's likely at least one other person or project in the world who
|
||||||
|
can use it, you'll often thank yourself in the future for having taken
|
||||||
|
out the time to open source it.
|
Loading…
Reference in a new issue