We’re talking about lock-in again this week. To rehash in case you missed the intro:

Software lock-in is, in simplest terms, what happens when you pick a piece of software and are stuck with that decision, locked-in. What usually comes to mind is proprietary software - vendor lock-in by method of proprietary data formats, that ensure customers use the vendor’s software for eternity. Working with open source software like Django we’re immune to this issue though, right?

Last week we took a look at third-party API lock-in and this week we’re back squarely in Django land to look at Python and Django library lock-in. To make that transition easier, we’re going to examine some libraries for working with a third-party API. Double bonus!

 

When good libraries rot

As with third party APIs and other forms of lock-in, with library lock-in you’re dealing with something - here that’s code - provided by someone else. This includes their opinions and their control.

Last year we were working with a software-as-a-service client that needed a Django upgrade. Like many SaaS’s they rely on Stripe for recurring payment processing.

And like many Django sites they used a Django app called django-zebra that provided nice integration with Stripe including webhooks for making decisions based on Stripe events. 

The only problem was that the maintainer stopped maintaining the app and stopped on a much older version of Django.

That meant this one third-party library was now the linchpin in the entire upgrade process. ##
Alternatives vs. development This is where things got interesting though!

If you’ve seen my “This Old Pony” DjangoCon talk[0] then you already know about the options for dealing with out of date libraries. I’m going to simplify here however:

1. Live with it and don’t change anything
2. Pick an alternative
3. Do the work to maintain a fork In this case #1 was not an option! 

Option #2 looked great. The dj-stripe library is well maintained and has an active development community. What’s not to like? 

We tried this route first but it quickly became apparent that this library was going to create more lock-in than the original.

While the code is nice it adds _much more _than we needed, including a new parallel model structure and tighter coupling between the API and the local database - for stuff that we didn’t care that much about.

Where dealing with an outdated django-zebra would require updating a fork, migrating to dj-stripe was going to require _architectural changes _to the app itself. ##
Keep your floorplan For this kind of functionality I don’t want to make architectural changes to an application. Luckily it took little effort to convince the CTO that this wasn’t the right route, and we simply created a fork[1] of django-zebra with the necessary compatibility updates.

This was a much lighter weight change that did not require making significant changes to the application itself and preserves a lot of “optionality” moving forward.
 

Picking libraries for the long haul

There will be occasions in which you find yourself leaning toward libraries that do come with significant lock-in. There will be times the benefits of doing this are stupendous.

So how do you know when to say yes?

The shortest answer is when the library is a good fit _and _has evidence of future life.

Check the release history, the repository commit cycle, issue tracker, outstanding pull requests, and if there is one, the developer mailing list.

Are people solving problems, responding to [meaningful] questions, and offering to work on features or bugs?

If it’s a Django app, what’s the most recent LTS version of Django with which it’s compatible? Is there evidence of a march toward compatibility with the latest version if it’s not there already?

Of course, if you’re willing to absorb any cost of changing the software then it doesn’t matter too much. 

Compatibly yours,
Ben

P.S. facing a similar lock-in dilemma? Let me know if you’d like someone else’s thoughts!

[0] “This Old Pony”: DjangoCon US 2016
[1] django-quagga

More like this

• This Old Pony: SELECT * FROM DATABASE_LOCKIN;
• This Old Pony: "Hey, this proprietary, black box API will make this super easy!"