Why we archived a 5k+ Stars GitHub Open Source project

If your Open Source project had reached almost 6k Stars on GitHub and over 4k active users... would you archive it?

You’ve been working on a project full time for almost two years, it has accumulated thousands of Stars on its GitHub Repo, you’ve participated in an accelerator program for it, you’ve got swag and a merch store. Basically you are convinced that this is going to be the lifestyle business that you have been wanting…

So why would we archive the project and give it all up?

This blog post is about BioDrop (formerly LinkFree). But it’s also about why sometimes, no matter how much you will something to succeed and you put your all into it, the “it” just doesn’t work.

Eddie and Sara working on BioDrop every opportunity we got

Where it all began

If you watch Eddie’s YouTube channel, then you’ll know that Open Source is one of its biggest themes. The idea for BioDrop came from a livestream, where together with the EddieHub community, the objective was to create an Open Source alternative to the link sharing platform Linktree. If you are part of the amazing EddieHub community or you have seen it “in action”, then it probably won’t surprise you that the next day there were many Pull Requests for the project.

What followed were months of creating with the community what BioDrop was eventually going to become. Yes a platform where you could add your social links, but also a place where you could also connect with other users, check out and add what tech events you would be attending - an extension of the EddieHub community we would say. And the green square icing on the cake for the contributors? An opportunity to create your profile through a JSON file and a GitHub Repo where you could contribute and collaborate with others.

We saw such amazing uptake from the EddieHub community: we absolutely loved all the profiles which were being created and the fun the community was having playing with different tools and coming up with new features. Amazingly this was going beyond the EddieHub community. One day we woke up to several pages of new Pull Requests on our GitHub Repo of people wanting to set up their BioDrop Profile. Turns out our documentation on “How to create your BioDrop Profile with a JSON file” had been used as a case study and assignment for a lecture in a university in Asia!

Getting serious

After a year of approaching BioDrop entirely as a community project, we thought “What if there is scope to take this further?”

Whilst consulting and content creation are the bread and butter of our business, we had for a while been thinking how we would like to have a SaaS product which we turned into a lifestyle business. Could BioDrop be it?

To explore whether this was a possibility we thought it would be a good idea to apply for an accelerator program and the GitHub Accelerator seemed perfect: it focused on Open Source projects (✅ check) and guiding its owners and maintainers on making these sustainable (yes please).

We absorbed as much as we could during the ten week program. From that, as well as the chats we had with successful founders (we are so grateful for their time and advice) and consuming tonnes of content on the subject, we felt ready to turn BioDrop into a SaaS.

In addition to moving the project along and dealing with the community contributions - which were coming in thick and fast - we spent our time and personal financial resources on a rebranding exercise, logos, domains, social media accounts and most importantly for a SaaS - thinking about what type of paid product our users would find value from and what that price point would be.

The Open Source GitHub repo for BioDrop

Could this be “it”?

The intention for BioDrop was that there would:

1. always be a generous free tier and

2. a place where the community could contribute, develop their skills and collaborate.

Having spent thousands of hours over the years dedicated to the community, not only through EddieHub community projects, but through YouTube videos and livestreams as well as the EddieHub Discord, we did not see a reason why a part of the BioDrop project could not be turned into a SaaS. One thing was not going to change: we did not want to make money from the community, but in our view recognised that there could be some users who would see value in paying for a premium tier of BioDrop.

In hindsight we took way too long to get the premium tier out. Every example of a successful SaaS that we saw was telling us the same thing: “Get something out, it doesn’t have to be perfect.” But as that wasn’t really the decision why we archived the project, this is probably the subject for another blog. What we will say is, the speed at which we were able to work on the premium features and also the community’s response to it did have an impact.

We appreciate the there are countless projects where contributors are keen to contribute for free, when the project itself produces an entirely commercial product. But MongoDB and Elastic we were not. In retrospect we were perhaps a bit too over zealous on this front. We were so worried that we could be perceived as “exploiting” the community in some way by asking them to contribute towards what would be a premium feature. As a result premium features were labelled accordingly and Eddie took on 99% of the work required to get these features done - only asking our maintainers for help on this if he was absolutely stuck. Added to this the notifications on the community contributions were completely getting out of hand.

Turns out we didn’t need to worry about being perceived to ask the community to “work for free”. Any Issue or Pull Request with the label “Premium” might as well have read as “Radioactive”.

We would never be the ones to advocate for hustle culture, although we fully appreciate that hard work is necessary to achieve what you aim to do. But when you are completely burnt out from juggling the community and trying to run a business, and you are in perpetual survival mode - then it’s time to revaluate things.

And the noise kept getting louder

The effect of notifications for maintainers is a topic which is not talked about enough. Whilst we feel the aim of a community project is to encourage contributions and collaborations, what happens when you are dealing with notifications 24-7 and you are trying to build a SaaS at the same time?

During the GitHub Accelerator a cohort member had shared a blog by a maintainer who had decided to lock Issues until they were ready to be worked on. This was in no way gatekeeping, but had helped with managing notifications.

Have you ever come across an Issue where you scroll through the comments and all you see are contributors commenting “assign this to me” on repeat, over and over again? Often times the Issue had already been assigned. Or duplicate Issues were being raised and worked on causing conflicts for the maintainers to resolve. Plus there were the instances where Issues were raised that were just not in line with the project. This can be a little annoying right? Imagine this happening multiple times a day for months on end and as maintainers, feeling like resolving this is all you are doing (and in the meantime, those premium features you would like to work on are sidelined). So we made the decision to lock Issues until they were appropriately triaged. This was in a great part to save Eddie’s sanity and when explained to the community, taken on board. We were however not expecting this to be the catalyst for some of the project’s maintainers leaving.

A big part of what Eddie advocates is encouraging people to get into Open Source and particularly not being apprehensive about making their first contribution. It’s great when someone makes their first contribution as a result of this encouragement and maybe even on one of the livestreams! However in hindsight the BioDrop experience has changed our perception of pushing the “get your daily green square” approach.

Particularly in the last few years we are seeing a trend (if that’s the right word) of people making contributions for - in our opinion - the wrong reasons (such as swag or a green square only). This is not a criticism of competitions with prizes or that nice feeling of seeing a dark green grid on your GitHub Profile. But that should not be the only reason a contribution is made. Those types of contributions tend not to be thought out in terms of whether it will benefit the project and also how the community can collaborate.

Have multiple contributions made “for the sake of a green square” in the hundreds and you will have a maintainer who cannot cope. An example of this is the number of times the BioDrop footer moved - from left, to right, to the middle, then back to left then…you guessed it - back to the right again. Was there a reason for it? No.

Whilst some may consider this an unpopular opinion, we know that we are not alone in thinking this. Take a global event such as Hacktoberfest. They have modified their requirements and also their prizes to avoid these types contributions, and have as a result seen a downturn in participation.

Realising hard work isn’t everything

We realise that a product is not going to take off overnight and we are also not the type to make snap decisions. However, as months passed it was clear that BioDrop as a SaaS was not making a profit. When you consider the hosting costs of the web app and the database - we weren’t close to breaking even.

We want to emphasise that we had the most amazing maintainers.

Maybe we got too caught up in the community’s support at the start? Maybe we had incorrectly interpreted our careful market research?

Plus it can be demoralising to run a community project which also has a SaaS element. It is free for the community to use but it is costing you money. Your premium tier does not have near enough paid subscribers to cover those costs. Then there are the mounting notifications a lot of which were - let’s face it, noise - making it hard for you to come up for air. If these elements were not enough, you wake up one morning and someone had decided to write a script to keep refreshing their BioDrop Profile page so they would appear in the “Most Popular Profiles” list, which effectively load tested the app and double our costs. And this was not an isolated incident.

This makes you think: “What am I doing here?”

After much deliberation (and probably way too much of that too…) we decided to archive the project as of June 2024. We considered turning this back into a 100% community project: we disabled the premium tier and gave all these features for all users - but ultimately we felt the project could not continue.

We want to emphasise that we had had the most amazing maintainers, but it is important to remember they have a day job too and interests in other projects. Plus the reality had set in: having spent 99% of our time on this project, taking on minimal client work to contribute (not cover) living costs and going through our savings - this was no longer sustainable. It may seem like an all or nothing attitude but we needed to move on from the project and also start making money to live.

So what are the lessons?

Ah hindsight.

We have thought whether, if BioDrop was generating an income, would we have sucked it up with the level of notifications? Probably yes for a while - but we recognise that in the long run this would not have been healthy.

There are certainly elements that we feel we spent too long thinking about; such as the name and branding. Additionally we took too much time to deliberate whether we should archive the project and move on. In the meantime costs were mounting and we felt we didn't have the necessary closure to move on to the next project.

Then there is what many who will probably feel this is the most “controversial” lesson of all. We have worked with many clients who want to build a community around their product, after the product has been created - and this is not always an easy task. We thought “Well we already have the community, so support will be there right?”

The truth is the mindset needed to run a community and to run a business such as a SaaS, is completely different. Running a community which is just that - a community - requires a level of realisation that whilst many of its members are there to collaborate, there will be several instances where the green square, swag and “I’m going to use this as a place to test the new technology I learnt” and “This will look great on my resume” mentalities will be prevalent. Some will say that those things are what a community should provide. But this is not financially sustainable for an individual to run on their own. And as a founder is that the place to run a business? Our conclusion, probably not.