And *that* is why I prefer to depend on open source

[jducoeur]

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...

Comments

[laurion]

Not what I was expecting when I first saw the word 'tarball' in the post.

But yeah, since switching to linux a few years back, I've also found the delight in being able to contribute directly to the enhancement of the tools I use. Not much in favor of maintaining my own branches, but even if my suggestions or pull requests aren't taken, at least git makes it easy to do these days.

Try to push the enhancement upstream

[marc milgram (from livejournal.com)]

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

[jducoeur]

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

[jducoeur]

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.)

[ladymacgregor.livejournal.com]

And OF COURSE you've checked the license on your open-source software, so that if Querki ever goes commercial and people pay for it, you can continue to distribute this vital piece of your project?

(says the person who gets to do this for all of my company's third-party products)

[jducoeur]

Mais oui -- it's Apache 2, which AFAIK isn't a serious concern.

I spent a month arguing with lawyers about whether my company could use the LGPL, about six jobs ago, which quite sensitized me to the issue. After digging through it and concluding that it was badly-enough written that I couldn't actually justify my point (this was the original LGPL, which was a serious mess), I've gotten pretty careful about this stuff.

Fortunately, most of the OSS world has actually gotten much more sensible over the years. I have yet to actually want to use a library that involved any sort of GPL derivative, and nearly every library I've been interested in has had a pretty permissive license. Indeed, most of the communities I run in favor the MIT license, same as I do. (Which I usually summarize as, "Here's some code. Do what you want with it. Don't sue us.")

This is actually why the querki.org domain exists, BTW. (At least in theory: it's just a namespace at this point, not a website.) Querki.net itself has a semi-restrictive license, the CC Non-Commercial Sharealike: loose enough to allow people to run their own personal/club servers, but not to rip off my code and run a competing commercial service. But whenever somebody sees something in the Querki codebase that would be generally useful, I pull that out into a separate querki.org library, and MIT-license it. That seems the right balance point, far as I can tell, letting me be deeply involved in the OSS community without giving *everything* away...