What we can learn from 180+ case studies on successfully shipping Python software.
If you're reading this (or hearing this), you read and write code, probably Python. And for all the code you've shipped, you've probably had your share of missed requirements. Somehere in the excitement of software abstraction, we can lose sight of what really matters, what makes our well-factored modules and packages and frameworks turn into real-world applications.
That's why I'm pleased to announce Awesome Python Applications, a hand-curated list of 180+ projects, all of which are:
The result is a list of predominantly focused on software that
pip or PyPI, and whose audience is mostly not
developers. There's still plenty of that in there, too, with other
exceptions, but the breadth of the list speaks for
So why spend weeks cataloguing open-source Python applications?
Aside from holiday cheer, three big reasons.
Ever since I started talking about Python packaging, people have been asking me questions about which packaging technique is best for their software. I was struck, over and over again, how far people can get in developing an application before reaching the fundamental question of delivery. Exploring this, I landed on a more basic question:
Why are so many people building applications from first principles (blog posts and Stack Overflow)?
Isn't Python one of the biggest names in the software world? Aren't there dozens of successful, real-world applications written in Python? What are the chances your application is totally unique?
So Awesome Python Applications is really an attempt to open up a new flow for answering tough development questions.
When building an application, scan the list to find projects which most closely match your project's requirements. Then, use that application as a guide for answering your own questions. This works especially well for abstract questions surrounding architecture, deployment, and testing.
Back in school, I learned more about architecture and software development from the MediaWiki source code than I did from any class. It continues to inspire me to this day. APA is the next step in enabling the holistic education of a working application with real users.
In short, while we may lack the time to write them, each production application is worth a thousand blog posts.
We Python programmers are also software users. But unlike other software users, we know how to file issues and may even make significant contributions back to our applications of choice.
By choosing Python software when possible, we take one step closer to pitching in. What better way for a future application developer to get started?
I would love to see more developers connect with software they didn't realize was Python. My (minor) contributions to the Twisted were greatly energized by the knowledge that one of my favorite applications, Deluge, heavily used the library. Using free software leads to creating more free software.
With the pace and cerebrality of technology, it can be easy to get ahead of ourselves and our end users. Infrastructure devs get disconnected from application devs, and that makes for worse software over time. This problem is compounded when applications get less developer attention. Most APA entries have three- and even two-digit starcounts, unless users are highly technical. Few major Python applications are distributed with PyPI, so download statistics can't help us either. Even if they did, lower-level libraries have way more fanout. And of course free software projects can't lay down big donations or conference sponsorships, so representation tends to be pretty sparse all around.
These applications represent the best of the free and living portion of Python. Not only are they a source of utility and pride, but they need our support, in spirit and in practice. It is my sincere hope that the APA will help to anchor the Python community in its real-world applications.
What does this mean, concretely? A keen eye will notice how the list is structured. This isn't just for consistent rendering, but an attempt at an API for the dataset. We must explore our ecosystem with the relzationship between libraries and applications in mind.
I know I'm going out on a limb here, and metrics aren't everything, but it would be very interesting to see the Python FOSS ecosystem explored as an analogue of the scientific publishing framework. Can we get some sort of developer h-index by treating libraries as "articles" and applications as "journals"? Adding in some application userbase approximations (via social altmetrics and other means) can give us much deeper insight into real-world impact.
If we've missed a project, please open an issue or PR. If you're as excited about this as I am, consider helping with some of the open issues. There are still a lot of application features to survey: licenses, Python versions, frameworks, and more. And as always, watch this space (and the repo) for updates as we make more discoveries!