Comment by tsukurimashou
5 years ago
"Ok... So that was unprofessional. If you don't want to maintain a project anymore, you give it to someone else and link to that repo in your README.
This just screwed me over big time."
https://github.com/actix/actix-web/issues/1#issuecomment-575...
These kind of entitled attitude is probably exactly why the guy just removed everything.
More details / discussion here: https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou...
It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
It's not very hard to say, this is a project for my own technical interest, I don't intend to follow Rust norms about use of unsafe, and you shouldn't rely on it, but here's the code if anyone wants to look. That's fine! (And I do think we need to be better about making it common to do that. GitHub has no good tooling for such a repo, for instance: you can't disable pull requests unless you archive the project or make it private.)
But that's not what Actix's docs say. See https://actix.rs/docs/ for instance: there's nothing to the effect that you shouldn't use or rely on it, and everything to the effect that you should. (In case that page gets taken down, it starts, "Actix is your door to developing web services with Rust and this documentation is going to guide you.") On https://actix.rs/community/ it says you should report bugs to GitHub, implying that bug reports are in fact welcome, and there isn't a single statement that the project goals prioritize the author's technical excitement over correct code.
Again, there's nothing wrong with wanting to prefer your technical excitement over having bug-free code. Just be clear about it.
> if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
This reminds me of an incident years ago. I was on a city bus, very full of people, and we were just about to leave a stop. There's a woman maybe 150 feet away running towards the bus. The driver sees her running and re-opens the door, waiting. Inconvenience to all of us on the bus, but hey, she's running.
The woman, seeing the bus has waited for her, stops running and starts slowly walking instead.
Driver sighs, closes the door, drives away.
I'm not sure what the moral lesson I take from it is, but mainly "if I go out of my way to help you, don't take advantage of my generosity". Maybe that partially applies to situations like this one. Or maybe just "don't annoy transit operators". That's a good one too.
I think that's fair - especially the part about not taking advantage of generosity. But I don't think that's what happened here. Someone reported a soundness bug. Someone else (IIRC) posted a patch fixing it by switching from a custom Cell type to the standard library one, which is what the maintainer called uncreative and boring. Fixing a soundness bug is a perfectly reasonable, non-advantage-taking thing to do in a PR.
(I agree that in general there is a problem with open-source users feeling entitled to support/features and maintainers not feeling comfortable saying no, but that doesn't seem to be the type of incident that triggered this, and more generally it is difficult for me to see how a patch would count as that - at least a patch that isn't "please maintain this pile of new code," which this one wasn't.)
1 reply →
In this case, the maintainer made an active and conscious decision to do something that did nothing but hurt everyone using the project. There are no passengers who might benefit here, sadly.
18 replies →
Yeah, people who aren't in perfect running form don't deserve help.
Well put!
He held the door open for a lot of people. Some people spit at him as they walked through. He doesn't want to hold the door open any more, he's done it enough. He didn't sign up to be a doorman for life.
This idea that replacing unsafe code with safe code is "spitting" is unhealthy in the extreme.
I don't understand why the author felt so defensive about accepting packages. As far as I can tell, they've always had this attitude.
Why even make a project open source if you don't want to consider patches? The whole idea is that even if you think a thing is boring, someone else may not and they'll do that work for the community.
Weirdly, this is now some kind of grave affront to the maintainer who appears to take the idea that a compiler check could be added to their general framework as an insult.
8 replies →
Just walk away then, no need to set the door on fire.
5 replies →
Right, and he can do that and that would be totally fine. People stop maintaining projects all the time. But by going out of his way to antagonize people (many of whom aren’t even the people who “spit” at him) he’s just not being very nice.
> It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
Exactly.
Like it or not, there are implicit social contracts if you maintain OSS software.
Yes I've read the birdseed of the various licenses.
I know this will whip up the oft-suffering maintainers and developers in here. But this is the exact kind of trope that stymies wider FOSS adoption.
The artifacts of these little meltdowns are exactly the kinds of things your upper management will cite the next time you suggest using FOSS vs. whatever vendor they're about to push down your throat.
Ignoring security conventions, and then adopting a "take my ball and go home attitude" isn't a ringing endorsement for adopting FOSS, unless it's run by a large entity.
I'm not saying the author should have to endure abuse or harassment, but consistently pushing unsafe code into a web-framework, being cavalier about trivial and widely accepted coding conventions, and dismissing patches as "boring" is exactly how you end up with NPM Ecosystem v2
> Th e artifacts of these little meltdowns are exactly the kinds of things your upper management will cite the next time you suggest using FOSS vs. whatever vendor they're about to push down your throat.
Yes, this is what I don't understand - we spent decades fighting the perception that open source could never be as good as proprietary commercial software. Now that we've mostly convinced our bosses, we want to turn around and say, no actually an open source maintainer who writes buggy code, rejects patches, and takes down their project when called on it is doing exactly what he should do?
Of course he has every right to do that, but this shouldn't be (and fortunately isn't) the norm. Defending this outcome as the expected outcome just means that the bosses will quite justifiably say, suppose we use this software and I let you publish patches back, you're telling me to expect that the upstream author will take their code offline? Why should I use this software at all, let alone let you waste your time on patches? I'm gonna buy from Oracle.
4 replies →
> Like it or not, there are implicit social contracts if you maintain OSS software.
I think I agree, and its tricky because its really hard to pinpoint what the contract is (without sounding "entitled"), like there is with any social contract I guess. Maybe it even depends on the various cultures of the people working on the project.
5 replies →
> Ignoring security conventions, and then adopting a "take my ball and go home attitude"
That statement is quite wrong. It's not a "take my ball and go home" attitude. You are not the boss of a FLOSS maintainer not are entitled to order anyone around to do your bidding. At best you're addressing a person and asking them to do you a favour. If the maintainer doesn't feel he should be bossed around by you then he has been generous enough to let you pick up where he left off and actually put in the legwork you are expecting others to do.
And in return these haters prefer to just bitch around and criticise others for not following their orders.
1 reply →
If some one opens the door for you that was nice of them, they did your work for you, they have no ongoing obligation to maintain the door in an open state.
If some one give you their code that was nice of them, they wrote your code for you, they have no ongoing obligation to maintain your code.
by simply giving you their code they have already provided you with value, a head start for nothing in return, they have opened the door for you, the rest is up to you.
We’re starting to stretch the metaphor too far, but by opening the door you’ve signaled to me that I can walk through it safely. Closing it abruptly can in some cases be even worse than the alternative, since I could have possibly opened the door myself (written it myself and not invested time in this particular project) or gone through a another door that was also being held open (used another open source project).
8 replies →
Well put. I’d add on to your metaphor: slamming the door on someone is quite different than just not holding it open anymore. The second is totally acceptable; the first is impolite.
This case is clearly akin to not holding the door open anymore.
The code’s all there and still available, right? Anyone who wants to can reach out and “hold the door open” for themselves, can’t they?
If someone is relying on your code, that means they have their own copy of it.
You're not obligated to keep your copy online.
As an open-source developer myself, I'm annoyed when people do that. I want them to rely on my product, not my code. I want them to update when I publish new versions and I want them to send patches back.
There are even almost-open-source licenses that compel you to send patches back. I don't want to use one. I want to treat them with respect and I hope they treat me with respect in turn.
1 reply →
They're right, it was unprofessional... but since the maintainer is not being paid this is not a professional project. It's a personal project. And this seems like a perfectly personal thing to do with something that's preventing happiness.
I absolutely agree with this. The author has spent an insane amount of time to build all this stuff and instead of getting recognition and/or being payed adequately he is getting shitstorm after shitstrom.
As an outsider I have to say that I think what the Rust community has technically achieved is remarkable. But on the social side it is not so bright, avid Rust users constantly spam forums of other programming languages with toxic comments. But this incident shows that the situation is even worse than expected, the Rust community even treats its own peers like sh..
Well, no different than any other tech where the community is an echo chamber full of fanboys. Linux used to be like that, especially some of its distros (uhm Gentoo?), cryptocurrency fans are like that, Apple users probably don't need mentioning neither ...
3 replies →
Well, it's easy to get confused when you look at the professional looking website with a well crafted logo, a promo list of features and a copyright notice from the "The Actix Team". The community page even says "We're a welcoming community so don't be afraid to engage.". Ouch!
Huh nothing you said indicates it is a professional project. Sleek does not equal professional.
The easy way to tell is to remember if you're paying them or not.
14 replies →
> It's a personal project.
If you create an organization on GitHub for a project that is meant to remain personal, this kinda sends a wrong signal.
Blaming some users for being rude and entitled, and then deleting an open source repo out of spite... it's a bit hard to feel sympathy for the guy here.
For information, the repo has not been deleted but simply moved: https://github.com/fafhrd91/actix-web
> If you create an organization on GitHub for a project that is meant to remain personal,
Sounds like there were intentions or plans to transform a one man project into something bigger. Some steps were made. Hence, a nice looking website, a github org, benchmarks etc. All those signals are intentions, the vision of the future self. They may or may not come true.
Nothing signaled an established business model or sustainable backing of any kind.
Exactly. It can be argued it's unprofessional to become dependent on third-party software without any background recherche regarding the maintainer's motivation, team size, financial standing, etc., especially when said third-party software isn't a replaceable, standards-based component such as, say, Java Servlet containers and other web components used to be.
Professional pursuits are things related to a vocation, not directly tied to an exchange of money for every interaction under consideration. If you're in the industry of software development, and tie your identity to an open source project, it is de facto professional.
In this example it is held as a significant accomplishment on this individual's linkedin page. Which isn't surprising as professional credibility is a primary motivation driving a lot of open source involvement. We are seeking a different, less direct form of compensation.
So it's fair to say that acting like this is unprofessional.
That doesn't mean it isn't merited, or that they might have been frustrated or had good reason. But professionally they would have been much better served by other means: Simply announcing that they're retiring from the project and encouraging forking and the percolation of a new canonical version, etc.
> And this seems like a perfectly personal thing to do with something that's preventing happiness.
Sure, if you want to spread the misery. That's still kind of a dick move, even if he's perfectly within his rights.
> These kind of entitled attitude
If you offer code to the public – and present it as an active, dependable project – professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.
It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.
> If you offer code to the public – and present it as an active, dependable project – professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.
As far as I can tell, this project was released under the Apache License 2.0.
https://github.com/actix/examples/blob/master/LICENSE
Clause 7 of said license says the following:
"7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License."
Other popular free software licenses (namely the GLP) have very similar clauses.
> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.
Expecting labour from someone without paying them is the very definition of entitlement.
Lets compare it to an other type of volunteer based work, after school activity for kids. Some of those are going to be free, run by people who volunteer (usually other parents), with disclaimer policy that say that any responsibility is on the parent and no liability may be put on any of the volunteers.
Is there a social contract that put some expectations on the volunteers who are organizing the activity/event, and is that the definition of entitlement?
I would say there is such social contract, and when people expect too much of it there is also entitlement going on. Where the exact line goes is gray zone.
> Other popular free software licenses (namely the GLP) have very similar clauses.
What the license says and what image the project presents can be very different. Pointing to the license and reasoning that nobody has legally promised anything contractually is not very useful.
> Expecting labour from someone without paying them is the very definition of entitlement.
That’s a very mercenary view of the world. What about volunteer charity workers? Is it OK for them to just not show up whenever, just because they aren’t paid?
6 replies →
Or to put it another way:
As an open source maintainer, you're perfectly entitled to just walk away. Hit that archive button on github so nothing new can come from the repo, and enjoy your life. Nobody could fault on you that. People would prefer you work out a clean transition to a new maintainer, but you have no obligation to do so.
Deleting the repos is the equivalent of setting the house on fire on the way out (especially when they're under their own org). Unlike in reality, it turns out it's totally permitted, but people will still view it as a dick move.
The repo has not been deleted! https://github.com/fafhrd91/actix-web
2 replies →
I don't see why.
Anyone that cared already has their local repository copy.
After all that is what DVCS are all about
9 replies →
If you want to rely on some code that it takes even a second of your day to think about your response to author deleting that public code, then you fork it and simply track author's repo.
> professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
It's in big capital letters there. Explicitly no implied promises.
> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented
That is almost literally the definition of entitlement
Yeah, that's really the core of the problem, isn't it. People trying to impose an implicit understanding (which is nothing more that 'this is what I want the world to be like') when there's an explicit statement of 'this is how it actually is'.
The attitude baffles me. So many times I've had someone come in all butthurt and say 'I know it was in the contract, but I didn't think they'd actually enforce it'.
2 replies →
To assume certain conditions that are not explicitly laid out without even talking to the person providing you the service is literally entitlement. It seems like you've made assumptions that turned out wrong. I've fallen for it too in the past. Not everyone thinks the same thing so people's assumptions are always different. The key thing is, when your assumptions don't turn out true, to learn from it.
In the case of open source, it's worth asking the maintainer what the terms are if you're unsure. The LICENSE always says that authors and contributors are not liable for any outcome, either as an ALL CAPS paragraph or a clearly defined section.
Everything is provided as-is so you can't expect anything. It's on you to pick up after them if you still need the project.
Exactly. The open source community is far from homogenous, and people who engage in it (maintainers, packagers, <s>leechers</s> users, etc.) tend to have wildly different expectations that vary from person to person. I’m sure RMS, some Contributor Covenant wielder and I won’t ever agree on a set of assumptions.
Moreover, companies present themselves as “active, dependable project”s then go belly up all the time. Not sure why hobby projects should be held to a higher standard.
No you don’t. You aren’t alone in assuming that, but it’s an entirely unreasonable expectation. And as evidenced by this exact thread, people like you cause good developers to stop maintaining their projects. Your attitude harms our community.
Practically speaking, if I give you some work I did for free yesterday, and give you some work I do for free today, that does not entitle you to free work from me tomorrow. It does not entitle you to free support on the code I’ve published already. I owe you my time when you’re paying for it. Until then, if I have made something you found valuable you are in my debt for its use. Not the other way around.
As a user of my software I generally give you two rights - you have the right to use the code in your project, and the right to fork the project. And as the maintainer, I have the right to spend my time however I want for the rest of my short life on earth. If the beach looks like more fun than putting up with entitled complaints on github and HN, that is my right.
Cool, you don’t have to work in the project if you don’t want to. But going and nuking it off the face of the earth so nobody can have it is still impolite.
4 replies →
Strongly disagree. For me, what's implicit is that any software, commercial or F/OSS, can be abandoned at any time - because that's just the way it is. A remedy would be to use software coded to a specification with mulitple implementations such that in case a project folds, you might be able to switch over to a different implementation. The Java EE ecosystem used to be like that until around 2012 or so.
> what's implicit is that any software, commercial or F/OSS, can be abandoned at any time
This is particularly true when you look at what licenses say:
... THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
... THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
... IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The onus is always on yourself to insure against everything.
1 reply →
Abandon is different from deleting everything.
Ofc, git is distributed, so someone should have a copy of the repo, even if it's not updated.
Edit: disregard post, apparently it's just moved to the personal account.
5 replies →
I've never heard of "implicit promises". For me a promise is by definition explicit. Anything else are assumptions, in this case false assumptions.
In many contexts, there’s often an implicit promise to be courteous to others, even if it’s not defined explicitly.
2 replies →
“Implicit promises” is going into my Orwellian dictionary. What a farce, do people really believe such a thing?
1 reply →
Yeah, no.
If you put your code out there open, it's still your code. If people start to rely on it, they need to be ready to maintain their branch.
I do not think these expectations are reasonable. This line of thinking is definitely the core issue of the problem.
>If you offer code to the public – and present it as an active, dependable project
Not familiar with the project or Rust Ecosystem. Anyone else can comment whether it was presented / marketed / sold as an "active, dependable project" ?
As someone more used to the Ruby Rails ecosystem, I think the communities as a whole generally accept the convention that all open sources, whether they are backed by a single person or cooperate account, are given out as it is ( MIT ) and their maintainer or author will do the support or development as they could when they are FREE. And it is perfectly acceptable of forking it to make your own variation or improvement.
> you implicitly promise and signed up for
Think about this. Do you really think it makes any sense to try to hold people to promises inferred by alternate parties that aren’t even providing any consideration in return?
Just think about that.
A large amount of human interactions work this way. It's fuzzy and messy, with many shades of gray, but the world is filled with implicit promises with varying degrees of commitment and severity.
1 reply →
> professional behavior is exactly what you implicitly promise and signed up for.
Wise up. Professionals get paid, if you aren't paying some one they are not a professional. This is the reason why opensource projects provide professional support for pay, for professionals who need professional support.
I think that's made pretty clear in pretty much every open source license: "Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND".
That’s a legal, not a social statement. Following the letter of the document that governs your work doesn’t mean you still can’t do something that would be inconsiderate.
3 replies →
> you should immediately make that clear, front-and-center, to any current and future users.
like, for example, in a license file?
Is it entitled? Most would agree, "very" (but that's not my concern nor judgement to make)
Did the maintainer screw over people that were using Actix? Very likely.
I sympathize with both sides here. I've been the unthanked, punching bag contributor on a few notable projects, and I've been a user of software whose leadership got into drama and squabbles, that ultimately fucked me over.
There were times that I pulled certain projects and essays, that had greatly helped people, and taken my ball home because I was fed up with the people I was catering to. There is no correct answer here, dealing with people and their emotions, but there is a way for both sides to handle things without contributing negatively to other's lives.
> Did the maintainer screw over people that were using Actix? Very likely.
How so? Just find a fork with a decent maintainer, or push your copy to your own repo. Let the Actix guy do his thing and move on with life.
Now due to that comment actix maintainer has disabled issue too. I don't know why people show such attitude as if they are paying him to do opensource.
In open source you give and take. The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work. This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share.
It is your choice to use open source software without open sourcing your own work or without contributing.
But by engaging in open source you engage in a social contract, you become part of a community whose goal it is to foster collaboration and help one another, other people start to rely on you, just as you rely on their libraries, compilers, and kernels.
The author choose to break that social contract out of spite. He created a scenario where people choose to rely on him, when they could have relied on other works, and then screwed them over majorly.
> The actix author almost certainly (unless they deploy their own kernel)
... or use Windows / MacOS / Solaris / any other commercial OS he paid for...
> by engaging in open source you engage in a social contract
You heck. You simply allow other people to use your work as they see fit. That's it. The only contract is the license, and the license is very explicit in denying the existence of any other tie, explicit or implicit.
11 replies →
"The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work."
Prove it.
"But by engaging in open source you engage in a social contract" https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
1 reply →
Once it's public and people depend on it you can't retract it like that. His goal was to make his work public, not private.
You basically can. The cost of free stuff like this is "be nice to the guy giving it to you" or at least don't be actively abusive about it. If the community won't pay that price, expect it to evaporate.
> The cost of free stuff is "be nice to the guy giving it to you".
Can I get this on a poster please? Really well put.
This goes both way though. Be nice when people submit patches especially when you reject them.
The abusive comment seems to have been a knee-jerk response from someone dissatisfied by the "it's boring" comment about a proof-of-concept patch.
You can retract it. He just did it. You can take down any webpage under your control. I could delete this comment later if I like. You could delete yours. etc.
> I could delete this comment later if I like.
Now you can’t.
The point of open source is that people can maintain their own forks etc. There's plenty of mirrors of actix I'm sure.
Why?
It’s no longer “his” code.
In open source you give and take. The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work. This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share. It is your choice to use open source software without open sourcing your own work or without contributing. But by engaging in open source you engage in a social contract, you become part of a community whose goal it is to foster collaboration and help one another, other people start to rely on you, just as you rely on their libraries, compilers, and kernels. The author choose to break that social contract out of spite. He created a scenario where people choose to rely on him, when they could have relied on other works, and then screwed them over majorly.
Dude, sorry to break this to you! But basically any widely used software is supported by major companies just to avoid this problem.
Libraries, compilers and kernels alike.
If you want to rely on software being there, you should be ready to pay for people to support it.
> This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share.
It is clear to me that is not true anymore. It is really hard to find open source project without clear direct financial incentives.
Again, as a community, we should start to pay for the components we use.
Companies should contribute their fair share by supporting open sources projects monetarily, definitely!
But that is a different issue, from the behavioral standards we as a community uphold implicitly, and which are broken by pulling a "left-pad" incident.
2 replies →
> has profited immensely from other peoples work
Have they? how much $$$ profit did they make?
You aren't paying for shit and yet you think they are making a profit and you are entitled to professional support? Wise up.
Making a profit != profiting.
I profit from Clojure, Python and the linux kernel. Doesn't mean I habe an income from their existence.
Nobody is arguing about professional support, but advertising a project and then deleting the entire thing to spite people is a jerk move.
Ready up!
2 replies →