Crowdsourced Software Projects

What if our medical AI startup made all of our research public and worked directly with the online Discord community to develop the most useful open models? Kind of scary to have a company's research progress fully transparent, but I think pro-open source, crowd-sourced collective intelligence approaches to research are an under-appreciated resource. We're now giving away compute and focusing on optimizing the Discord "science-in-the-open" workflow. We want to collaborate with volunteers and academics to train great models & publish top papers. Last week we hosted 3 public Google Meets to share our work on fMRI foundation models, real-time brain-to-image decoding, and pathology foundation models. Below are the links to the recordings from these meetings: fmri foundation model: https://lnkd.in/ew8_iWwh pathology foundation model: https://lnkd.in/eWCJBcpA real-time brain-to-image: https://lnkd.in/e5MUXX9g For some more context, I've successfully led a few successful and a few unsuccessful Discord-based research collaborations in the past. I've seen that most of the time these open science projects fail. I'm now also sharing a 10-page blog post on my philosophy behind why Discord collaborations often fall apart and our strategies to ensure that doesn't happen with any of the projects we support at MedARC. https://lnkd.in/eXUdNWU3 We also want to support the medical AI online research ecosystem more generally—if you want to lead your own research project (e.g., as an independent researcher or as an academic in a lab) we are keen to hear from you and we can potentially support you by providing you access to compute, our community, and our structured support to ensure you reach your goals. Join us on Discord: https://lnkd.in/eT7Ed7X5

We have had over 20 people contribute to Neosync in the last 6 months. If you’re working on an open source project and are looking for contributors, here are the steps that I would take to get your first contributors. 1. Sync your project management tool with Github. We use Linear <> Github sync (https://synclinear.com/). This will pull all of the issues that you tag with a ‘Public’ tag into Github. 2. Create tickets that are very well defined and isolated that someone who has no knowledge of your application can work on. Ideally, it should be limited to 1-2 files in your codebase and be easily testable. 3. Tag the issue with the 'Public' and ‘Good First Issue’ tag. There is a website that scraps these issues from Github that many developers new to open source go to. 4. As soon as someone shows interest in working on an issue, reply right away and give them a very clear guide on how to complete the issue. You almost want to do the work for them. This might seem like a lot of work, but your goal should be to get someone interested in contributing to submitting and merging their first PR as soon as humanly possible. 5. Once they’re done, thank them! If you have the means, send them some swag like a t-shirt or sticker Increasing your contributor count is a great way to get other contributors and build buzz around your project.

We decided to build an open-source project and here are a few tips that helped us grow and get huge companies like Amazon, Microsoft, IBM and Google to use and promote our product. 1. Organic reach: we published the project everywhere we could, and repeated that. Hacker News seemed to be the best place to get that first momentum. Yes, the website looks like it was taken from the 90s, but you'd be surprised at how many industry leaders are reading through posts there on a daily basis. Also worked well for us are dedicated Reddit communities, and to some extend Twitter/X. 2. Friendly Experience: we made our OSS friendly for first-time contributors from day 1. We opened around 10 issues in the repository with various degrees of complexity, tagged some with "good first issue" so that GitHub search engine can index our repo and opened a community slack workspace so people can ask questions or request guidance easily. 3. Quick Response: we monitored our open-source activity closely. We set up Zappier integrations so we get notified whenever someone opened an issue or a PR on the repo - so we can respond quickly. The first few contributors are looking for a quick feedback and may quickly abandon your project if they don't see maintainer activity. Community: we actively engaged with the community. We arranged webinars, answered questions, and were quick to fix bugs that were opened. This helped gain the trust that we need to make this succeed. Building and maintaining an open-source requires constant dedication of time and effort. But once you do it right, it’s a great way to get exposure to what you’re building. What is your story? How do you grow your open-source projects?