Log in

No account? Create an account
Previous Entry Share Next Entry
And *that* is why I prefer to depend on open source
Yesterday, I hit a gigantic tarball in my current Querki project. (I'm currently rewriting the underpinnings to be journal-based instead of conventionally relational, which should make the system *vastly* more reliable, and permit us to build powerful version control into it. Huge project, but the end result is going to be *sweet*.)

The details of the problem aren't too important: suffice it to say, I realized that one of the key libraries I was relying upon (Kryo) was missing a critical concept, and this was leading to my code that depended upon it getting more and more baroque, with some possible problems coming up that might be entirely unsolvable.

In traditional enterprise software, I might have "support" available to me -- that is, I could report the issue. If that got a friendly ear, my request for an enhancement might get into their issue-management system. And in a while -- a few months if I'm lucky, a couple of years if not -- I might get a good fix. That doesn't exactly work for me.

Fortunately, the library in question (like most of Querki's underpinning) was open source. Which meant that, in a few hours, I could figure out *precisely* what was going on, come up with a fix (enhancing the KryoSerializer shell library around Kryo with a new concept), fork the library, and get the solution up and running.

No, it's not "supported" by anybody, and I might wind up having to maintain my own fork if the owner of the shell library doesn't like my approach. But I managed to clear a major blocker in Querki by adding a major new feature to the underlying tool, in hours instead of months.

Really, having gotten used to a nearly-pure open-source environment for Querki, my patience for traditional closed-source software has gone *way* down. I've never been anywhere near so productive in the traditional world...

  • 1

Try to push the enhancement upstream

Forking the library might seem like a good idea as you solved your immediate problem, but what happens when changes are made in the original code? Will you want those changes as well? Security holes that get fixed? Do you really want to maintain your own copy of the library?

If you found your enhancement useful, others might find it useful as well. I recommend trying to feed the changes back to the original project.

I sound like I drank lots of Kool-aid at work.

Re: Try to push the enhancement upstream

Oh, planning on it if possible. But the project owner hasn't responded to my issue yet, and I have no clue whether he's going to be amenable to it or not -- the fix only really matters if you are using the library the way I'm doing. (Which in turn is only really likely if you're using it for persistence the way I'm doing.)

So I'm *hoping* I can feed it upstream, but not counting on it...

Re: Try to push the enhancement upstream

Following up: after some discussion, the project owner has okayed me merging into mainline, so that'll be tomorrow's project. The only hassle will be that I once again forgot to make a branch for my work, so I have to figure out how to squash my changes in master, which is *not* easy, even with SmartGit. (Rebase. I *hate* rebase.)

  • 1