One of the best ways to improve your code is to open source it.

One of the best ways, just to be clear, and with that condition out of the way, let’s dive into the why, the how, and just what the hell I’m talking about.

There’s no magic about open source and there’s no magic behind making your code open source and accruing benefits. To draw an opinionated analogy, it’s a bit like running in minimalist shoes. While not quite in vogue as they were a few years back, at one point it seemed like you couldn’t go anywhere - if you happened to go or read where people discuss such things - without hearing about the multitude of benefits such shoes conferred on the wearer. Better gait. Fewer injuries. Faster times. Better recovery. Happier runs. Etc. etc. etc. The problem with these claims was not the base claims themselves but that they were made and/or interpreted as being necessary claims. In my own experience such shoes can lead to all kinds of improvements given that you actively respond to the new stimuli and that you build up slowly. These benefits are not conferred by default. Just strapping new shoes on and doing exactly what you were doing before is the path to pain in the most literal sense of the word.

It’s kind of the same with open source code.

The benefits are only conferred if you respond to the new stimuli. I think you will, but it’s more likely if you know how they work.

The act of open sourcing code doesn’t apply to everyone reading this. If you have only one small site Django site I don’t think the effort is in any way worth it. If you’re in a larger enterprise it may not be possible to open source any of your code. However for reader in the latter category there are analogues you can follow, sometimes explicitly in your organization.
 

The power of scrutiny

Whether you’re in a closed enterprise or you have total freedom of movement, lets think about what it means to open source some code:

1. Other people will be able to read it
2. Other people will be able to use it
3. Other people will be able to communicate their opinions to you There’s a lot more to this, but that’s the gist of it. And that’s no tiny thing, either. For most people these are incredibly strong stimuli which lead us to act differently than if were were just working quietly by ourselves. If you’re concerned about any of the above, in any way - whether due to a sense of pride or duty, you’ll tend to apply a more critical eye to what you’re sharing with the world.

The result we expect from this, that is, the appropriate way to respond to this stimulus, is to take reasonable care making sure your code is readable, tested, and documented. You may also decide that it warrants and can handle a better abstraction layer.
 

The world is your production test bed

There’s an oft-quoted myth popularized by Eric Raymond that with enough eyeballs are bugs are shallow[0]. However there is something to be said about having many people use the same piece of software and then be able to report back how things are working for them.

The first reason is that you can only generate so many use cases, whether in development or production. If even if a handful of other people are using your software, they’re all but guaranteed to use it in ways at least slightly different than how you envisioned it being used.

The other is that they’ll give you way feedback - hopefully - about ways to improve the software. These may be suggestions that align with your use cases and they may not. But whether it’s performance tweaks or superfluous feature suggestions, it’s A+ feedback that you’d otherwise have to pay for.
 

The payoff and the how

The payoff for a Django project is several fold. Improved code quality. Potential third party improvements. A wider test network. And improved isolation of components[1].

The how is a bit trickier but - BUT - I have some good news. There’s a website underway that tells you exactly what you need to do. It’s called www.django-standalone-apps.com and it’s a field guide to writing reusable Django apps, either from scratch or from your active projects.

It is deeply in progress. There’s a longer backstory that I won’t bore you with, but suffice to say it was started a while back and is in the process of being cleaned up and edited one chapter at a time.

And oh yeah, I’m the author. I encourage you to direct any suggestions, questions, praise or vitriol directly to my inbox by hitting reply!

It’ll be rolling out week by week.

Reliably reusably yours,
Ben

[0] So, yes, more people looking at code is good, but it turns out the marginal benefit drops off pretty sharply, and that not all eyeballs provide the same level of bug detection. Nor is all code amenable to the same level of inspection. The Heartbleed bug in OpenSSL affected source code widely used and widely available, but for perfectly valid reasons that didn’t mean the bug was guaranteed to be discovered in review https://en.wikipedia.org/wiki/Heartbleed
[1] I tend to believe in the benefits of encapsulation, as it aids not only at a code level in isolating code for debugging and testing, but also at an intellectual level as it makes it easier to think about how smaller parts work. This is neither original nor, I would anticipate, terribly controversial.

More like this

• Do you remember Django Standalone Apps?
• Does your Django site schedule maintenance for you? (This Old Pony #63)