A Better Open-Source Future

At the end of March, I had the privilege of attending AtmosphereConf in Vancouver. The conference was excellent, and there were so many amazing projects. However, throughout my conversations with all kinds of people, the most common answer to "What do you think Atproto needs most?" was various forms of "Money! Right now there are lots of cool hobby projects, but that won't sustain the ecosystem forever." I wholeheartedly agree with this response. It was the biggest question I had going into the conference, and it remained the biggest question I had leaving. Although there were a handful of talks with a financial focus, I didn't have a "This is the answer!" moment. This is mainly because the ideas I heard essentially boil down to various forms of asking for grants, donations, and venture capital (VC) money. VCs, grants, and donations alone will not sustain us! Until we have some true working answers, we all need to focus on and discuss this question, because having—or not having—an answer will be a key in deciding the long-term fate of our ecosystem. I don't have all the answers, but I do think I have some potentially interesting conversation starters to help get us there. On the way home from the conference, my immediate reaction was to start thinking about solutions to this problem. In my view, the ideal solution would maintain the values of this community while providing the people who help build it with at least a stable income to live comfortably. Personally, since I started working on Atproto, these are the community values I've come to love: - Local & open-source first solutions - User-owned data - Collaboration and interoperability of apps You can probably think of others, but for me, these are real, tangible values that I think we're all set out to make sustainable for years to come. The State of Open Source With our values and goals defined, we can now start working out some solutions to get us to our end goal of financial sustainability. Since the current community seems so open-source oriented, this became the focus point of my inner thoughts. The question was: Why does open source have to be so inherently unprofitable, especially for smaller developers? Traditionally, the funding model for open-source projects seems to involve variations of the following: - Donations / Supporter Buttons: With limited resources, developers usually start here. - Grants & Corporate Sponsors: If the project can become important or a critical failure point - VC Funding: Usually a tool to get to the next two stages. - Freemium: A free open-source app with premium closed-source features. - Paid Hosting / Infrastructure: Free open-source code paired with paid hosting. (If you can think of others, I'd love to hear them! Please reach out to me!) My Perspective: The current culture of open source makes it feel like charity work. It's something you do to build your resume or street cred to get to "real" business models that actually make money. And if you're focused on open-source, you better have a plan to introduce something closed-source at some point if you ever want to make a buck. I think this logic is flawed. Open source powers our world. Every device you own and use likely has open-source code for various mission-critical components. Even projects that are 100% open source are often providing tremendous value to the community. It's strange to me that these projects so often resort to a donation for financial support. How can we build a system where 100% open source projects can still make an income? No VC funding, no Freemium, no Paid Hosting, and no grants & sponsors. Not that these paths are inherently bad, but because good open-source software is inherently valuable. It should not be seen in any way as charity work. To Fight a System, You Need a New System One path to having Atproto flourish economically is to have a system where open source can be equally (if not more) competitive than closed source. To have open source become a true competitor to closed source, we need a system that balances incentives better than donations and freemium models. Having a good balance means everyone involved feels like they receive a fair deal for what they put in. To really get a holistic picture, let's start before a developer even decides to take money at all. This is very important because it helps us realize that the imbalance starts even before any transactions are involved. At this point, the developer creates a product purely because they think it should be created. Let's assume that although this is a passion project, the goal is to grow it to a large number of people. As the project grows and more users join, they generally start to request features. This can be small additions like, "Make this text bigger," or major system changes like, "Make permissioned data for Atproto." This is exciting, but too often it is the first major incentive imbalance—one that generally has the user taking advantage of the developer because there are so many requests for features with little offer to pay in return. It's at this point that developers often ask for donations. Donations are great for developers because they are direct cash from the user, no questions asked. Sometimes this goes well, as respected developers can retain lots of patrons to fund their development full-time. However, there could be an incentive imbalance for both the developer and the user, as this purely relies on trust that the developer will use the funds in good faith OR the user paying as a thanks for something they've already received for free. Queue all the prompts that guilt people to donate. To make it a little clearer as to what funds will be used for, developers often go to crowdfunding. This requires the developer to create a listing of what they want to build and usually a funding goal of how much they estimate the cost of the project to be. I emphasized "developers" because for large platforms, there could be thousands of feature requests. Asking the developer to create campaigns for every feature would be very costly and time-consuming. This also requires the developer to prioritize what features even need campaigns. Additionally, we still have an issue where users generally have to trust and patiently wait for a feature to be developed. For one reason or another, the developer could take the money and run, or choose to switch to other features the community doesn't want. Suppose users and developers build a new platform to crowdsource features, letting users vote and pledge what they’d pay. A developer might then pivot: “If you want these features, I’ll go closed-source and charge a monthly fee.” While this simplifies access and can out-earn crowdfunding in the long term, it introduces risk in the short-term as competitors could still rally up-front funds. Yet as the closed-source product scales, the ecosystem as a whole suffers as it creates huge barriers to entry. Crucially, going closed-source opens the door to venture capital, which demands returns. That pressure subtly shifts priorities: small, incremental changes begin favoring profit over user benefit, eventually leading to enshittification—where innovation stalls and user-centric features become afterthoughts. Open-source software counters this process, as any features developed are ultimately released and owned by the community, ensuring that the product source code never disappears, the community can directly adapt the project to their needs over time. No small group of developers have ultimate ownership and control. A new system for donation developers To address all theses issues above, we propose a new model for open-source developers to not have to resort to broken donation systems for income. It's a new type of crowdfunding where the community as a whole leads proposing features, and incentives are balanced to help ensure everyone receives a fair deal. In this system, there are three key players: - The developer(s) - The broker / platform to facilitate transactions - The users / community members Here's how the system works: - Feature Creation: Anyone, from users to the developers themselves, can propose a new feature. - Funding Estimation: Users estimate how much they would pay if the feature were developed. - This step requires no actual payment from the user, but to help limit spam, we only allow the user to estimate up to $25 or double the largest previous successful contribution. - Although no funds are transferred, this gives the developer an idea of what features to prioritize. - Development: The developer marks a proposal as "in development" to let the users know that they have started working on the feature. They can set a funding goal to estimate the full cost of development. Users get an additional option to donate directly to the developer as they estimate the full amount they would pay to have the feature completed. This allows the user to send some funds upfront to help cover development costs, as well as indicate the full amount they would pay to have the feature finished. - Important! To ensure the developer doesn't give the feature away for free, they should develop it in private using a temporarily feature branch to a private repository. - Public Preview: The developer deploys their code to a "Public Preview" environment that, for a limited time, has the feature included. The developer should spend some time documenting exactly how to access the created features and what they should do. Users now have only one option, which is to fund the release of the feature. This will start an escrow process and send the users' funds to the platform handling the payments (not the developer!) until the feature is released. - Open Source Release: As the users review and pledge funds during the public preview, the developer can then decide one of two paths. They can choose to say that the funds weren't enough and receive nothing, or they can start the process of releasing the code to the open-source repository for the project. - Important! It is required to release code to open source to receive any non-donation funding on the platform. - Verification & Funds Release: Once the developer releases their code to an open-source branch, the proposal enters a verification period where all parties can fork or copy the codebase. The users can also create a dispute for the platform to say that the released code did not match the public preview. For this reason, the public preview must stay available and documented for the entire duration of the proposal. What's the overall point of this process? First, it's a message to open-source developers. Stop giving away all your great creations for free!!! What you're creating is valuable, and you deserve to be paid for it! Just because one user likely can't pay you fully for the feature doesn't mean you need to resort to begging for donations, or going closed source to fund it! Second, it's a message to the AtProto community. We can get creative. We can try new ideas. We don't have to keep using the same sub-par systems of the past. Just break the systems down into their fundamental components, and design a new ones that align to new values. As an initial draft of this process, we've created StratosFund.at! You can try it out today by posting features for your favorite platforms (including your own!) to let the creators know what features you'd like developed, and how much you would be willing to pay for them to be prioritized. Do I think this is a silver bullet to making a renaissance for open-source development? I don't know, and only time will tell. My overall point with making this is to start a discussion, because as I mentioned before, I think we need to have more discussions and start trying things. It's the most pressing issue of the moment, and the future of the communities values depends on it.