2 ms·
Although the particulars are unique, this seems to be another problem stemming from what I like to call "Having Your Open Source and Eating It Too Syndrome". Na
by tolmasky 7y ago
Although the particulars are unique, this seems to be another problem stemming from what I like to call "Having Your Open Source and Eating It Too Syndrome". Namely, it seems to me that the authors don't actually want an Open Source project (or perhaps more accurately a Production-Ready Open Source Project). They may certainly want many of the advantages that Open Source brings, but are upset by what I think are honestly completely predictable consequences from not living up to the, regrettably for lack of a better word, "responsibilities" of Production Open Source. I say regrettably because I don't want to get into an argument about what is actually "owed" -- I agree no one entered any contract or whatever. All I'm saying is if you put in the work to convince someone that something is production-ready, and convinced them to stake their livelihood on your project, then it shouldn't be surprising that they are upset when you prioritize abstract principles or decisions over their ability to ship. Again, I'm not implying you should be forced to have a process or do what they say, just don't be surprised when your users get upset, and then on top of that accuse them of "entitlement".
There's a lot of convenient, and perhaps subconscious, confusion of terminology in technology. For example, people can point to the fact that a project isn't 1.0 yet and argue "well you should have known anything goes pre-1.0". But Linux was amazingly solid prior to 1.0, and even the term "Beta" has been watered down by Google's infamous insistence of using the term for ages on their software. I'm not saying you have to agree with the watering down of technical meaning, but you should understand the unfortunate reality that a lot of this is mixed signaling. For example, a common one is "It's beta but we use it in production and it works great!", which if you break it down is kind of a used-car-salesman technique. It's saying "I've created plausible deniability for myself so that I owe you nothing, but the final thought I'm going to leave you with is an emotionally manipulative statement that wink wink it's really ready to go".
Similarly, if you have a fancy landing page telling people why your product is better than other production-ready products, for example Elm compares itself against Angular, React, and Ember, then you are strongly implying you are a peer. So even though the words "production-ready" don't appear on the page, there is a strong implication here. There's certainly no asterisk anywhere saying "pre-shipping numbers", something that game trailers will even do. Again, I don't think this is intentionally deceitful, I think it's supremely easy to accidentally run into this sort of messaging. But you should absolutely be mindful of this and work against this.
Luckily, this is all fairly avoidable if you're willing to take some simple steps. For example, just say "this is a toy project" or at least "We absolutely do not recommend this for production", or even "the primary purpose of this project is for researching ideas that interest me". That can completely avoid any miscommunication and sets expectations up correctly, and furthermore puts you 100% in the right in the event that someone ends up relying on your code... But no one wants to do that because it hurts adoption! This is what I mean by wanting to "Having Your Open Source and Eating It Too". You want to portray an amazing product that does everything well AND is a happy community, while reserving the right to treat it like a side project whenever you want.