top of page

Contributing Code in the Age of COVID-19: How We Came Together For an Open Source Hackathon

TL;DR: We successfully transformed a traditionally offline Goodness Squad event (a meetup focused on contributing to open source projects) completely online utilizing some pretty cool tools and solutions and even had an online afterparty to celebrate our success - in just about three hours 35 participants wrote 1,158 lines of code working through a month-long plan for selected projects - completed 19 tasks, and created 21 pull requests.

In a matter of just days, it seems, the whole world has shifted online and all the offline events, such as meetups and hackathons, had to follow, inevitably switching online as well.

Most online events nowadays are, basically, live streams of offline events. But it just doesn't quite work like that. Thus we set out to find the best format out there - and tested (and still keep testing) a lot of various tools.

In this article I will share with you what we found, and the experience of organizing the first fully online Goodness Squad Event and what we learned from it.

Wix Engineering is a major supporter of OSS - we encourage our engineers and support them in open-sourcing their own tools and products and in contributing to existing Wix OSS projects, as well as some of the world's most popular projects.

And this is where Goodness Squad truly comes in. It is Wix Engineering’s favourite format - we pick OSS projects that need support, contact their maintainers and bring them together for a round table. We then work with maintainers to define a set of tasks they want to cover and form a backlog of tasks for participants.

Historically, an online community called JavaScript Israel invented and structured this event as a hackathon. Maintainers of OSS projects and open source contributors work together and dive deep into code and the architecture. Three hours of hands-on contributions to the Open Source community, bug fixes, feature improvements, and of polishing of skills.

Since we really wanted to test out doing this in an online format, we decided to focus on a particular locality - Ukraine in this case. We made a Call For Projects, put together a list of open source projects that were open to giving us a go, and eventually picked four projects to work on:

  • PandAid - An online platform for coordinating actions between charities, volunteer organizations and organizations in need.

  • Icecast-parser - NodeJS module for getting and parsing metadata from SHOUTcast/Icecast radio streams.

  • JS tl;dr - zen-mode javascript documentation that provides info on language essentials in a noiseless, zen-mode manner.

RehabJs - Wix library developed in the Kyiv Mobile Guild for React and React Native projects. RehabJs allows making snapshots of the network layer, state managers’ states, navigation libraries, etc. And it works with the speed of unit tests.

Now, usually hackathons are purely offline events with their own vibe - plus it goes without saying that when we set out to move everything online we had several serious concerns:

  1. Communication - How will people be productive in their online communication and also have a chance to have one-on-one talks when it’s a crowd of 50 participants, plus they are split into groups of 5?

  2. Tasks Distribution - How should we distribute tasks among people we barely know? How should we track tasks and progress?

  3. Networking - How can we keep the networking / collaboration part and the hackathon vibe? How can we share the Wix vibe?

  4. Engagement - How can we make people come to and stay at a free online event?

And here’s how we addressed all of the above:


We put ourselves in engineers’ shoes and kept in mind that you should always do it their way, not your way. If the Open Source community you’re working with is using a specific communication tool (Discord in this case), then why would you want to put them all in a Zoom meeting?

Discord covers all of the communication problems. Basically it works like a combination of Slack+Zoom - you can divide your Discord server into spaces, and spaces into channels. It can be a text channel or an audio/video channel (unfortunately you cannot combine text and audio/video call in one channel).

We created a Discord Server for our event and set up the following channels:

  • General text channel with open access for all participants was used for text communication between contributors, OSS maintainers and organizers

  • Closed org text channel for orgs only - for text communication between organizers

  • Closed text channel for maintainers and orgs

  • OSS Spaces that had 2 channels each: audio/video where each working group was on for the duration of the whole event, and a text channel for additional communications - to share files, code, etc.

Maintainers were the main speakers in their respective channels - they presented their projects, reviewed and assigned tasks, and answered questions.

Participants communicated on technical issues within their channel and were able to contact each and anyone else personally for private chats.

Tasks distribution

Prior to the event, project maintainers created a set of tasks that varied in the set of skills that was required to tackle them and in levels of complexity. In order to not use multiple unrelated tools, we decided to utilize the full potential of GitHub and went with Github Projects, which allowed us to assign tasks, change their status and add labels and comments (again, an example of meeting devs where they feel comfortable). Maintainers set up GitHub Project Boards per each OSS and enrolled participants there.

At the very beginning of the event we held a small ice breaking session with presentations from each group - participants talked about their experience levels and skill sets, so that maintainers could assign tasks accordingly.


We wanted participants to make new connections throughout the event, to chat about different topics and have a place to unwind and regroup. As Discord was filled with tech discussions we decided to get another tool for informal chats and smalltalk.

Enter Spatial. It turned out to be the real game changer. In its basic form it is a black endless field where people are represented by circles and their faces are displayed via webcams. You can move through the space and get closer to people to hear them and talk to them - as in if you move your “avatar” away from them, their sound fades out. Just like in real life - remember what parties or working in crowded offices used to feel like (sigh)?

Options and functionality of Spatial are limited - you can add images and videos - that's it. But people need directions in order to be able to navigate around new places. So we created a digital map of our virtual “venue” in a jpeg format and added it as a simple image. We had several locations - a stage, projects areas, and even a bar - all so that people could, say, decide to meet at the bar to discuss official announcements they heard from the stage, or hang out in project areas to talk to maintainers about the projects they were working on. This is how it looks:


We want people to be comfortable, open, inspired, we want people to have fun, because in the end that’s what it’s all about.

We wanted people to fill this vibe even through an online event and want to stay till the very end. So we put together Goodness Squad Boxes - physical boxes, each filled with Wix Engineering’s merch, containing a 1 kilo pack of popcorn and a set for mixing cocktails. Prior to the event we sent a box personally to each participant - to show that we cared about their commitment and participation.

At the end of the event we threw an afterparty with a cocktail workshop - a bartender streamed the workshop to the bar inside Spatial and participants were mixing, drinking, and chatting on the go. Of course people stayed till the end of the event and even longer!

Eventually in just about three hours 35 participants worked through a month-long plan for selected projects - completed 19 tasks, created 21 pull requests and wrote 1,158 lines of code.

Moreover, during the event maintainers had a chance to promote their projects to the wider audience and attract new contributors who could continue to work together even after the event had ended. And the contributors finally had some time to sit down and work on Open Source projects.

In particular, one of the contributors in the PandAid work group created their first ever pull request on an Open Source project during our event.

Putting together and holding an online-only Goodness Squad hackathon was quite challenging for both organizers and participants. Yet that is also what made it so special and even awesome! We have definitely learned a lot about converting an offline event to an online one - thankfully nowadays there are plenty of cool and accessible tools to help with that.

And though we all can’t wait to get back together in person and plan out yet another Goodness Squad, an offline one this time, we might as well apply the lessons we learned and throw a bit of online into the mix. Especially now that we know how it needs to be done.


This post was written by Daria Tkhorevska


For more engineering updates and insights:


bottom of page