From b82a451cdbd6f0728560c50c148eb2a237d1f4e2 Mon Sep 17 00:00:00 2001 From: Michael Snoyman Date: Mon, 12 Dec 2016 19:30:18 +0200 Subject: [PATCH] Blog post: extra benefits of open sourcing --- posts.yaml | 3 ++ posts/extra-benefit-of-open-sourcing.md | 53 +++++++++++++++++++++++++ 2 files changed, 56 insertions(+) create mode 100644 posts/extra-benefit-of-open-sourcing.md diff --git a/posts.yaml b/posts.yaml index 89becda..b1724dc 100644 --- a/posts.yaml +++ b/posts.yaml @@ -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 title: "Haskell Documentation, 2016 Update" day: 2016-11-28 diff --git a/posts/extra-benefit-of-open-sourcing.md b/posts/extra-benefit-of-open-sourcing.md new file mode 100644 index 0000000..db98d8d --- /dev/null +++ b/posts/extra-benefit-of-open-sourcing.md @@ -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.