Stop using Moq as a guinea pig to get feedback on and develop SponsorLink #1396
Comments
|
The changelog of 4.20.69 What's Changed
This version looks good to me. |
I'm not a fan of such absolute statements. I prefer to believe that trust can be earned back, but that requires more than just work on @kzu's part; everyone else also needs to show some willingness to forgive. Or at the very least stop the venom. What's the point in holding a grudge forever. Sure, if you just want to see Moq burn to the ground because it makes you feel morally justified, and if you don't mind the extra work of looking for a replacement, keep the rage going... but is that a smart choice? I for one would much rather see things repaired as soon and as much as reasonably possible, so that we can all go on using (and working on) a great library and leave this mess behind us.
I've considered a fork. I'd certainly be in a good position to do that. But as long as there remains hope that the situation can be fixed, I don't think it would be in the best interest of everyone involved. I'd rather see this project succeed once again, than fragmenting its user base any further. (Also, "find some maintainers" is far easier said than done. Feel free to fork the project yourself and try. I personally am under no illusion that if I were to fork it, I would remain the sole active maintainer. Look at this repo's history if you want some evidence for that claim.) |
Well the package itself took a hit that should still be salvageable (sure, that AWS started a PR to remove themselves from the sponsors list really wasn't a good look) but I feel that I don't trust anything that @kzu touches anymore. As long as he has the ability to push new releases without review I'm not adding Moq (or any of his other libraries) to any of my projects and I think that that is how many people feel. My ideal solution would be that @kzu stepped down (or was removed) from the project completely and any trace of SponsorLink was removed. But seeing that he has contributed almost as much as @stakx I don't really see that happening. It is weird however that the sponsor banners/buttons in this repo is to sponsor @kzu personally and not the actual project. But I also understand @stakx point of view, forking and finding new maintainers isn't ideal either. Not only is it the hassle of finding those maintainers, but forking would also be a sort of "starting over" with a new name even if it was "Moq"-adjacent. All the articles already written all over the internet would still reference "Moq", the "Moq" package would still be the twelfth most downloaded NuGet package for a long time etc. |
|
From the code review and collaboration perspective, could we avoid PR merged without approvals especially likes the sponsorlink PR https://github.com/moq/moq/pull/1363 |
|
@karl-sjogren: I don't want to stray too far from this issue's original request, but I'll address one of your points because I think it's important in order to understand where Moq is headed:
Comparing our contributions solely by the number of lines of code changed doesn't do justice to @kzu's very crucial contribution: he created Moq. I (and others) merely iterated and expanded on it. Both of those activities are important, but for different time frames: I am quite good at iterating on existing software and keeping the lights on in the short and mid-term. But for the long term, you should want @kzu to stay involved, because he has the vision and the ability to come up with the next-generation version of Moq. The need for Moq vNext isn't hypothetical, btw.: The foundation upon which present-day Moq is built (LINQ expression trees, paired with dynamic code generation using System.Reflection.Emit) has already reached its limits. LINQ expression trees haven't been kept in feature parity with C# language features since C# version 4 (example: assignment operators, default parameter values, or anything (Please note that I've intentionally focused on our individual abilities and ignored the aspect of trustworthiness above because, like I said earlier, I believe that trust can be earned back.)
I see where you're coming from. But this probably deserves a discussion of its own, and I would suggest that we keep it out of this issue in order to stay on topic. |
|
Fair enough, but as long as there is a risk of this project being the guinea pig of @kzu again it will be really hard to regain the trust of the community. |
In addition to this, approval from other people than the pusher without overrides |
|
Setting up a peer review / approval system as a safeguard against merging bad stuff is a reasonable suggestion to make, but that requires at least two active maintainers, long-term... ideally even more than that. Otherwise development can easily get blocked and crawl to a halt, which isn't helpful, either. So you're back at the question of how the project can secure itself more support and resources. I suggest to have that discussion in a separate issue so it's easier to track it and remain on topic. |
|
Yeah sorry I have to agree with the others here. Once a developer has silently pushed a change like this without feedback or acknowledgement from the community. The bridge is burnt. It takes years to build trust and moments to break it down. I suggest trusted members fork moq to save what remains. The work thats there is good and it deserves to be saved. |
|
I think probably the best way to achieve what you're looking for here stakx is to have kzu turn over ownership to you and maybe a couple other people interested in being a kind of governing council or something. He severely damaged the ability for people to trust software that he distributes. The solution then is to have him not distribute the software. Instead, he would be the primary author/contributor, and someone else(s) would be in charge of packaging and distribution. I'm sure CTO's across the world have said that nobody is to use software distributed by kzu going forward, and I really struggle to think of any other approach that salvages Moq's reputation and sets kzu up to work on the damn thing. |
|
I'm sorry to stray off topic here, but the issue of trust is such a crucial point that it not only deserves reiterating, but it's not an exaggeration to say that we have to come to a resolution before talking about the future of Moq:
I also prefer to believe trust can be earned back, but only if you are willing to work for it. What people ultimately wanted to hear is something along the line of: "I'm very sorry about all the issues that were caused -- I screwed up. Here's what I'm doing to undo the damage, and here's what I will do to ensure something like this won't happen again". Only then, we can actually talk about a sustainable future of Moq with kzu involved. Over the past few days, we haven't seen a single line of apology, only a disingenuous attempt to "clarify" his actions. |
I truly don't think it was disingenuous. I think it must be ascribable to ignorance rather than malice. It did show, however, that he is far removed from the practices of shipping commercial software and working in an enterprise. That he 1) thought it would be incumbent on individual developers to make the nag ware go away and 2) still does not actually see what he's done wrong, indicates that trust will be slow-to-impossible to regain if the project governance structure and especially the Moq Github/Nuget distribution channels stay fully under his ownership. I still think despite everything, people would more or less be happy to let him develop Moq, but almost nobody wants to see him as the source for distribution. |
There is a difference between holding a grudge and trusting a package and trusting an author. Especially in enterprise environments, but also for people personally. At least on an enterprise level, that trust has been violated and that taint will stay on both the package and the author for a good while. That's not holding a grudge, that's simply risk management. You look at what they did, you look at their reaction and replies, and then you do a risk matrix based on how likely another such incident would be, and the impact of it. And with that in mind, I indeed think that for moq a fork and/or other contributors would remove some of that taint best. |
Based on the above clarification and the problematic compensation issue regarding FOSS wouldn't Moq vNext be an ideal jump off point for duplicating Duende's transformation of IdentityServer to OSS with a commercial license? Sure, there is a lot of legal and administrative work to get it set up and to maintain it but if done right a commercial license for Moq vNext should facilitate what @kzu is trying to acheive with SponsorLink. All traces of SponsorLink should be removed from the current version of Moq and there would be no need for it in vNext. In this transformation I do believe it would be in Moq VNext's best interest to not have @kzu as the owner of that project. His contributions should be acknowledge and he should definitely continue as a developer but someone else should be responsible. It is a matter of trust. While I do think the introduction of SponsorLink was a result of naivity rather than malice it did erode that trust. For a commercial license to be accepted the organization/individual(s) maintaining it must be believed to be able to understand and support the requirements and obligations for large enterprises. |
|
Just out of curiosity, what do you think about the core idea behind SponsorLink itself? I can't help but feeling that if it was driven from the start as a community effort with full transparency, the idea of linking sponsors to libraries is actually pretty great. As far as I can tell from companies I worked on, the main issue companies have with sponsoring OSS is not lack of willingness or funds but the overall headache to fund dozens of small projects from administrative point of view. If there was a credible system where the company could push some funds towards a redistribution system, got an invoice that can be put into accounting, and the redistribution system would know how many and which packages that particular company actually uses and redistribute the funds accordingly, many companies would actually consider it. |
I too think the core idea behind it has some merit, and that the initial implementation was terribly flawed in several ways. My whole point here is that Moq isn't the best place to discuss SponsorLink, because people are already so biased against it that they likely won't be calm enough to distinguish between SponsorLink the idea, and SponsorLink the terrible first implementation. The majority of people are going to focus on the latter and reject it outright. As a collaborator of the Moq project, I am first and foremost interested in repairing the damage that was done to Moq. Right now, I am not really interested in SponsorLink and that's why I'm hesitating to discuss it in depth. I think it deserves a calm place where it can be discussed and developed, I just don't think that this repository is the proper place for that, due to what happened last week. |
Possibly.
I really can't speak for @kzu, but if I were in his shoes, I'd probably feel quite affronted by such a setup: I'd be graciously allowed (...) to develop Moq vNext for everyone, but prevented from taking ownership of my own creation?! Doesn't strike me as particularly fair. I understand where you're coming from and why you're making that suggestion (the issue of trust), I'm just not sure whether anyone (and @kzu, specifically) would be capable and willing to split intellectual and nominal ownership that way without feeling hurt, or even taken advantage of. |
|
Besides, while many people have asked for a fork or even a new project owner, noone has yet stepped forward. Frankly, seeing the sickening amount of entitlement and cancel culture present in the ongoing discussions, it's not at all an enticing job prospect... if one isn't allowed to make any mistakes or missteps, ever, without getting cancelled right away, one would just set themselves up to be next in line. That's why I believe it would be best for everyone involved to show some more willingness to forgive. That being said, I do agree that @kzu needs to be the one to make the first steps towards mending things. And I'm aware that this isn't an easy process and restoring trust may take a long time... but we need to start somewhere. |
Which is completely understandable but the truth of the matter is that @kzu put himself in an impossible situation when injecting SponsorLink into Moq the way it was done. Either way he is going to have to eat humble pie in some form or other to attempt to resolve the situation. If vNext becomes a commercial OSS it is important that it's users/customers have trust in the organization behind it. And I believe @kzu must be an integral part of it given that it is his brainchild and his current involvment with vNext, but I do believe some form of oversight is necessary to appease enterprise organisations. I worked as a consultant for 20+ years at major retailers, in insurance and financial companies with strict oversight, and at government agencies. For all of these the introduction of SL made Moq 4.2.x anathema to them according to their internal policies regarding third-party software. I am certain they don't want to replace Moq for cost and time reasons but if a major effort isn't made to rectify the situation they will be forced to. |
Naturally. But when the dust settles, the idea itself should probably not get forgotten.
There are mistakes and mistakes. How can, in his right mind, an OSS developer think that force-pushing a closed-source obfuscated library that gathers and transmits PIIs to the cloud out-of-process without consent was gonna fly?
Probably not. Then again, when you mess up this bad, there are consequences. And people should be held accountable for their actions, even if that means feeling hurt. I think that once your project reaches certain threshold of contributors, downloads and widespread use, you are no longer the ruler with unconstrained power over what happens to it, you made the project part of kind of an elite group, together with the likes of .net, react etc., and "unprofessional" is a gross understatement of what happened to Moq. Kzu stepping down himself would be the best thing to happen to Moq - instead, the responses from him I've seen so far didn't make me think it's a good idea to rely on a project where all the power is given to someone this irrational. While (unlike some colleagues) I pushed for the chill-pill so far, waiting for further events, I think there are many who don't want to cancel moq because of the scope of work but it'll be a necessary step if future stability is not somehow ensured. |
This guy added what was then a closed source package, which fired an obfuscated process which was only discovered through reverse engineering. To be an admin reading what was going on at the time is nothing short of a nightmare. You can say it was just a mistake. And maybe it was. But man what a mistake to make. Moq has millions of users, there was no discussion on this. No burn in time for SponserLink. And no opting out. We want him paid for his work but this is the wrong way to go about it. As for SponserLink, I think the idea itself is solid. Although I firmly believe that it's not for a 3rd party to implement. It seems best to let git providers or IDEs themselves implement something like it. There's a lot less security concerns that way. |
I'm thinking more like some sort of foundation or something that would back the entire project, not just the .Net/Nuget implementation. |
|
"twelfth most downloaded NuGet package" - are you serious? And he doesn't make an income from it? Yeah, wow, now I understand why people are talking about the problem with open source and github. That's a massive issue. |
|
@Gavin-Williams I think it depends on the type of the open source project. Usually, backend framework or no-GUI project is harder to get income from users. Moq as a test framework is targeting QA or SDET as major users. And big boss (who has finance permission) usually don't care much about QA's work. Even if some kind QA or SDE raise sponsorship application to a big boss/engineering manager, it's hard for them to show big benefits or cost down from using Moq. |
With how many nuget's this guy is involved with (317 Packages just from looking at Nuget), I'm not sure that is a realistic option. There is a good chance your using something else he made, or helps with |
It is a massive issue, and I feel for those devs because most OSS projects are a labor of love (outside acquisition or corporate partnerships). But basically making it into malware (via activism) ain't it. |
|
It can be a massive issue if you only think money as income. It depends on how you define income and your religion. For me, as a buddhist, I believe OSS contribution is maily for the next life instead of this life. We have concept called Karmic debt in Buddhism. OSS can help you reduce the Karmic debt and create a better life for your next life. OSS projects eases the life of most developers, which is best practices of ‘Purdue sentient beings’. According to my understanding of Karmic debt, both @kzu and @stakx will have a better life in their next reincarnation. However, @kzu may get some consequence on SponsorLink event since it's kind of a mistake. But it doesn't mean this mistake will eliminate what he has done in the past 10 years for Moq. You cannot simply make bad things equivalent to a number of good things. Bad things and good things are two different things in Karmic debt formula. Anything you have done will cause consequence. |
You both are delusional. Money is obviously the goal. Stop prentending it isn't and license it for money to companies. Its the only way forward. |
|
@PetterHiab If it just makes money for oneself, you can say the goal is money. If someone is trying to help every contributor in the community to get sponsorship, it's not just about money. It's about building a healthy community that every developer wanna contribute to open source projects and they benefits from the projects they work on. Definitely money is important for OSS sustainablity although it's not everything. Most OSS developer give up a project not just because he lose passion, most of the time, he found that he cannot profit from the project. This is the situation @kzu faces. But it's not only kzu. There are hundreds of kzu in .NET community facing the same issue. While maintaining a open source project, they cannot even get a cup of coffee sponsorship from the users. It's not about getting rich. It's just about thanksgiving. Just like tip culture in US. In most cases, tip is a must for every deals (usually 10-15% of the deal amount). But can you say tip is just for money? I think it's also about thanksgiving. |
Tip culture is not the greatest example for several reasons. It is absolutely US-centric because this has been solved in better ways in nearly every other country. And then it begs the question "to what end?" Do I tip the person who took my order at the fast-food counter? In software this would be "do I tip the guy who wrote Then there is question of whether tipping is just a poor way to subsidize what the employer themselves should be doing in the first place -- paying their employees an adequate wage. In the case of software, it's like an unpaid internship/volunteer work vs your first job. |
|
unpaid internship/volunteer work was made illegal in my country in 2009. |
|
@kzu, I think I got a response to my original request... even though it's not the one I was hoping for. Since this issue got a little off-track, I'll try to summarise: My original request
How the request got answeredYou didn't directly address this request here, so I'll start by citing you from a few other posts:
Here, its not entirely clear whether SponsorLink itself "won't come back", or just the email collecting aspect of it.
This likely answers the above uncertainty: it's the email collecting / PII aspect that won't come back.
You've made abundantly clear how invested you are in SponsorLink, and you've promised that it won't come back in a form that will cause another data privacy nightmare. By not directly replying to my original question, and via the above statements, I think it's reasonable to assume that SponsorLink may return to Moq in the future, in some improved form. I'm really glad that you've taken steps regarding data privacy and PII, and that's almost good enough for me... only time will tell whether or not the future implementation of SponsorLink will be acceptable to the Moq community. This part of my request remains unanswered for now. What's still missing for me personallyI believe that in your desire to improve the financial situation of OSS maintainers in the future, you've done the present-day .NET community a great disservice. Even though you have a noble and worthwhile goal in mind, the end does not justify the means. You don't seem to realise (or at least you haven't acknowledged) that people other than you also have a stake in Moq, and disregarding those people's interests was bound to offend them. Let me illustrate this a little bit.
To me as a major contributor to Moq, this is unacceptable. Why should I go on caring for Moq and invest my time & passion in it when you, the project owner, are willing to kill it off at any moment (and without including me in the decision process)? (Btw., this quote should explain why I think the term "guinea pig experiment" fits: you're willing to sacrifice Moq, the proverbial guinea pig, for something you consider a greater good. But I won't insist on using that term any further if you find it inappropriate.) In your blog post, you also wrote that...:
You even acknowledge me as the main contributor to the project. (I appreciate the credits, btw. Thank you! ❤️) But did it not occur to you to contact me and ask whether I was still interested at all in the project before declaring it abandoned and having your way with it? (My answer would have been this: "Yes, I am still very much interested in contributing to Moq. I have been taking a temporary break from OSS due to being otherwise busy in my life, but I am planning on getting back to work on Moq this autumn / winter.") This is your project, you created it and you also own the GitHub organization behind it. But you should know that when one contributes to someone else's project for so many years, one slowly makes it their own, too. In my eyes, Moq is, in actual fact, not longer exclusively yours. I think the people who said that ownership of Moq should be transferred to a group, organization, or foundation were on to something: it may have prevented you, currently the sole nominal owner, of making a decision without consulting other key project members. For much the same reason, I've also come to believe that any project with more than a single maintainer should be transparent about its decision making process; that is, it should explicitly declare how it is being governed. In conclusion, I'm surprised and TBH somewhat disappointed in how you handled (or rather mishandled) communication. I'm still hopeful that things can be mended... but at present, I'm inclined to take a step back from this repository and observe how things develop. I would like to keep contributing to Moq, but I have one key requirement:
What I'm going to do in the meantimeThis is my current plan (I'm not making any promises, though):
P.S.: I realise that this post may sound a little harsh. This whole situation has really made my head spin, and if I am to regain some peace of mind, I feel that I can no longer avoid some uncomfortable facts... but I truly don't mean to give you any offense. |
|
Heya @stakx! Thanks for taking the time to respond. I think taking time and meditating is a crucial part of taking the discussion forward. Some folks just assume I woke up one day with a crazy/stupid idea and just went with it. I shared my thoughts on this with at least one prominent OSS guy as far back as December 2020, so I think that's important context too. I have been ruminating about this for a while (and till I'm sure I totally missed a bunch of scenarios, side effects, and incentive alignment issues!). Your original requestI'm sorry you had to go fishing around for a response. I was not being intentionally obtuse. To make it perfectly clear: I will bring SponsorLink back to this project (and every other project I work on), and do so in a privacy-preserving way (you can explore the candidate approach). I perhaps avoided saying it in such stark terms because folks were going to assume my intention was to continue "violating" their GDPR/privacy rights and insist "I learned nothing" and what not, instead of what I always planned: put it out, learn from feedback, iterate and improve until it (hopefully) solves the problem I set out to solve (namely, sustainability). On current Moq, its contributors and you as the main maintainerAs you properly pointed out, more and more new C# features are starting to pile up as unsupported "tech-debt". Moq cannot survive in the long run unless it evolves with C#, or it will eventually (inevitably?) become irrelevant legacy software. I don't think this is hyperbole. So the question of a major rewrite and how it can happen, is not a side-show detail, IMHO. You made it quite explicit to me in the past too, that you could simply not dedicate enough time to anything vNext. I know you aren't doing the work on the current Moq for the money (there is none, after all!), but can't you envision a world in which you actually could? Quit your current job (or take a sabbatical?) and work full time on something that (as you mentioned) fascinates you? Why should that be a pipe dream? I had conversations with folks on the GH sponsors side, and on the MS side, and are actively pushing for things like Sponsor based GitHub feature toggling so that that dream becomes a reality. I would love nothing but for you to get paid for the work you do, possibly even do it full-time if that rocks your boat. Users should be able to vote with their wallets on issues that are important to them, and you should reap the benefits of fixing them. Somehow folks act as if that's a terrible goal and an outright disgusting thing to even propose. You should be free to continue doing it for free, if you so choose, by just not setting up a sponsorable account, though. On ownership and governanceI am forever grateful for your contributions to the project (past and hopefully future!), as well as the countless others who sent PRs. That said, I don't believe in design by committee. If there is ever a vNext that blows the competition out of the water, it won't happen because we vote in some Zoom meeting on whether we should X or Y. It will only happen if someone (i.e. me) sits down for MONTHS and works TIRELESSLY on it, obsesses over every tiny API naming, over extensibility, over long-term maintainability, and so on. As you pointed out yourself, that won't be yourself, and you would be one I'd considered well positioned to so so! Imagine what it's like for regular users that just consume the thing or report an issue or even send a PR for a very focused change/improvement. So what are the tools at my disposal to take a shot at doing that? As I explained in my follow-up blog post, the status quo just didn't work no matter how hard I tried. There's also a chicken-egg problem: I'd have to put a MASSIVE effort into it before getting ANY benefits from doing so. And at the end of the road, what would await me is a clamor for a committee to take over whatever I did and "not ruin the project" for them. That hardly seems like an enticing proposition.
I never promised anything to anyone other than just publishing my OSS code, pushing a nuget, and hope that fellow devs would find it as useful as I did (and still do!) myself. I cannot promise respectability (I may come up with a crazy idea everyone laughs at! fair enough, that's what you risk putting your ideas and code out there!), neither "good public standing" (anyone is free to think whatever they want about what I do or not do). I have explained in excruciating detail the reasons and my goals in implementing SponsorLink. Until such time similar features are offered out of the box by VS/VSCode/NuGet/GitHub, I will continue to iterate and improve it and depend on in for any future projects I do. I think it's abundantly clear by now that Sponsorships is ENTIRELY compatible with OSS. From the idea and goals point of view, I don't think I'm doing anything non-respectable or worthy of massive desertion and public scorn. So, maybe I was a bit (lot?) naive, but I would have thought that the prospect of a revival of a vNext would have been exciting to you, rather than "unacceptable" gamble on my part. Do you have any doubts that if Moq vNext happened it will be massive and leave every other mocking library biting the dust? I have no doubts because I'm quite clear too on the limitations of the underlying techniques we ALL currently use. And I've seen what a totally revamped approach can achieve. In closing: I deeply appreciate your contributions. I hope SponsorLink takes off, folks start to massively sponsor this and many other projects, and lots more dotnet OSS can flourish as a consequence, and therefore Moq vNext happens too! Which at that point might be sufficiently interesting that you'll consider coming back to the project. |
|
Thanks for the reply @kzu. Fair enough. I think we can leave it at that for the moment. I appreciate your expression of gratitude, too. I won't be leaving completely, but I think I will put my code contributions on hold for a while and observe how this project is going to recover. One final note: I think I would be excited about vNext, if I took a closer look and started tinkering around with it. Probably not quite excited enough to quit my regular job for it 😃 (even if I got sponsorship), but Roslyn APIs are definitely fascinating, hobby-wise. Alas, my daytime job is no longer in .NET world (and hasn't been for years!), and it's become challenging enough to simply keep up with what's going on here... familiarizing myself with a technology as complex as Roslyn isn't easily possible for me at this time. But let's wait and see, that may change. I think we can close this issue as answered (unless you want to keep it open a little longer for others to add their perspective, too, or finish their ongoing discussions). |
|
@kzu Hey, man. I think all your replies are a bit hard (instead of soft). I understand maybe it's part of your characteristics and hard to change. The community/the public usually like someone can be humble and even a bit cowardly. If you keep saying statements like 'I don't care...' or 'I don't promise anything...', the community will keep suspecting your goal. And the respect you wanna gain is usually from humbleness of the author or critical speaker of one project/one company. I think sometimes too transparent is not good for crisis PR. I have no idea if you two have discussed personally. But I do suggest you should do that for some sensentive topics instead of discussing everything in Github issue. You have a company and I believe you understand what I mean. And Moq is lucky because this project have @stakx as the co-contributor. And he is trying his best to save this project. In most OSS projects, there is only one major contributor. If it have happened to Moq, this project has been dead. Because no matter what you say, the community has decided you are guility or criminal (they think they are the Judges although I know they are not). And I did check the law. GDPR is NOT criminal offense. It's just civil offense. But in the whole event, they judge you as a criminal which is very ridiculious. (for example, they say you are putting a gun on their head) I can frankly tell you that I start to know this accident because one of colleague suggest locking the version of Moq in a PR and I feel a bit weird. It's my first time to see a company is locking a nuget package version. And I start investigating what happened as I'm also a OSS developer. Some colleagues suggest we should find a alternative as Moq is becoming a malware. For the sake of change cost, I suggest we hold on and see what happens. A few teams in my company are still waiting to see what Moq team will finally decide. So far, what @stakx suggest are all in the right direction. No matter who is the owner of this project, he is doing something good for the project. |
You are smart. I did quit my job and start a company for my open source project a few years ago. I can 100% sure that this is a big mistake I made in my life. The original plan is that I can get consulting fee and maintainance fee from the potential company users of my open source project. But the fact is that no company is willing to pay. (I'm the guy who really experiences the joke that Fortune 500 companies give you a star and say goodbye) And I didn't change the license of my project to commercial license, which is another mistake I made. The company eventually becomes a outsourcing company and several years later I go back to work for big companies. I'm not sure what kzu's company is doing and how the business is. But open source is NOT a good topic of entrepreneurship. There are very few successful cases. Even Docker mother company is not so successful. Usually open source is for big company and for strategic purpose. It's kind of marketing function instead of earning function. |
Case of a criminal prosecution under GDPR that resulted in prison: link |
|
@cmjdiff, you may want to re-read that article. It does not even mention the GDPR. It's refers to the UK's Computer Misuse Act (which, unless I am mistaken, predates the GDPR by nearly 3 decades):
|
|
@tonyqus, I'm sorry to hear that your enterprise didn't succeed. But at least you came away with invaluable life experience and you'll never have to wonder, "what if I had dared"? The world would be a poorer, boring place without risk-takers such as yourself. |
|
@tonyqus I'm sorry if I'm coming across as a bit harsh. I tried to be very understanding of everyone's points of view. I've felt very little sympathy or understanding of my point of view from most folks, except for a few that were willing to stick their necks above all the angry replies. You have been one, so thanks for that. Your experience trying to live off of OSS is sobering. I'm sorry it didn't work, and rest assured, you're not the only one telling me this is all pointless. It may very well be so. |
|
As already mentioned, SponsorLink is the wrong way to approach licensing for CI tooling. That Moq is part of the CI build process is what limits your options, since what would work for any other OSS running in runtime with the application could be handled in other ways gracefully. Paying for OSS is a solved problem. The only viable option is an in faith licensing model, where Moq is free for some use cases and requires a license for others. I've been watching this issue and waiting to see where it would land, but if you're firm about SponsorLink for Moq, we'll just bite the bullet and replace it. We'd been happy to pay a license to avoid the hassle. |
SponsorLink never affects CI. It's intended as an in-editor only thing. It always was. It never activates any behavior unless you're actively coding in an editor. |
If you're sending that out NOW, when SponsorLink in its current flawed implementation is already gone from Moq's latest package (and won't come back as-is at all), then you are likely out of date (it was gone within 24 hours). SL is even open source now and several steps were taken to ease folk's concerns. That said, you can always "invest" in replacing it when there's no need for it. I just believe that the next library will eventually be in the same situation as Moq unless OSS sustainability situation changes, so I'm not so convinced that's a good "investment" either. |
No. You are assuming everyone thinks like you. Not everyone think they deserve to get paid for things they do on their freetime. For example, I don't expect to get paid for volunteering as a football trainer for kids. Still takes 3 evenings out of the week. |
Yeah, that comparison doesn't really change anything. If you suddenly want to get paid for coaching and they say no you have a choice of continuing unpaid or quitting forcing them to find a new trainer. The same goes for Moq although with a role reversal; if @kzu wants to get paid for his work and finds a way to enable/enforce it you can either pay (sponsor) or use another framework. Expectations change, when you start a labour of love with a few users and contributors it's all well and good to work on it in your free time. But when the project grows and consumes too much of your time you are likely to want some compensation, especially if huge enterprises benefit from your work. |
|
You don't understand. You can't expect money for teaching kids football in your freetime. Just like you can't expect money for FOSS. This project is good enough to monetize properly by charging license money. |
|
Sure, that's one way of doing it. As I explained in my follow up post, I'm not convinced the status quo is great and that there's nothing to improve. A third option could be available, and it's most certainly not against OSS to seek sponsorships. That much has been proven by OpenCollective and others similar initiatives. |
|
I'm going to close this issue, since my original question has been answered above and the other discussions appear to have come to a resting point. (But feel free to discuss further even if the issue is closed.) |
|
The v2 implementation considers every contributor to every sponsorable project, a sponsor of said project(s). Yay :). Please give it a look at the new fancy GH CLI extension at https://github.com/devlooped/gh-sponsors |
and others
The way how Moq is being used as a "distribution channel" for what (at this moment in time) essentially amounts to a social experiment strikes me as really unfair not just to Moq's user base, but (ironically) also to the project itself and all of its contributors. As a frequent collaborator, I've taken great pride in being part of such a widely respected project, and I dare say it's been an essential go-to tool in the .NET ecosystem. (Yes, there are some great alternatives like e. g. NSubstitute or FakeItEasy, and I'm not discounting those; but fact remains that Moq has so far been the most popular of them all.) All of this is now being put into jeopardy in order to get feedback on, and develop, SponsorLink.
I'm not commenting on SponsorLink's potential here – it may or may not be a good idea – but assuming that SponsorLink is actually a great idea worth following up on, then shouldn't it be able to stand on its own legs and get some traction without having to piggy-back on the success of another hugely successful library like Moq?
I know it's been tried before, but in the hope that my ranking as the current top contributor to the project bears some weight, I'd like to kindly and respectfully request that SponsorLink be completely removed from the Moq project, and that it not be brought back again, unless (and only if) it has proved itself to be a viable and generally accepted part of the .NET ecosystem.
If you do need some library to test SponsorLink on, please let it be something other than Moq... Moq is simply too valuable and important to be squandered this way.
P.S.: Some shortcuts:
The text was updated successfully, but these errors were encountered: