Google Summer of Code
Zulip is the only modern team chat app that is ideal for both live and asynchronous conversations. Zulip has a web app, a cross-platform mobile app for iOS and Android, cross-platform desktop and terminal apps, and over 100 native integrations. The entire Zulip codebase is 100% open source.
Zulip has been gaining in popularity since it was released as open source software in late 2015, with code contributions from over 1000 people from all around the world. Thousands of people use Zulip every day, and your work on Zulip will have meaningful impact on their experience.
As an organization, we value engaged, responsive mentorship and making sure our product quality is extremely high. You can expect to receive disciplined code reviews by highly experienced engineers. Since Zulip is a team chat product, your GSoC experience with the Zulip project will be highly interactive.
“The experience of working with Zulip for the summer was really phenomenal and taught me a lot about software development and working with a community. Zulip has one of the best open source communities out there who are super friendly and welcoming. You learn a lot just by watching others work and talk.” – Sai Rohitth Chiluka, Zulip GSoC 2021 participant
As part of our commitment to mentorship, Zulip has over 160,000 words of documentation for developers, much of it designed to explain not just how Zulip works, but why Zulip works the way that it does. To learn more about our mission and values, check out this blog post!
The Zulip GSoC experience
Zulip has been a GSoC mentoring organization since 2016, and we accept 15-20 GSoC participants each summer. We have also mentored several interns through the Outreachy program, and hundreds of Google Code-In participants.
Zulip operates under a group mentorship model. While you will have an assigned mentor, you will also get lots of feedback from other members of the Zulip development community by posting your questions and ideas in public streams. We encourage GSoC participants to help each other out as well!
Many GSoC participants stay involved with the project past the official end of the program. A number of folks who get started with GSoC go on to mentor the next cohort of participants, and several have joined Zulip’s team of core maintainers.
To learn more about the experience of doing GSoC with Zulip, check out our Zulip’s Google Summer of Code 2021 blog post. Our guide for having a great summer with Zulip will also give you a feel for what it’s like to do GSoC with us.
“It has been the best summer I’ve ever had! I’m thankful to my mentors, my peers, Zulip, and Google for providing me an opportunity of getting involved in the community! You have helped and supported me to become a better software developer and a passionate open-source contributor.” – Sarthak Garg, Zulip GSoC 2021 participant
We have an easy-to-set-up development environment, and a library of tasks that are great for first-time contributors. Use our first-time Zulip developer guide to get your Zulip development environment set up and to find your first issue. If you have any trouble, please speak up in the #GSoC stream on the Zulip development community server (use your name as the topic).
Application tips, and how to become a strong candidate
Zulip has some of the highest standards of any GSoC organization. The most important component of a strong application is to demonstrate your ability to contribute to a large codebase. Accepted applicants generally have five or more merged (or nearly merged) pull requests, including at least a couple of significant changes (on the order of 100+ lines).
The quality of your best work is more important than the quantity, so be sure to follow our coding guidelines and test your work before submitting it for review. Don’t worry if you make mistakes in your first few contributions! Everyone makes mistakes getting started — just make sure you don’t make the same mistakes next time.
It’s best to get started with Zulip early, so that you have time to learn, make contributions, and put together a strong proposal. However, we recommend waiting until the last few weeks to formally write up and submit your application.
The GSoC 2022 application deadline is April 19, 2022. Please follow GSoC’s application process instructions. Your application should include the following:
Details on any experience you have related to the technologies used by Zulip, or related to our product approach.
Links to materials which help us evaluate your level of experience and how you work, such as personal projects of yours, including any existing open source or open culture contributions you’ve made and any bug reports you’ve submitted to open source projects.
Some notes on what you are hoping to get out of your project.
A description of the project you’d like to do, and why you’re excited about it.
Some notes on why you’re excited about working on Zulip.
A link to your initial contribution(s).
We expect applicants to either have experience with the technologies relevant to their project or have strong general programming experience. We also expect applicants to be excited about learning how to do disciplined, professional software engineering, where they can demonstrate through reasoning and automated tests that their code is correct.
For all of our projects, an important skill to develop is a good
command of Git; read our Git guide in full to
learn how to use it well. Of particular importance is mastering using
git rebase so that you can construct commits that are clearly correct
and explain why they are correct. We highly recommend investing in
learning a graphical Git client and learning to
write good commit structures and messages; this is more important than
any other single skill for contributing to a large open source
project like Zulip.
We are excited about candidates who submit good contributions to Zulip projects, help other applicants on GitHub and on chat.zulip.org, learn from our suggestions, try to solve their own obstacles and then ask well-formed questions, and develop well thought out project proposals.
For the first time in 2022, being a student is not required in order to apply to GSoC. We are happy to accept both student and non-student participants.
Our documentation on what makes a great Zulip contributor offers some additional helpful information. We also recommend reviewing the official GSoC resources, especially the Contributor/Student Guide.
Questions are important
A successful GSoC revolves around asking well-formed questions. A well-formed question helps you learn, respects the person answering, and reduces the time commitment and frustration level of everyone involved. Asking the right question, to the right person, in the right way, at the right time, is a skill which requires a lifetime of fine-tuning, but Zulip makes this a little bit easier by providing a general structure for asking questions in the Zulip community.
This structure saves time answering common questions while still providing everyone the personal help they need, and maintains balance between stream discussion and documentation. Becoming familiar and comfortable with this rhythm will be helpful to you as you interact with other developers on chat.zulip.org. It is always better (and Zulip’s strong preference) to ask questions and have conversation through a public stream rather than a private message or an email. This benefits you by giving you faster response times and the benefit of many minds, as well as benefiting the community as other contributors learn from reading the conversation.
Stick to the community norms.
Read these three blog posts
Understand what makes a great Zulip contributor
This is a typical question/response sequence:
You ask your question.
Someone directs you to a document.
You go read the document to find the answer to your question.
You find you are confused about a new thing.
You ask another question.
Having demonstrated your the ability to read, think, and learn new things, someone will have a longer talk with you to answer your new, specific question.
You and the other person collaborate to improve the document you read in step 3. :-)
As a final note on asking for help, please make use of Zulip’s Markdown when posting questions; code blocks are nicer for reading terminal output than screenshots. And be sure to read the traceback before posting it; often the error message explains the problem or hints that you need more scrollback than just the last 20 lines.
Once you have several PRs merged (or at least one significant PR merged), you can start developing a specific project plan. We recommend discussing your ideas in the #GSoC stream in the Zulip development community, in order to get quick feedback from whoever is online.
This section contains the seeds of project ideas; you will need to do research on the Zulip codebase, read issues on GitHub, and talk with developers to put together a complete project proposal. It’s also fine to come up with your own project ideas. As you’ll see below, you can put together a great project around one of the area labels on GitHub; each has a cluster of problems in one part of the Zulip project that we’d love to improve.
We don’t believe in labeling projects by difficulty, because the level of difficulty is highly dependent on your particular skills. To help you find a great project, we list the skills needed, and try to emphasize where strong skills with particular tools are likely to be important for a given project.
We will never reject a strong applicant because their project idea was not a top priority. On the flip side, we often reject applicants proposing valuable projects when we haven’t seen compelling work from the applicant.
More important to us than specific deliverables in a project proposal is a clear body of work to focus on. E.g., if we see a proposal with 8 Markdown processor issues, we’ll interpret this as an applicant excited to work on the Markdown processor for the summer, even if the specific set of 8 issues may not be the right ones to invest in.
For 2022, we are particularly interested in GSoC contributors who have strong skills at visual design, HTML/CSS, mobile development, full stack feature development, performance optimization, or Electron. So if you’re an applicant with those skills and are looking for an organization to join, we’d love to talk to you!
The Zulip project has a huge surface area, so even when we’re focused on something, a large amount of essential work goes into other parts of the project. Every area of Zulip could benefit from the work of a contributor with strong programming skills, so don’t feel discouraged if the areas mentioned above are not your main strength.
GSoC offers two project size options: 175 hours and 350 hours. We have designed all our projects to have incremental milestones that can be completed throughout the summer. Consequently, all Zulip projects described below are compatible with either project size. Of course, the amount of progress you will be expected to make depends on whether you are doing a 175-hour or 350-hour project.
Full stack and web frontend focused projects
Cluster of priority features. Implement a cluster of new full stack features for Zulip. The high priority label documents hundreds of issues that we’ve identified as important to the project. A great project can be 3-5 significant features around a theme (often, but not necessarily, an area label; the goal will be to implement and get fully merged a cluster of features with a meaningful impact on the project. 175 or 350 hours; difficulty will vary. Experts and skills depend on the features; Tim Abbott will help you select an appropriate cluster once we’ve gotten to know you and your strengths through getting involved in the project.
Zulip’s REST API documentation, which is an important resource for any organization integrating with Zulip. Zulip has a nice framework for writing API documentation built by past GSoC students based on the OpenAPI standard with built-in automated tests of the data both the Python and curl examples. However, the documentation isn’t yet what we’re hoping for: there are a few dozen endpoints that are missing, several of which are quite important, the visual design isn’t perfect (especially for e.g.
GET /events), many template could be deleted with a bit of framework effort, etc. See the API docs area label for many specific projects in the area. Our goal for the summer is for 1-2 students to resolve all open issues related to the REST API documentation. 175 or 350 hours; difficulty easy or medium. Skill required: Python programming. Expertise with reading documentation and English writing are valuable, and product thinking about the experience of using third-party APIs is very helpful. Expert: Lauryn Menard.
Implement important full-stack features for open source projects using Zulip, including default stream groups and improvements to the upcoming public access feature. Experts: Tim Abbott, Aman Agrawal. Many of these issues have open PRs with substantial work towards the goal, but each of them is likely to have dozens of adjacent or follow-up tasks. 175 or 350 hours; easy or medium. The most important skill for this work is carefully thinking through and verifying changes that affect multiple configurations.
Fill in gaps, fix bugs, and improve the framework for Zulip’s library of native integrations. We have about 120 native integrations, but there’s more that would be valuable to add, and several extensions to the framework that would dramatically improve the user experience of using these, such as being able to do callbacks to third-party services like Stripe to display more user-friendly notifications. The the integrations label on GitHub lists some of the priorities here (many of which are great preparatory projects). 175 or 350 hours; medium difficulty with various possible difficult extensions. Skills required: Strong Python experience, will to install and do careful manual testing of third-party products. Fluent English, usability sense and/or technical writing skills are all pluses. Expert: Zixuan Li.
Experts: Greg Price, Austin Riba, Steve Howell.
Extend Zulip’s meta-integration that converts the Slack incoming webhook API to post messages into Zulip. Zulip has several dozen native integrations (https://zulip.com/integrations/), but Slack has a ton more. We should build an interface to make all of Slack’s numerous third-party integrations work with Zulip as well, by basically building a Zulip incoming webhook interface that accepts the Slack API (if you just put in a Zulip server URL as your “Slack server”). Skills required: Strong Python experience; experience with the Slack API a plus. Work should include documenting the system and advertising it. 175 or 350 hours; medium to difficult. Expert: Tim Abbott.
Visual and user experience design work on the core Zulip web UI. We’re particularly excited about students who are interested in making our CSS clean and readable as part of working on the UI; we are working on a major redesign and have a lot of plans that we believe will substantially improve the application but require care and determination to implement and integrate. 175 or 350 hours; medium to difficult. Skills required: Design, HTML and CSS skills; most important is the ability to carefully verify that one’s changes are correct and will not break other parts of the app; design changes are very rewarding since they are highly user-facing, but that also means there is a higher bar for correctness and reviewability for one’s work. A great application would include PRs making small, clean improvements to the Zulip UI (whether logged-in or logged-out pages). Experts: Aman Agrawal, Alya Abbott.
Build support for outgoing webhooks and slash commands into Zulip to improve its chat-ops capabilities. There’s an old pull request with a lot of work on the outgoing webhooks piece of this feature that would need to be cleaned up and finished, and then we need to build support for slash commands, some example integrations, and a full set of documentation and tests. Recommended reading includes Slack’s documentation for these features, the Zulip message sending code path, and the linked pull request. 175 or 350 hours; easy to medium. Skills required: Strong Python/Django skills. Expert: Steve Howell.
Build a system for managing Zulip bots entirely on the web. Right now, there’s a somewhat cumbersome process where you download the API bindings, create a bot with an API key, put it in configuration files, etc. We’d like to move to a model where a bot could easily progress from being a quick prototype to being a third-party extension to being built into Zulip. And then for built-in bots, one should be able to click a few buttons of configuration on the web to set them up and include them in your organization. We’ve developed a number of example bots in the
Work on Zulip’s development and testing infrastructure. Zulip is a project that takes great pride in building great tools for development, but there’s always more to do to make the experience delightful. Significantly, about 10% of Zulip’s open issues are ideas for how to improve the project’s contributor experience, and are in these four labels for tooling improvements.
This is a somewhat unusual project, in that it would likely consist of dozens of small improvements to the overall codebase, but this sort of work has a huge impact on the experience of other Zulip developers and thus the community as a whole (project leader Tim Abbott spends more time on the development experience than any other single area).
A possible specific larger project in this space is working on adding mypy stubs for Django in mypy to make our type checking more powerful. Read our mypy blog post for details on how mypy works and is integrated into Zulip. This specific project is ideal for a strong contributor interested in type systems. See this issue for details on the current state of this work. 175 or 350 hours; difficult.
Skills required: Python, some DevOps, and a passion for checking your work carefully. A strong applicant for this will have completed several projects in these areas.
Experts: Anders Kaseorg (provision, testing), Steve Howell (tooling, testing).
React Native mobile app
Code: React Native mobile app. Experts: Greg Price, Chris Bobbe.
The highest priority for the Zulip project overall is improving the Zulip React Native mobile app.
Work on issues and polish for the app. You can see the open issues here. There are a few hundred open issues across the project, and likely many more problems that nobody has found yet; in the short term, it needs polish, bug finding/squashing, and debugging. So browse the open issues, play with the app, and get involved! Goals include parity with the web app (in terms of what you can do), parity with Slack (in terms of the visuals), world-class scrolling and narrowing performance, and a great codebase.
A good project proposal here will bundle together a few focus areas that you want to make really great (e.g. the message composing, editing, and reacting experience), that you can work on over the summer. We’d love to have multiple students working on this area if we have enough strong applicants. 175 or 350 hours; medium to difficult.
Electron desktop app
Contribute to our Electron-based desktop client application. There’s plenty of feature/UI work to do, but focus areas for us include things to (1) improve the release process for the app, using automated testing, TypeScript, etc. and (2) polish the UI. Browse the open issues and get involved! 175 or 350 hours. This is a difficult project because it is important user-facing code with good automated testing, so the bar for convincing others your work is correct is high.
Good preparation for desktop app projects is to (1) try out the app and see if you can find bugs or polish problems lacking open issues and report them and (2) fix some polish issues in either the Electron app or the Zulip web frontend (which is used by the electron app).
Prototype a next generation Zulip desktop app implemented using the Tauri Rust-based framework. Tauri is a promising new project that we believe is likely a better technical direction for client applications than Electron for desktop apps for security and resource consumption reasons. The goal of this project would be to build a working prototype to evaluate to what extent Tauri is a viable platform for us to migrate the Zulip desktop app to. 350 hours only; difficult. Skill required: Ability to learn quickly.
Code: Zulip Terminal Experts: Aman Agrawal, Neil Pilgrim.
Work on Zulip Terminal, the official terminal client for Zulip. zulip-terminal is already a basic usable client, but it needs a lot of work to approach the web app’s quality level. We would be happy to accept multiple strong students to work on this project. Our goal for this summer is to improve its quality enough that we can upgrade it from an alpha to an advertised feature. 175 or 350 hours; medium difficulty. Skills required: Python 3 development skills, good communication and project management skills, good at reading code and testing.
Code: zulip-archive Experts: Rein Zustand, Steve Howell
Work on zulip-archive, which provides a Google-indexable read-only archive of Zulip conversations. The issue tracker for the project has a great set of introductory/small projects; the overall goal is to make the project super convenient to use for our OSS communities. 175 or 350 hours; medium difficulty. Skills useful: Python 3, reading feedback from users, CSS, GitHub Actions.
Circulating proposals (March to April)
If you’re applying to GSoC, we’d like you to publicly post a rough draft of a few sections of your proposal at least one week before the application deadline. That way, the whole development community has a chance to give you feedback and help you improve your proposal.
What to post: Please include (1) Links to your contributions to Zulip (or other projects), and (2) a paragraph or two explaining what you plan to work on.
How to post: We generally prefer Dropbox Paper or Google Docs, since those platforms allow people to look at the text without having to log in or download a particular app, and you can update the draft as you improve your idea.
Thanks for being interested in Zulip! We’re always happy to help volunteers get started contributing to our open-source project, whether or not they go through GSoC. We hope to hear from you soon!