I wrote to Ryan Fluery after reading some of his articles on software. He replied in an article which I am now going to reply to here.

The email

First, my email to Ryan, with some light editing:

Hi Ryan,

You may remember my name from Handmade, where I sometimes post about my Cakelisp project.

I have been catching up on your Hidden Grove blog. I agree with you on many of your points about the flaws of modern software culture and game development. I too think we need to start over with a focus on self-reliance and user experience as focus.

I wrote about similar topics in Software complexity and potential solutions. I'm convinced that we need a cultural change in order to really save expressive computing.

However, to me I see a contradiction with your approach. In Ships, Icebergs, Game Engines you say:

The Machinery’s collapse has given us a stark reminder of the presence of what seems to be a fundamental human truth—ownership is agency. If we continue to approve of a world in which ownership is regularly compromised, we will continue to see a decrease in agency, and all of the downstream effects of that—lost work due to the collapse of teams and projects, corporate or governmental exploitation, and diminished artistic expression.

Yet, in your Hidden Grove project announcement you say:

Parts of the codebase to which I refer is partly available to paid supporters through the Code Depot (as it matures, more will become available). The community mainly exists on the small Discord server, primarily in the portion for paid subscribers (though there is also a public area).

I understand that funding these projects is critical to their success. I too am working on my dream software and am struggling to finance it (currently working part-time to survive). However, I think your closed approach is not a healthy way to make a good community. You own the code and community, therefore the community lacks ownership and agency.

For contrast, Andrew Kelley founded a 501(c)(3) to ensure his Zig project could receive funding in an ethical and pro-community way.

I know the loudest advocates of software being bad and how to make it better are also consistently advocates of closed and proprietary (I'm talking about Casey Muratori and Jonathan Blow here). It's a point I disagree with them on.

I much prefer John Carmack's approach at id Software, where he believed releasing the software (under GPL, no less!) and sharing his technical findings (before the game was even released!) to be the right thing for the community. I don't think there is any evidence his approach netted him any less profit or success.

I don't think it's a "good software or free software" dichotomy. If you're starting from scratch, why not make it "good software AND free software" instead? I'm using the term "free" as in freedom; I'm happy to pay for software and have donated to several projects, so long as I can truly own the software I pay for.

For the first time in history we have a resource which can be free to distribute and modify, which I believe means it should be free to distribute and modify. Similarly, we can have decentralized communities and communications, so we should decentralize them. (Why: because it benefits the most people to avoid centralization of ownership, due to censorship, profit motivations conflicting with community ideals, etc.).

And to clarify, I do not expect you to develop your software in the "bazaar" style, taking contributions from anyone. I have a natural preference for "cathedral" style myself simply because I prefer figuring things out on my own to managing community. I only ask that your ideas and the ideas of the community you are trying to create won't be hampered by paywalls and/or proprietary practices. You can't defeat walled gardens by creating another walled garden.

I'm imagining in my head a culture of self-hosted blogs, with authors connecting through decentralized protocols like email (though not necessarily email, which is horribly complex), sharing code and letting people create their own spin on things–the polar opposite of a closed Discord and paywalled code base.

I read this (from Regulation Cannot Save A Defeated Culture):

The software world I hope to help build is different than that which exists today, and that which Big Tech corporations have no problem driving us toward. This would be a world with widespread competition, simple and re-writable building blocks at the core of the ecosystem, simple and open protocols for networked communication, simple and open file formats for the most important information, a high value for user experience and design, and the impossibility of extinguishing computing freedom.

But what I feel is implied from your community organization is:

This would be a world with widespread competition, with my simple and re-writable building blocks at the core of the ecosystem, my simple and open protocols for networked communication, my simple and open file formats for the most important information[…]

I hope you consider this conflict. I don't expect you to defend your position, as I too receive unsolicited messages offering opinions on my projects. I want to agree with you more, and I want to consider you a driving force for good in the computing world.

Please forgive me if you have already addressed these in other posts as I am still working through your backlog of articles.

I have seen your posts on Handmade about Dion and am excited to see what you have coming!

Thanks,

Macoy Madson

Ryan's response

Ryan responded in Software Kingdoms (archive.org).

My response to his response

I was glad he took the time to explain his reasoning. I think we may have miscommunicated, though I take responsibility for the miscommunication. I wasn't necessarily advocating for his software to be "free as in beer". I do believe we should try to sell our software.

My interpretation of his reasoning, though slightly different, is this: it is better for more people and results in better software if the developer is better funded. Therefore, the best thing to do is to extract as much capital as possible to support the developer, even if that means the software product cannot be given away for free. Doing otherwise, he argues, is irresponsible, because the customers end up with a worse product.

Now, clearly Ryan has a poor opinion of free and open source software, which is unfortunate. There are a good deal of brilliant programs out there which improve daily. But, there's really no point arguing this except to say that generally the better programs have had more time put into them. Time is money, because we all need to eat, so it costs more to make better things.

His post did help me clarify to myself my stance on selling software. I think it's okay to keep source code unavailable until the customer purchases the product. However, once the customer has given the developer their money, the customer should truly own the use and their potential improvements on that version of the software.

This comes back to the four essential freedoms of free software:

• The freedom to run the program as you wish, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help others (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

If I buy a software product without the source code, it feels much more like a transient throw-away thing that I cannot invest much time into. If I produce creative works with it, I know those works may have their lifetime or spread limited by the lifetime of the software product. If I retain the source code, I can theoretically port the software to new platforms to extend the work's lifetime. It is possible to do this without the source, as the video game emulation community has shown us, but it is much preferable to start with the recipe rather than reverse-engineer everything.

An ethical way to me to both profit and still distribute code is to keep the source closed until purchase, then include the source with the product, potentially pinned to a specific version. The customer can do what they want with the source according to the four freedoms, but may not e.g. get the next version of the software without paying.

This has some interesting implications for software development communities. There can emerge the original "closed until purchase" producer of the software and potential "open after purchase at version" producers who are customers buying the software and giving the source to others for free. One could view the "open" producers as parasites cutting into the "closed" original producer's profits. This is a potential issue, but it can be mitigated. For example, the "closed until purchase" producer could provide better technical support due to their increased funding. They could also release features earlier to their more trusted customers as a sort of "early access".

Additionally, some people do actually have morals they follow, so the closed producer could appeal to those morals by saying "I'm doing the work, therefore don't I deserve to profit from it?" This is an appeal to charity or altruism, but it seems to work for some developers. For Sublime, you can practically use Sublime Text indefinitely without paying by dismissing the "please buy" popup, but myself and at least one other programmer I know appreciated the software's quality enough to purchase a license. There are enough people doing this that their company continues to improve Sublime and release other products. Another way of putting this is "make something so good that people want to give you their money". Shouldn't we encourage this kind of market dynamic over forcing them to pay?

The "fork" is a lever of power the community can threaten the developer with in order to make the developer change how the project is made or run. The idea is that the community takes the software at some version and develops it separately from the original developer based on their difference of opinion. This is an important ability for the community because, as Ryan pointed out in Ships, Icebergs, Game Engines with the Our Machinery example, the original developer can dissolve or take the project in a direction which is bad for the community.

Customers of software need to retain the right to declare independence from the original developer. They don't need the right to claim the original work as their own, but they do need a way to escape potential tyranny. Otherwise, no one but the developer truly owns the software.

The major benefit of forks is again one of competition. If there are three different versions with different approaches, the market is allowed to select the best approach over time. In reality it might instead select for the best-funded or most popular team's fork, but at least the selection wasn't artificially regulated by the software being completely closed and proprietary.

On community

I stand by my opinion that the community should be open and free to join and study. I don't think it is out of the question to charge members of such a community for technical support, especially if the support will likely only benefit that user. Paying just to listen is mainly the problem I have here, especially when members of the community aren't getting a portion of the payment for their contributions. The free exchange of ideas is simply too valuable to paywall.

For me personally, I don't feel comfortable putting intellectual effort into a communication only to have it live on a server someone else owns and charges for access to. If I want to disseminate ideas, I want to own the distribution as well. If I don't, it feels like I'm working for free for that person, and that they are the true owner and benefactor of the intellectual effort.

Conclusion

I appreciate Ryan's willingness to clarify and share his stance on software production and economics. I hope to discover a way we can both respect freedoms while still funding developers to produce the best software.