Community Spotlight: Sage Abdullah
Meet a developer from Jakarta whose open source journey has taken him around the world
1. Tell us a bit about yourself. How did you get interested in contributing to open source?
Hey, I'm Sage. I'm from Indonesia and I've been an open sourcer for almost eight years now.
It started when I was still in high school around 2016. We have a national olympiad for students in Indonesia called Olimpiade Sains Nasional (OSN), which is divided into different subjects like maths, physics, chemistry, and informatics. I participated in the informatics olympiad, but I only got to the provincial level. The olympiad was mostly around competitive programming, so it was tough, and very unlike the programming people usually do. Not to mention that they used Pascal as the programming language, so it's not exactly something you'd use these days.
Then I heard about Google Code-In (GCI), which was a contest for high school students to contribute to open source projects. I thought it was a good opportunity to learn more about programming and to get involved in the open source community. Compared to competitive programming, it's a different kind of vibe that is much closer to your typical software development, and I was interested in that. I participated in it, but I was still using Windows so it was a bit hard to get started. I didn't spend much time on it, as I was in my final year of high school and I had to prepare for the national exams. I didn't win, but I got a (very cool) t-shirt and a certificate, and of course, I learned a lot. It was the first time I learned how to use Git in the terminal, how to set up continuous integration systems, and the like. Most importantly, it opened my eyes to the world of open source.
In 2017, I started studying computer science at the University of Indonesia. As expected, the first year was mostly about learning the basics of programming, algorithms, and data structures. It was the first time I learned Python, and mostly with toy project assignments. However, combined with my previous open source experience, it really unlocked a whole new world for me. Using open source packages, I was able to build a few side projects that my friends could use, which I was very proud of. All of them are open source, and some of them are still in use by other people today.
The big thing about open source for me is that it's a great way to learn. Sometimes, the things they teach you at university or in books just don't cut it. You're often given some example code that you won't see much in the real world (`abstract class Animal`, `class Duck`?). With open source, it's all there. You can see code that people actually use, and see how people wrote it. It's not always the most beautiful code you see. But if a lot of people use it, that's got to mean something. You also get to see how people collaborate, how they make decisions, and –like it or not– how they argue. Software is inseparable from the people who make and use it, and open source is a great way to learn about that.
2. What drew you to the Wagtail CMS project? How did you get involved?
I don't recall the exact details of how I first heard about Wagtail but it was likely from Tom Dyson's talk at DjangoCon Europe in 2020 or maybe from someone else in the Django community. I am not going to sugarcoat this, but I was drawn into Wagtail because I saw a job listing for a Wagtail Developer role at Torchbox. The thought of working on an open source project as a full-time job was very appealing to me. I knew Wagtail is built with Django, but I also learned that it has some front-end components built with React. I was already familiar with the two things, so I thought it would be a good fit for me. I got the job in February 2021, and I've been working on Wagtail ever since.
Aside from the fact that it's now my full-time job, I also found the project on its own to be very interesting. Before Wagtail, I had used a few CMSes before, but I had never actually worked on one. The approach taken by Wagtail, as outlined in the Zen of Wagtail, stood out to me. Wagtail does not try to be an instant website toolkit. It gives you the tools you need to build your website. But how you use the tools is up to you. Unlike some other CMSes that try to be a one-size-fits-all solution, it expects you to write code. Wagtail also gives you the flexibility to customize the CMS itself, to a level that I've never seen before. When you develop a product like Wagtail, you effectively have two different user bases: the end users who use the CMS to manage their website, and the developers who work with the CMS to build the website and the admin interface. It poses a unique challenge, and I find it very interesting.
3. You participated in Google Summer of Code with Django. Can you share a bit about your project and your experience?
Yes, I did Google Summer of Code (GSoC) with Django in 2019. My project was to implement a new cross-database JSONField to store JSON data in the database. The feature was already available in Django, but it was only available for PostgreSQL. The main goal of the project was to make the feature available for all database backends, including SQLite, MySQL, MariaDB, and Oracle. I also had to make sure that the feature was (mostly) consistent across all database backends, so that you can use the same code to work with JSONField regardless of the database backend you use.
To get into GSoC, you have to submit a project proposal to a participating open source organization. Usually, the organization gives you a list of project ideas that you can choose from, but you can also come up with your own project idea. If your proposal is accepted, you'll get to work on the project over the summer, guided by mentors from the organization. There will be evaluations throughout the project, and if you pass each evaluation, you'll get paid a stipend by Google.
The proposal submission period was around the same time as my midterms, so I had to balance between studying for my midterms and working on my proposal. The JSONField project was one of the project ideas that Django had, and it immediately caught my eye. I had only started learning Django the year before as part of my web development course at university, and I remember needing to store some data from an external API. I was too lazy to set up my own model for it, and I wondered if Django had a built-in way to store JSON data. I found JSONField, but I was disappointed to learn that it was only available for PostgreSQL, as I was using SQLite for my local setup. I ended up writing my own solution with a TextField and `json.loads`/`json.dumps`, which worked well, but it was not as convenient as JSONField. When I saw the project idea, I immediately knew that I wanted to work on it.
To increase my chances of getting accepted, I started off by working on a few "easy-picking" tickets in Django's issue tracker. It really helped me get familiar with the Django codebase and the contributing process. I introduced myself and shared my proposal on the Django developers mailing list. I was very happy when I got accepted, but I knew that the real work was just beginning.
The journey was quite steep, considering that I was fairly new to Django and its codebase, and I had never worked with the other database backends before. I had to learn a lot of things along the way, like how to write database-specific SQL, how to test database-specific features, and how to make my code fit into the existing codebase. Luckily, Django's popularity and the usefulness of JSONField led to a number of people making their own packages to add JSONField support for other database backends.
As I said before, open source is a great way to learn. Those pre-existing packages were great precedents, as they gave me starting points for the other database backends. Once I had a working proof-of-concept, I made a draft PR on GitHub to gather feedback. My mentors and a few others from the Django community did several rounds of reviews on the PR, and from there we iterated on the implementation until it was ready to be merged.
The new JSONField was a major feature. It took a good few rounds of additional reviews and changes after my GSoC participation ended, and it wasn't until almost a year later that it was merged into Django's `main` branch. That said, the project was a success, and the feature has been available in Django since version 3.1.
4. Now you're mentoring Google Summer of Code projects. How does it feel to be on the other side of the mentoring experience and what do you recommend for people applying to be mentored?
It's a different landscape, for sure. One thing I noticed is that somehow GSoC has become even more competitive over the years. It was already quite competitive when I applied, but I didn't really start approaching Django as a contributor until like a month or two before GSoC started that year. These days, I see people starting to contribute to open source projects as early as a year before, and only explicitly state their interest in GSoC when the time comes. As organizations, we don't even know if we'll be accepted into GSoC until a month before contributor applications are open!
As a mentor, I get to see the other side of the coin. Every year, there are a lot of people approaching the project. These people range from those who are fairly new to open source, to those who have been contributing for a while. Their programming skills also vary, from those who are still learning the basics, to those who are already working as software engineers.
5. You went from being a contributor to being one of the core members of the Wagtail release team. That's quite a journey, so what are some things you've learned along the way?
Working on a big open source project like Wagtail comes with its own set of challenges. You can't just change things as much as you want, because there are developers who depend on the project, either directly or through third-party packages. You want to keep breaking changes to a minimum, but sometimes there's just no way around it. Wagtail has been around for more than ten years now, so there are things that have been done in the past that might not be the best practice today. It's a balancing act between keeping the project up-to-date with the latest technologies and practices, and keeping the project stable for the developers who depend on it.
To help me assess the risk of breaking changes, one of the things I do quite often is source code archaeology. With a big enough codebase, it's not uncommon to see code that makes you ask "why is this here?" or "why is it done this way?". The answer is not always obvious. Digging through the codebase, the commit history, and their associated issues and pull requests on GitHub can give you more context on how the code came to be. In some cases, the decisions made in the past might no longer be relevant today. In other cases, you might find that our ancestors were way ahead of their time, and you might want to build on top of what they've done.
When making breaking changes to publicly documented code, we have a deprecation policy. We keep the code for at least the next release to give people time to migrate their code before we remove it. But sometimes, despite your best efforts, you might still break things unknowingly – especially for undocumented code. That's where the community comes in. The Wagtail community is very active, and they're not shy to report issues when they find them. Sometimes, they even go as far as to submit pull requests to fix the issues themselves. It's a great help, and it's a testament to the strength of the community.
So, I guess another thing I've learned is that it's okay to make mistakes. We all make mistakes, it's not the end of the world – it's part of the learning process. What's important is that you learn from your mistakes. And even more importantly, be open about it. Who knows, maybe a code archaeologist from the future will find your mistake, and they'll learn from it too!
6. You are (almost) single-handedly responsible for all of the innovations that have occurred with Snippets over the past few releases. Why were you drawn to Snippets and what inspired you to pursue new evolutions of the Snippet features?
When I first started working on Wagtail, it was mostly driven by its page model. The page model has a tree structure, where each page can have multiple child pages. It's a great model for building websites, but it's not the only model you might want to use. Sometimes you might want to store data that doesn't fit into the tree structure, or you might want to store data that is shared across multiple pages. That's where Snippets come in, which are essentially Django models for your smaller pieces of content that you can manage in the Wagtail admin interface.
Wagtail has a lot of nice features like revisions, previews, workflows, and many others. Unfortunately at the time, these features were built into the page model. If you wanted to use these features, you had to use the page model.
From a technical perspective, there was no strong reason why all these features couldn't be used with other models. We want to give developers the flexibility to use the models they want, especially when they're integrating Wagtail into an existing Django project. Having these features available for non-page models would be a big win for them – and for us. By decoupling these features from the page model, we could make them more reusable, and we could simplify the page model to only contain page-specific code. Once we had that, we could start building new features for all models with the same code. Case in point: the live preview feature introduced in Wagtail 4.0 was immediately available for both pages and snippets.
Wagtail is a Django project, and Django is known for its "batteries-included" philosophy. One of the batteries included in Django is the admin interface, which is a very powerful tool for managing your models. That said, the Django admin is not really known to have the best user experience, especially for non-developers. For some time, Wagtail had a trimmed-down version of the Django admin as the Wagtail ModelAdmin "contrib" module (separate from Wagtail "core"). The ModelAdmin module was a good start, but it was still quite developer-centric. We wanted to build a better admin interface for all models, and we wanted to build it in a way that is consistent with the rest of Wagtail.
Wagtail's core admin interface is tailored for content editors, but that doesn't mean we can't cater to the more tech-savvy users. After bringing Wagtail's editing features to non-page models, we started incorporating features from the ModelAdmin module into Wagtail core. It wasn't straightforward though, as we wanted to rebuild them to be more in line with Wagtail's codebase rather than Django's. With these features, we are giving developers the tools they need to build a better admin interface for their models, especially those that are internal models that do not suit the "snippets" terminology.
With the editor-focused features we brought from the page models, and the developer-focused features we brought from the ModelAdmin module, Wagtail becomes a more versatile CMS. Given enough time, we might even see Wagtail being used as both a CMS and a general-purpose Django admin replacement. If that happens, maybe we'll retire the "snippets" terminology altogether, and call them something else that fits better for all models. Until then... 😉
