Lately, been developing on django alot and this is to document my thought process when choosing django packages. In fact this is also how I determine what open source projects to adopt and not just limited to django.
Figure Out Available Choices
To determine what packages are available for a particular feature/function, Django Packages is a really great site for that purpose. Pick the category you are after, and it will show you comparison table of all the available packages. It shows you what’s different between each packages, their respective download counts & ratings, and more importantly, whether the package is actively maintained. This is usually a good first step, and normally I will pick the top 3 options and compare further.
Setup Complexity
The ease of getting things setup & running is very important, afterall, part of the goal of using a package is DRY and to speed up the development process. Usually, if the setup requires more than 20 mins or depends on some other infrastructures (say MQ or 3rd Party Services) which are not there already, I would think twice to myself “Is this package worth the setup effort for this particular project”. You just don’t want to spend many hours to work out how the configuration should be or throwing in another piece of infrastructure just to get it running.
Extensibility
Package written with extensibility in its design should be chosen over the others, even if it’s less feature-rich. Very often, you will find packages that are close to what you need but not 100% fit; or even if you are lucky to have found one which serves exactly your purpose – Great, but let’s not forget, at some point in the future, you might want to add new features or upgrade the current offering. Either case you will need to extend the package: write code & made changes to cater your specific needs. If a package is structured to a point where extending it is so hard and necessitate breaking its own internals, this might be a signal telling you to look for alternatives before settling on this one or you might find yourself doing a rewrite almost.
Table Schema Quality if There’s One
Sometimes, switching / ditching a package is necessary, and you would want to make sure it’s a managable process if not easy. Most django packages do touch on data layer where they will deploy their own tables, and you should safeguard to make sure the data schema comes with the package is reasonably designed. As schema migration is a pain for launched product, not to mention those with huge dataset. A carefully designed schema allows you to go a long way before having to deal with the performance issue, and could also give you better flexibility in case you really dealing with one.
Open Source
(Django packages are open source normally, so it usually not an issue.) With code available in the open, everyone can contribute which in turns make the codebase less buggy, and also improve the Bus Factor. Open source community would be formed, crowd wisdom shall impact the development positively, which eventually will help driving the development roadmap.
Optional: Scalability
Scaling is hard! Any hindrance to the problem should be eliminated. Scaling issue will eventually hit you and become the topmost in your TODO – Happy Problem. Dealing with it often involves lots of customization & architectural changes. Still, you should try your best to eschew adding unnecessary burden to the task. So when you are choosing package, do pay attention to the two characteristics: Loose-coupled & Fan-out. If chose right, it would allow you to decouple different parts of the application and scale them independently by throwing in more machines (Horizontal Scaling).
Next time when you are installing a new package, spend sometime and think thoroughly, then pick the best-fit or write one & open source.