Hacker News Reader

I really like this model and want it to take over the world. It would solve two problems: compensating people for building open-source software, and replacing the notion of IP for software with something more sustainable. More people should stand up and say, "I made this, I want to make the world better, and I will add this to the commons that everyone can benefit from after I extract $X of value from it."

A social norm of requiring people to "call their shot" in advance feels like a powerful counter-force to greed.

Okay, I have to ask:

How is the current "notion of IP for software" not sustainable?

And how is this model, which seems like it's just asking to fall into a tragedy of the commons, more sustainable?

And finally, how is making something and holding it back until getting paid a certain amount a "counter-force to greed"? (to be clear, I don't have a problem with this -- if someone makes something, they're free to do what they want with it -- but I don't see how it's any more or less greedy than other options)

Fundamentally, the power a author has ,that is greater than the power granted by IP, is the power to decide whether to release something or not. This is a nontransferable power.

Historically, copyright was the granting of limited time monopoly powers over the distribution and derivatives of something in exchange for the promise of the author to not make use of the power to choose to not publish. In other words, copyright was meant to encourage publishing. The reason was that publishing that was controlled and approved by the state was vastly more preferable to uncontrolled organic spreading of knowledge. It was meant to be a win-win-win for everybody. The author gained revenue, the state gained control and the public gained culture.

The same was true about patents. The state granted the inventor a limited time monopoly over the use of a solution in exchange for the inventor not keeping it a secret. This granted the the inventor a way to extract revenue directly out of an idea instead of out of a finished sealed product. It granted the state control. And it granted the public access to the inner workings of the innovation.

This however does not mean that the power to keep something secret is gone. When it is more profitable to do so, the choice will always be to do so. That is why trade secrets exist. That is why there is a black market for information. Secrets are still highly valuable.

Currently the term of copyright extends far beyond the end of the life of the author. Noone will publish anything after they are dead. Also, all IP rights are now transferrable and inheritable. Oftentimes IP transfers are imposed on employees as part of their contract with the employer. The main beneficiary of IP today are large corporations. Also, the public is no longer just a consumer but a transformer. And due to technology, the state has clearly lost control. All of this makes the system of IP, not sustainable. The incentives are no longer aligned.

This model relies on that fundamental power to keep something secret and to trade that secret. It is an attempt to realign the incentives of each party based on simpler assumptions.

Now please explain why you believe "it's just asking to fall into a tragedy of the commons".

"IP transfers are imposed on employees" - so true. pretty much all the contracts I've seen in the past 8-10 years had something like this in it and I did refuse jobs because of these clauses. These days - almost everything(related to development) I do is done by my wife, my sisters husband or a very good friend from another country :)

Is it greedy if, after investing months or years of work, answering issues, implementing feature requests, you feel like you deserve to be somehow compensated for your work, especially with successful companies using your software, benefiting from it?

The model may be far from being perfect, I'm still learning and adjusting what works and what doesn't, but it feels much better investing my time into this project since I get something back.

It sure feels greedy if your inheritors expect to retain a monopoly over all rights over your work after your death for at least 70 years.

"When free software was born, if you wanted to clone, interoperate with, improve, or modify any existing software, all you needed to do was reverse-engineer that software and go to town.
"The GPL wasn’t permission to make something new that was compatible with something that already existed. People who knew how to make software already behaved as though that was something they were permitted to do, irrespective of the feelings of the company or individual whose code they were interacting with.
"The GPL was a request for companies and software authors to make this process easier and less tedious by handing out source code, so that would-be interoperators could skip the wasteful, time-consuming reverse-engineering step and go right to the good stuff – making a new thing that improved upon (and/or competed with) whatever was already made.
"The GPL was icing on the cake. Applying the GPL to your code didn’t signal that you’d forswear legal vengeance upon those who wanted to make something compatible with your thing. You had no right to that vengeance! Applying the GPL to your code signalled that you wanted to collaborate with interoperators, rather than impotently shake your fist at them from the sidelines as they went right ahead and interoperated with your code against your wishes.
"Some 40 years later, the world is a very different place. Between software copyrights, anti-circumvention rules, software patents, enforceable terms of service, trade secrecy, non-compete agreements, and the pending (at the time of this writing) Oracle/Google dispute over API copyrights, any attempt to interoperate with an existing product service without permission from its corporate master is a legal suicide mission, an invitation to almost unlimited civil – and even criminal! – litigation. That is to say: if you dare to modify, improve, or replace an existing, dominant software-based product or service, you risk bankruptcy and a long prison sentence.

"Forty years ago, we had cake and asked for icing on top of it. Today, all we have left is the icing, and we’ve forgotten that the cake was ever there. If code isn’t licensed as “free,” you’d best leave it alone."

https://locusmag.com/2020/09/cory-doctorow-ip

> How is the current "notion of IP for software" not sustainable?

https://www.eff.org/deeplinks/2016/06/stupid-patent-month-st...

> How is the current "notion of IP for software" not sustainable?

The only reason the "notion of IP for software" is a thing is that our intuitive notions of ownership don't quite work. We can't sell software without sources because nobody wants to allow a stranger to run arbitrary code on their computers. We can't sell software with sources because it's too easy to copy. We can't give away software with sources for free because people gotta eat.

So IP is a hack that slips into a gap just because there’s nothing better. But it's not a great hack. https://250bpm.com/blog:82 makes a compelling argument that licenses exist only to help CYA companies consume software without risk. All of the software on my computer is owned by others, and yet nobody bears any liability for security holes. It's hard to discuss licenses, because "IANAL". But any time spent looking into licenses quickly uncovers stuff that's only there because nobody has tried to fight it in court yet. Licenses apply to a single snapshot of code, but software has a life cycle and needs a supply chain and governance structure (https://monetize.substack.com/p/a-holistic-vision-of-open-so...)

> how is setting up a situation that seems to be asking for a tragedy of the commons more sustainable?

I think a lot about the tragedy of the commons (https://news.ycombinator.com/item?id=4359257#4361596), but it's not clear to me how people putting things made of bits in a digital commons that anybody can use creates any sort of tragedy here. If you have a specific scenario or externality in mind, we can certainly discuss it.

> how is making something and holding it back until getting paid a certain amount a "counter-force to greed"?

It’s a counter-force because of the bounding effect. You can choose to extract as much value as you want — but you gotta say up front what you want.

Users are not passive entities here. If you choose to set the number too high, discerning consumers may choose to not feed your network effects. If you set the number to something people feel is reasonable, your adoption may speed up, because people feel like they’re contributing to something good entering the commons.

Hi, I am not sure if I fully understood your model:

You said you will release the 1.5 K, 2K, ... features once you reach a monthly recurring sponsorship revenue of that amount of Dollars.

What do you do if the sum of the monthly pledges goes down at some point? Will you make those features private again?

I guess it's a bit counter-intuitive for me that a one-time release of a feature is tied to a recurring sponsorship level.

On the other hand, that's basically the monthly-license-fee subscription model, so I guess it DOES make sense.

> What do you do if the sum of the monthly pledges goes down at some point? Will you make those features private again?

Nope, any feature that is released will remain public.

> I guess it's a bit counter-intuitive for me that a one-time release of a feature is tied to a recurring sponsorship level.

In the end, I'm selling early access to new features, that's it. If you need something now, and it's available for sponsors only, you need to subscribe to get access to it. You can always implement it yourself, the project is very hackable and puts a great emphasis on extensibility. The documentation is very thorough, also in respect to customization. However, sometimes, maybe especially for something like technical documentation, you don't want to be fighting browser bugs and edge cases.

This is pretty common on the Blender plugin side was well. IE Crowdrender.

Į think certain percentage will just keep the donations on. And of course some will cancel them after the feature is released.

There’s likely enough people continuing to support. As well: if needed there’s exercising the option to set the next feature at the next highest MRR goal.

Thanks for the explanation. For clarification, does any subset of your community have access to the private version, like perhaps people paying a subscription fee or something?

Or is that version completely hidden from everyone, and just used to develop and test new features until a funding threshold is met to release them into the public version?

Sponsors have access to the private repository (I'm using GitHub's collaborator feature). I have several sponsor tiers and $10 a month or more will get you access to my sponsorware, which means you will be added to the private repository and can use the features immediately. What you're effectively getting is early access, so you can use the features before other users.

The official documentation of my project lists exactly which features are "Insiders only", and which aren't. When the features tied to the funding goal that was hit are merged, everybody can use them. I try to always have sponsors-only features on higher tiers to keep sponsoring attractive.

As I understand, Caleb does it with content and entire projects - I'm doing it with new features for an existing project. Also, I'm doing it fully transparent, disclosing how much I earn with this, which I think is crucial to build the necessary trust relationship.

How do you avoid malicious users publishing your content public? Or is it just not an issue yet?

This is indeed a problem. However, given that you need to pay for a subscription to get access, I consider the risk rather low. The Insiders code is released under the same license (MIT), as I didn't want to make things complicated, so I couldn't even enforce someone publishing it. I have a fair-use policy [1] that (up to now) all users respect.

Yes, the model is far from being perfect, but it allows me to pay at least some of my bills. I'm always curious to learn how to improve it!

[1]: https://squidfunk.github.io/mkdocs-material/insiders/#terms

I suppose it's licensed under a non open source license until it's released to the public. If so, you can prosecute such individuals who break the license.

It's MIT-licensed, as the original project. I have no interest in legal prosecution. Also, different licensing would make it more complicated for companies.

> different licensing would make it more complicated for companies

True, although just removing a couple of words from the MIT license would still be a very attractive and easy to use license. Examples of words you might remove: "sell" and "sublicense".

No company (that cares about licences in the first place(!)) is going to touch 'MIT, but with some words removed'.

Remaining open source but banning the user who leaks the source code from the repository could work too, no? (the RedHat way).

So as a user, you can start some work based on the insider version and be confident that you will be able to release your work even if the insider version never goes public for some reason, instead of relying on a promise that the code will be released in an open source license.

How to find out who leaked? Can you make github insert a kind of fingerprint?

I found your project yesterday and was blown away by not only the quality but how easy you made it to get going. It motivated me to sponsor you for the insider features and has exceeded all expectations!

I never thought I would have so much fun creating documentation :) Cheers and keep up the great work!

Thanks! That is great to hear. Making writing documentation as frictionless and easy as possible is the primary goal of this project. Happy to welcome you aboard as a sponsor!

Thanks for providing details.

Are you the sole author? Do you accept contributions (PRs)? How are these handled?

I do 99% of the work, but of course I also accept contributions. However, PRs are very rare and are mostly about bugfixes, not new features. Bugfixes are always released as part of the non-Insiders version, of course.

What's probably interesting is to consider the user demographics, about which I learned more in a survey [1] I did last year. Only 8% of my user base would consider themselves Frontend engineers. Given that this is an HTML template with some rather complex CSS/JS, it's not surprising that there are only very few PRs that implement new features. I guess most Frontend engineers go for JavaScript-based solutions like Vuepress or Docusaurus. Material for MkDocs is Python-based.

[1]: https://twitter.com/squidfunk/status/1259832077668810752

Replied to wrong comment