6

"Just open-source it" is not realistic

 3 years ago
source link: http://rachelbythebay.com/w/2013/07/06/fred/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

"Just open-source it" is not realistic

I've received a couple of questions about fred following the failure of the kickstarter to fund it as open source yesterday. One of them was also asked before this whole thing started, and I had hoped it would just go away. I was hoping to not have to answer it. However, since it has come up again, it probably will keep coming up, so I might as well answer it.

The big one is: "why don't you just open-source it as-is?".

My answer is: it's not that simple, and it wouldn't help anyone as-is. First, you have to appreciate that fred is part of a much bigger code base. It's just like the "//depot/..." thing that some of my readers will recognize, only much smaller. It's a collection of libraries which I have written which have found their way into multiple projects.

I am not willing to just cut this all loose to the world. It represents a non-trivial amount of work, and why would I undercut my own ability to license it appropriately? Seriously, how can you possibly justify that? It would be one thing if I was riding a train of fat paychecks from some "day job", but I'm not. This is what pays my bills, and I'm not giving it up for free.

For fred to be released, it would first need to be split off from this code. This is not a huge deal. I've done it before. When splitting things off, some of the more generic aspects become less meaningful and sometimes I replace them with smaller versions. That is, instead of having a whole "Swiss army knife" class go out with the forked project, I whittle it down to just the parts which are used by that one project.

With this "freestanding fred" code base thus established, I'd go about making it somewhat less embarrassing. There are a few things in there which are great when used on my own systems but really should not be inflicted on anyone else. For those who are not familiar with this sentiment, it's called empathy. There would be an unnecessary amount of suffering needed to make it run as-is.

Let's also keep in mind that fred has no Makefiles. Seriously. None. It also has no build scripts or any other kind of build files. This is because it's part of my tree, and my entire tree is built with my build tool. I just say "bb fred/getpost" or whatever, and it gives me a binary.

As much as I want my little tool to take over the world of building C++, it would be unreasonable to expect other people to just give themselves over to it. It's also binary-only for the moment, and that means that only those people on certain similar x86_64 Linuxes and Mac OS versions can run it. Everyone else is out in the cold.

(Why is the build tool not open source? Easy, for the same reason fred isn't: it represents a non-trivial amount of work, and why should I compromise my own ability to license this and make some money from it?)

Given that relying on the build tool to exist would be foolhardy, that means I would have to create a Makefile. This is not a big deal, but making it handle the multitude of configurations is. That means autoconf. I have plenty of experience with these things (which is partly why I hate them so much), but getting it right still requires effort.

To release something without this work done would mean that someone else would have to do it. If someone was capable of doing that work, they probably would have done it already, and wouldn't be complaining about me not doing it for them. The whole point of doing this kind of compatibility and release engineering work is to make it useful for people who can't or won't get up to their armpits in http, RSS, Atom, XML, SQL, C++, Make, and autoconf grunginess.

Let me say that again: the people who are willing to meddle in such affairs aren't even here. They've already gone off and hacked their own thing in their language of choice. It's a feed reader, and the major pieces already exist. It should be possible to go from a general idea to a simple proof of concept single feed grabber in a day. If not, perhaps that task should be delegated.

The kickstarter was an opportunity to have me do that meddling on behalf of others on a grand scale. Once done, it would have been turned loose to the world to succeed or fail on its own merits.

Finally, I wanted to pass on an insight from a reader: Fred Brooks in TMMM says that a systems product costs at least 9 times as much as a program. Given that, does it seem so unreasonable to ask for some support when investing this kind of work in a fully-baked system?

For those who backed the project, I thank you. I wish we could have gotten to where this would have worked, and then I would have been able to fully commit to this project. As it is, I must now turn to other projects and clients. Such is the reality of capitalism.

(If anyone wants to dump money on me just so I can write code and give it away without having to worry about capitalizing on it, that would be just fine, too. You know how to reach me.)


July 7, 2013: This post has an update.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK