Open Source Hub - Your Developer Community Needs More Than a Hackathon

Transcript

side of the uh screen. Good luck to Yeah. >> Okay. Thank you very much. Um thank you very much for joining us here today and um also the people online. So my name is Mario Balink. I'm originally from Germany but um I've been around um Asia for many years lived in um um Singapore in Vietnam, Taiwan um and of course I've been many times to to India. Um I'm here with um my um yeah collaborator Satsaf. >> Yes. So hi all. Uh I am Shaw Ashwin. Uh I am based out of Bangalore uh India and uh I've been with Fors Asia for quite some time now. I I started as a contributor now I'm there as a mentor and a developer. So hi.

>> Yeah. Cool. So um the question we want to talk here uh today about is like uh um your developer community needs more than a hackathon. Um and um I think this is very relevant uh for many companies and projects because um um many companies like uh to yeah connect with the developer community um through a hackathon um but then like um they hand over the price um everyone goes home and then the question is what happens afterwards. Yeah. um often they are not sure like the hackathon is sometimes organized by the marketing department um or different departments but uh for us it's actually um um just a start and we want to share a bit of what we do um with force Asia so um Satov you've been

on board like for around like um over 3 years now and you become a a core team member so you can share this from your own experience um and uh like I'm as I'm longtime with this community Um like our goal is always to hand over also to the new generation. So um I will come back a bit later to the talk but let you um um lead this here for now. So thank you very much. Big round of applause for Satav. >> Okay. So uh I think one of the main questions uh that uh requires answering with hackathons and events organized by the uh organizations are like how do we keep the enthusiasm alive afterwards

uh because coming from a contributor side I've seen this many thing like uh joining an exciting project or like finding the right issue and like getting a review is one other thing but how to be involved as a community member for the months that is to come. Uh and like what are the possible uh people, how to meet people, how to connect them, what are the tools that can be used and like what are the basic habits that will help in a long-term processes like uh what I want to share with you guys. So think about the last hackathon you joined or organized. How many of those project are actively maintained today? Uh yeah so hackathon is something that

creates a very good uh spark. It is excellent at concentrating the energy. People meet teammates, they learn quickly, they build and ship prototypes and celebrate the victory. But it doesn't just end there. The problem is assuming that the event itself creates a sustainable project. Contrasting to this in 48 hours the goal may be to create a demo but the following 48 weeks is where the actual plan lies to create a sustainable project. Somebody has to try the bugs response to uh issues PRs update dependencies uh create documentation release and patching updates. The work is often less visible but the value is much greater over time.

So a community therefore needs planning of what happens when. So who welcomes the new contributors who are onboarding the project? Where does an unfinished prototype live? Who owns the next milestone? And what makes someone feel their effort matters? All these questions uh when answered right makes the new contributors welcome to a community. Uh so when you think back to the hackathon project that survived what happened after the event to keep it going the best place to design for continuity is the contributor journey itself.

Design for the next contribution that you expect to get. Every handoff is a place where newcomer can disappear or grow. We often celebrate somebody's first contribution but the se second contribution is a better sign that they have found a place in the project uh with themselves. So this five-stage journey makes it a bit more visible. A contributor can find the community the documentation the project and the interests within them. But to start they have a manageable task the instructions that actually work get a proper review that provides insightful feedback and a maintainer responding to the task that

is assigned to them is the most helpful feedback that a contributor can get. The reasoning behind these things are not only a list of corrections written the contributor knows where to go next and make an impactful change. Eventually they become a reviewer and this cycle can go on and on. A maintainer to a mentor. The weak point is often the handoff. A promising new customer can disappear fast if an issue is outdated or setup takes multiple days or a PR gets no response. So the fast respectful review helps the community building activity and not just mere quality or

code control events help developers discover this path but a healthy community ensure that there is somewhere to go after the event and it's they make sure that it is not just a one-off thing. So Faceatia illustrates how the same approach can work across many projects and many years from one gathering to an ecosystem. Fosatia began in 2009 and grew into an ecosystem of projects, events and contributors rather than remaining a single gathering. The figures here come from the session description. So more than thou 100,000 young people reached through open source activity worked spanning over 200 plus repositories and these numbers are not the main lesson.

What matters is creating the continuous impact. People first arrive through an event or a workshop or a shared technical interest in any of the projects. They find the projects that are open for participation. They learn by contributing to it and later help others take the same steps. A repository itself is not a community. It needs people willing to review, explain and maintain the project. Uh uh and Faceia has multiple projects like this. We have uh event, we have a bunch of hardware projects. We have uh dedicated contributor programs and we have uh recurring developer gathering.

Uh that becomes a crucial entry point for new and upcoming contributors. So, how can a relatively small core team support that much ongoing collaboration? Oh, no. Sorry. Yeah. Uh, so think of uh an open source opensource system as like uh three parts that reinforce each other. The first is the developer network.

uh people stay involved and when their recognized names know where to ask questions and can connect with maintainers and peers those relationship turn anonymous repository activities into actual collaboration. The second is automation. Volunteer organizers and maintenance have very limited time. They can't spend too much time on very repeated tasks. So finding pending reviews, sharing progress of flagging blockers can be streamlined giving people more time for difficult decisions that is there to make. And the third is human mentorship. A tool can tell us that a PR is okay uh can be merged or cannot be merged but it cannot fully

understand why someone is struggling to make the change that they want to and how to give constructive feedback of when to trust them with ownership. Mentorship develops confidence and judgment. If you run a developer group, create a place to connect, automate a repetitive workflow, and make sure newcomers know a real person they can ask for help. So, uh there are multiple automation tools that can be used for this. Uh and like this is one of the uh methods. So the goal of automation is to make the contributions easier to understand not to replace the maintenance. In a

distributed project, useful work happens across commits, PS, issue discussions and reviews. If each person must manually reconstruct this activity, it consumes time that could be spent on the project. Uh Faceia Scrum helper is one of the examples. It helps bring GitHub activity together into a human readable progress summary that gives contributors a starting point for reporting what changed, what remained blocked, and what they plan to do next. A summary can inform a conversation, but it cannot determine someone's contribution quality by itself. So walk through all these stages, gather the activity signals,

turn them into understandable updates, then have a maintainer decide whether to respond, review, unblock or recognize the work. Someone submits multiple PRs but small commits but it gets stuck awaiting review. The useful how outcome is not to have an higher activity score. It is recognizing the blocker and helping them proceed and getting a perfect output that is essential for the project and the community. AI can make the distinction between visible accuracy and genuine impact even more important.

AI coding assistants have lowered the effort required to produce code. This can help contributors learn and prototype faster, but it changes what we can infer from activity statistics. Counting commits, PRs, or lines of codes has always been imperfect. With AI assistance, those numbers are even less reliable as a measure of impact. When reviewing contributions, we should ask a strong question. Is there a real problem the change solves? Does the contributor understand the approach? Are these tests or examples that demonstrate the intended behavior? Have they considered all the edge cases, security,

performance, and maintainability? There are multiple questions. And could they explain or support the changes after the merge? A tiny fix that prevents a serious bug may be more valuable than hundreds of generated lines. reviews, documentation, user support and careful issue investigation also deserves recognition even though they can be hard to qualify. If someone submits a polished AI generated PR but cannot explain it, how would a mentor act towards them with a meaningful contribution?

This becomes obvious when software moves from a demo to a real event. uh and uh like an example uh is like uh let's say someone is contributing to uh events ticketing and the conference check-in flow. A feature can look complete in development environment but running it through a live conference create entirely different expectations. The flow has to work for organizers and attendees under time pressure. Implementing the feature and making the interaction understandable is a different thing. considering the error cases and trade-offs and making sure that other maintainers understanding the changes and monitoring real world

behavior and supporting the system is what makes an actual impact. Obviously fixing the issues and improved documentations and making the next deployment more reliable helps it in a longer run. Uh one of the main examples is uh we use badge printing and live checkin uh that requires more than a working button in all of the events. The they involve device flows, network connections, operational fallback and the ability to troubleshoot while people are waiting in real time in an actual event. So when something goes wrong, the human team and communication matters as much as the code. These responsibilities are also how a contributors becomes a trusted m

maintainer. Spaces like the open source hub right outside the event uh I mean outside the room help people meet the maintenance and projects where this learning happens. Oh sorry. Uh, yeah. The uh for so the open source hub here is a physical meeting point for people interested in building and sustaining open source project. Its value isn't just a collection of talks. It is the chance to meet the contributors, discuss the problems face to face and turn an introduction into a concrete next step.

Uh open source introduction is a starting place for people asking how to contribute for the first time. Open source careers explore the path from occasional participation to professional and sustainable maintenance work. All layers open encourages collaboration across different layers of technology from software and tooling to protocols and hardware. Before leaving the hub, try to make one introduction and agree for one follow-up action. For anyone building a community at home, uh here's kind of a simple plan.

So the creating a community growth is not a complicated framework. It is a very minimum viable follow-up that you have to take care after an interaction. First start with making the project approachable. Keep the setup instruction as simple as possible and label truly beginner friendly issues and assign a person who can review the contribution. Say explicitly where the questions should go. Then later retain the contributors that you get. Focus on the people who already started. Follow up on unfinished work. Unblock the remaining PRs and offer a second task that matches what the person can handle. Check-ins with contributors should help the

contributors. It just it should not just become mere paperwork and then grow. Give uh returning contributors small areas of ownership, invite them to review documentation, triage issues, help newcomers, and eventually mentor others. Once you unlock this cycle of creation, you can quickly get a newcomer, a sustaining member to your community. Those are the things that make a community last beyond any single event. A hackathon is an invitation. It brings people into a room, gives them reason to try something new and creates energy.

But a community is a commitment. The continuing choice to review, maintain, teach, ask for help and help others. Our main takeaway is simple. Don't design only for the participation on the day of the event. Design for the next issue, the next review, the next release, and the next person who needs help. Make it easy for someone to return to your project. Uh invite attendees to make themselves feel more comfortable with the project. And with this a hackathon be can become more than an invitation into a fullydriven commitment to join a community.

Any questions? >> Yeah. So there are a few questions of course. Um um of course the first question I would ask is uh um how um um do you now like uh transfer this knowledge that um um you also gained and like we continuously gain more knowledge in the for Asia Asia projects um as technology evolves. Um how do you transfer this um to other organizations to other companies? Um what what what could we do? How how how to start? I mean like um what could they do? So as I said the main thing is to get started and get familiarized with the project.

This can apply to any contribution any community in any organization. The main thing is to first find an interest in the project and then find a place to connect with the maintainers. Although in the age of AI anything it you can just put it in like an AI model and ask it to solve an issue. An actual commitment to a community only begins when you start interacting with the community members. When you start getting touched with the maintainers or the mentors who are available, who are there to help you out when you're struggling with something once you start that loop, you can break break out of the system of just staying with one contribution to becoming an active member to a community.

>> Yeah. So, um this is a a long learning curve of course that we had. Um I'm thinking also like if you're an organization um they can also actually learn from from us and from the wider um u community there are many open source projects there are um different um um like processes that they implemented and also many companies that uh learned uh from it. So Force Asia has been uh collaborating u with companies around the world. Of course like uh all the big tech companies in the US but uh I think uh with our position in Asia we also cooperating with uh um like the leading companies tech companies in China.

>> Um and um um this is also um where we can actually um collaborate um around the world and learn the best practices um around the world. So um I invite everyone for example to come to the force asia summit. So the first Asia summit happens next time from the uh 3rd of um no sorry it happens in in March. Yeah. The third month. >> Yeah. So um from the 7th to 9th of March um in Bangkok. So Bangkok also beautiful place. Many people would like to go. So we always uh happy to meet there and um please join us there. So there will be 4,000 developers um joining at at this event. But we have many other events also like in Indonesia um in Japan the

open source events that we uh are participating in and we're organizing the open tech summit in India. Actually the next open tech summit in India happens here uh right at Defcon um uh in two days uh on Thursday. We invite everyone also to uh join us in there and then like um we have the uh open source uh programs that we're organizing. So we're organizing for example a code heat program where we onboard u um new contributors but for us it's about free and open-source solutions. Yeah, it's not just hardware, it's not just software, it's not just knowledge, it's everything. Everything together, right?

Everything must be uh free and open. And we see how necessary it is. I mean, a few days ago, you saw the um hack at at Binance. Um they use a lot of open source, but I think not enough, right? And >> using this is not enough. We need contributors. We need a lot of people who check it. Even AI might miss it. One contributor might miss it. But the more people we have who check the code, who check the processes, who check whatever is possible um the u more secure we are and security is one thing that's becoming more and more important especially in the age of AI. So please um contact us um get together um with us at the events that we organize um but um

we're also happy to collaborate um in our coding uh contests. So for example, you can um um work on a partnership with us like many companies for example like the open atom Foundation in in China or the um Linux Foundation or so. Um yeah, you can also cooperate with us directly and we have some questions coming in here directly um also from um online and from the crowd in the room. Um so uh let's see. So where do I find connect with force Asia maintainers at Defcon? So we have the open-source hub uh at uh level three. Uh we have a table for for Asia there. So you guys can come meet with the maintainers, the developers uh and people behind for Asia and you guys

can connect with us at the open source hub at level 3 in devcon. >> Yeah. And uh here we have um a few questions actually which uh probably uh could be covered in several days if we answer that question completely which is like how to start as a contributor. um has been a hard time um in the age of AI and um so question here also like are we losing trustable contributors who give genuine love to open source um because of this you know there are a lot of challenges now in the age of AI um so how can we stand out I guess like the meaning here is how can contributors stand out I don't know this is these are huge questions do you have some take on

that >> yeah uh it is a difficult question maybe I can answer two of these questions things together. So the how to start as a contributor and how do we manage AI slop. So within the past few months es especially like when a community as big as foria we are active in multiple different programs like Google summer of code we get a lot of incoming contributions from new contributors around this time. So uh on a good on season we get usually around 10 ps per day but now we are getting about 50 PS per day which is getting hard to manage uh and to keep track of and most of this are a slop p. So we do keep in place some automation some testing and a bunch of rules that some of these PS needs to

follow and it becomes easy to uh classify some of them as sloppas and uh get rid of them easily. But uh the main thing that we see how people nowadays get started as a contributor is they take the time. They take the time to understand the project. They take the time to understand the workflow and most importantly they take the time to understand the use case for a project so that they can actually understand what they are contributing to. This can be very easily uh distinguished between the AI slop PS and these PS. When a person actually understanding the changes that matters and makes a PR, you can easily see that a per a person is actually there who understands why this change matters and why this change is needed.

Uh when compared to a person making an AIPR who has no idea what the project does >> and uh yeah this is related to another question that we see here on the screen which is like how do you guys manage AI slop PRs? Um like u of course u um yeah we have to come up with new u like processes and solutions all the time but like how how do how are we doing so far? >> So so far it's been good. It was hard when it started because we did not expect an explosion of PS to come our way. But now we have put up some uh guard rails that help us streamline some of the PR that we get. Uh and yeah that's mainly it but as I said again we

can actually distinguish when a person understands the project versus making an AI slope. Yeah. >> Yeah. So we have a lot of uh uh processes for example people need to post also like a a screencast um they need to sometimes explain um we have chat channels and so on um we don't have enough time to go now in detail to this questions but we have the open tech summit we have workshops there um happening here at the event in two days and there we will go in more details um and um yeah there are still a lot of other questions like how to um um provide incentives like beyond bounties beyond grants I can say career opportunities, startup opportunities, opportunities in this organization. There's a lot of u um u um

things that we can do. Please come to us, talk to us, visit us in Bangkok and