Closed-source will create more impact than open-source

When I was doing user research for our product a while back, I read the Game Developer Report and found the insights very useful. I took note of some of them as it applied to the idea we had. After that, I had completely forgotten about it. Recently, I stumbled across it again and after re-reading it I have some thoughts on it. The emphasis on open-source for every solution didn’t make sense to me.

To get some disclosures out of the way: We’ve developed a discussion and knowledge layer for DAOs. We’ve built a Discourse replacement for games that run as DAOs (where long form discussion is required). This platform combines both the forum and game identities as well. While it’s still very early stages, we’ve been tinkering away at it for the past six months. This addresses a lot of the issues under the “Community” section of the report.

I want to start by saying we are considering open-sourcing our product. However, the more and more we think about it, the more and more it just doesn’t make sense as a viable long term model. Frankly speaking, the reality of the current iteration of the product is that it’s mostly web2. Yes it has wallet auth and token weighted polling, but those are minor additions to what is primarily a clear SaaS type of product (like Discourse!).

Let’s say I were to open-source everything today. For one, the value accrual to the product owners (my team) will stop immediately. Most will fork it and run their own version. This means my team has no revenue to continue developing the product. We have many ideas (e.g. an open plugin system like Shopify) but realizing this goal will take many iterations. If we were revenue focused, we would know if we have product market fit. We know we will be building something people want, the moment they start paying. With open-source there is no true measurement of success. You can have metrics like “number of instances run” or “number of times forked” but I’m not sure those are valuable. Nothing will be as clear of a metric as revenue if you want to measure “value”. This will force you to develop features in the correct order, and with the correct cadence.

There’s also the big issue of death by committee. Instead of each feature being being prioritized how many extra customers it can get us, we would be pandering to the loudest committee members in the room and what they think is important. A product never becomes successful by pushing things, it’s always the demand pull. Nothing measures pull as well as someone paying you.

To be clear, this is not to say I think open-source software is terrible. I think open-source works really well when there’s value accrual to the people who develop every incremental step. This is evident in web3 ecosystem. OHM folks, yield farms, dexes were iterative, and every step pushed the needle forward. This worked well because, when you created an iteration within the model, you were directly rewarded with token appreciation. This incentivized 100s to constantly innovate to see what worked.

A lot of ideas mentioned in the report are primarily web2 ideas with a few web3 components. All of them can be built by sheer force of will (i.e. throwing money at the problem by setting bounties) but will they end up being the ideal solution that will create the most impact?

To illustrate this we can take a look at the e-commerce software market. Both Magento and Shopify were started around the same time. Shopify is closed-source and written in a niche prgramming language with a marketplace model. Magento is open-source and written in one of the most popular languages. The “open-source is always better” thesis would dictate that Magento should have become the go to solution for most e-commerce stores. Magento also has no shortage of localized partners that offer white glove implementation services. But in the end, Shopify dominantly captured the market and created the largest impact. It onboarded large amounts of stores and helped them be successful by creating a thriving ecosystem.

This is not to say that Magento was a failure; they were bought for over $1.5 billion, so they too created tremendous value. But I’m guessing most people outside the e-commerce scene haven’t even heard of Magento. Everyone knows Shopify. The difference in impact is pretty massive.

This brings me to my current dilemma. My thesis is that creating a platform with an open ecosystem, guided by monthly revenue from customers (which will act as the proxy for value) will be significantly more impactful than an open-source system guided by vanity metrics and committee based decision making. Since revenue is not a goal, the most fun and interesting ideas will automatically be prioritized over the more boring but useful solutions.

I’d like to receive feedback on my thesis. In particular why I’m wrong. I could have missed something, or the lens I’m seeing it through could be tainted and so I’m open to changing my mind since we are still in the early stages.

EDIT: Someone actually sent me this which talks about the same thing.


I love seeing these types of critical posts. I think they help us examine things in a dialectic manner which is an often lost form of discourse and analysis. The thesis is not necessarily wrong if we look at web3 like a web2 ecosystem and we continue to make the same value judgments as web2s many failed systems of market and governance.

We have to move away form this thinking and to a more equitable model of opportunity though in my opinion. This is why we have all been so excited about the 6551 protocol and the DID and SSI systems that will follow. This will allow us to set up systemic structure that can provide positive incentivization through equitable opportunity so open-source mechanisms start to mimic the level of return we see from web2 exclusionary models.

This Website and PDF: Have a plethora of useful knowledge about alternative frameworks and SOPs to enable Systemic structures, heterarchy, collaborative competition, and synergistic revenue-sharing mechanisms.



A few points about the post:

Revenue as a measure of success: While revenue is a crucial metric for traditional business models, it may not be the only measure of success for open-source projects. Open-source initiatives often prioritize different objectives, such as community growth, user adoption, and ecosystem development. These projects aim to build a strong user base, foster collaboration, and leverage network effects. Success in the open-source world can be measured by factors like community engagement, code contributions, active user base, and the project’s impact on the industry.

Development prioritization and decision-making: With open-source software, development priorities and decision-making are often influenced by the needs and contributions of the community. While it’s true that loud committee members can sometimes push for certain features, successful open-source projects establish governance models and decision-making processes that balance community input with long-term project vision. Engaging with the community can lead to innovative ideas and faster iterations, as different perspectives and expertise are brought to the table.

Value accrual and monetization: Open-source projects can still generate value and be monetized, even if the software itself is freely available. Many successful open-source projects have sustainable business models built around support, consulting, custom development, training, hosting, or premium features. By providing value-added services or products on top of the open-source core, companies can capture revenue while maintaining the benefits of open collaboration.

Impact and ecosystem development: The impact of a project is not solely determined by whether it is open-source or closed-source. Factors like usability, user experience, market fit, and ecosystem development play a crucial role. Open-source projects can foster vibrant ecosystems by enabling third-party developers and entrepreneurs to build upon the core software, creating a broader range of solutions and opportunities. Closed-source models, on the other hand, can provide a more streamlined and cohesive user experience, which may appeal to certain market segments.

Hybrid approaches: It’s worth considering that open-source and closed-source models are not mutually exclusive. Some projects adopt hybrid approaches, where they provide a core open-source offering while offering premium or enterprise versions with additional features or support. This allows them to balance community collaboration and revenue generation.

Overall: I agree that our current market environment does lack a robust structure to adequately incentivize the open-source environment we all want to see and participate in.

As we innovate into the future, I belive we need interdependent and layered DIDs and SSI platforms to provide “Identics” (Data identity analytics) to create free and fair trade open-source markets. These systems will allow us to create an even playing field of equitable opportunities for users engaged at all levels of the market process. The user, developers, and managers of an ecosystem can be holistically synchronized into one systemic market cycle controlled democratically by its users that equitably empowers everyone with opportunity through reliable open source and auditable trustless interaction.

We are all on the edge of the metaverse we have dreamed about. We must just dare to innovate! I hope this motivates others, as much as it does me to come together and help build out these types of interlocking solutions that can help sustain and elevate the ecosystem.

I appreciate the post and the effort put into it. There are many valid concerns raised in it. Thank you for sharing.


This will allow us to set up systemic structure that can provide positive incentivization through equitable opportunity so open-source mechanisms start to mimic the level of return we see from web2 exclusionary models.

My gripe is not with the level of return, but the alignment of values in the first place. Open-source software is notorious for moving at a speed that doesn’t rustle any feathers. Teams spend a lot of time on getting to consensus. It makes sense, because usually open-source teams act more equitably since goals are almost always less stringent. Even in the systems you linked, by definition, they add so much more consensus finding mechanism that every decision will at least take twice as long. Probably much much longer.

When a company is given X amount of money, and you say “figure it out and survive”, companies mimic a living organism. Depending on what X is, the company can start off extremely fat, get lucky, and continue to remain fat. But the majority of times, it starts small, gets fat, and then very quickly starts “dieting” in order to ensure survival. This means faster decisions, faster throughput and a “anything to survive” mentality which results in accidental innovation. The world is filled with examples like this, from Instagram to Slack.

This is never true with open-source software. There is no dire sense of need to survive. Sure, everyone wants to keep their jobs, but there is no one at the top who’s putting all their eggs into this one basket. You need people dedicated with that level of intensity in order to provide massive value. Maybe I’m cynical, but most long running open-source projects I see usually involves employees who keep moving the needle incrementally and sufficiently enough, but never enough to create the huge impact you see with other types of companies.

For example, it would be pretty straightforward for me to say “let’s open-source” and start applying for grants. Once grants are received, you dole out a barely comfortable salary to everyone, and if the project gains enough traction through whatever predetermined metric, the salary levels get to “comfortable and happy”. After this point it’s just sort of the same grind of decision by committee, implementation, rinse and repeat. No point changing the status quo because grant funding is dependant on that, and you definitely don’t want to piss off the wrong person. Then at some point grants will die off and if you somehow made a product that people will pay to service, you can live off that income. History has very few examples of such companies so I’m skeptical of such an outcome.

But in a standard company (venture backed or not), if growth slows, you can see your runway shrinking and the whole company is immediately mobilized to “sink or swim”. This unfortunately, a lot of times involves taking pay cuts, letting go of employees and working harder to extend runway. I have never seen open-source companies try this hard, and there’s no reason they have to. Most of the time open-source companies choose to to have 10 people for one month rather than have 2 people for five months. No one wants to make the uncomfortable decisions. The people who work on such projects wear it as a badge on their resume and start their next job in a standard company. Equity attached to IP can be an intense motivator to get people to try crazy things.

The impact of a project is not solely determined by whether it is open-source or closed-source. Factors like usability, user experience, market fit, and ecosystem development play a crucial role.

I agree, and the fact that it is open-source or closed source directly doesn’t matter to a project’s success. But my appraisal of the current state of things are that open-source systems creates enough misalignment within the organization and significantly lowers the chance of a project succeeding in the first place. It’s already hard to succeed, so why would I want to decrease the odds?

Some projects adopt hybrid approaches, where they provide a core open-source offering while offering premium or enterprise versions with additional features or support. This allows them to balance community collaboration and revenue generation.

This is an interesting point. There are lots of restrictive open-source licenses. But generally if you use any of these restrictive licenses you are constantly criticized for not being “truly” open-source and you end up using open-source just as a marketing tool. This is an odd situation to be in. Companies like ElasticSearch which have created an enormously valuable ecosystem are now being criticized because now they are trying to capture some of the value they created. Their license restrictions and their tiff with AWS has split the community and even though they are open-source there are no shortage of people criticizing them for not doing enough.

Appreciate the thoughtful response and the forward looking optimism. Until I see a company break these norms I think I will be somewhat skeptical of open-source in the majority of contexts. This article someone sent me was written 9 years ago! Talks about the same thing in less detail but since then we have yet to see the status quo change.