I don't see how it's worse?
https://github.com/microsoft/garnet/blob/main/LICENSE
It's MIT licensed?
https://github.com/microsoft/garnet/blob/main/LICENSE
It's MIT licensed?
By "fake", I mean Microsoft largely treats their Open Source codebases like they are closed-source, in-house proprietary codebases that they happen to let members of the public look at.
They'll accept a PR once in a while, but mostly it appears Issues and PR's are used as a free alternative to UserVoice.
Every decision is made behind closed doors (probably a MS Teams call actually), and you'll notice how top-heavy their staff is on these projects (half a dozen employees with "Manager" in their title on any given repo).
Beggars can't be choosers, and I'm glad they are dipping their toes into the FOSS water... but I don't really get FOSS vibes from their projects on Github.
What is it with .NET that compels you to lie?
Also FOSS and open contribution are different things, as sibling comment notes.
If you think otherwise, I suggest checking if there's any aluminium foil on your head.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons..."
Are you actually unaware of this? If so, why? Is it age or have you been sheltered somehow?
MIT license allows this, hence it's not a free software license. Because very large corporations don't like freedom they've poisoned the discourse around software freedom and launched PR campaigns trying to substitute talk about freedom with talk about openness or open source. To some extent they've succeeded, as evidenced by the chatter about it in this thread.
I don't know how you can extinguish something that's MIT licensed and has a million copies around the world.
I wouldn't trust Microsoft near my open source code base in 3 centuries
They can extinguish it by just stealing all the code, and using their bigger marketplace advantage to become the defacto standard.
gestures wildly at the MIT-licenced VSCode codebase
Yes, they are not rug pulling the VSCode source but by locking down the marketplace (and never giving a truly open source VSCode, what developers think of as "VSCode") they are in the processes of locking out forks.
Fair point! good example of an attempt to extinguish.
Like seriously - I haven't heard of them doing it in quite a long time. I know they were atrocious in the 90s and 00s, I'm not disputing that at all. Are there any examples of them continuing this behavior in the last decade though?
Further, a huge percentage of the people making those decisions back then are no longer with the company, different people are in charge, etc. The industry has changed it's relationship with open source - company board rooms aren't scared of the consequences of loading open source onto a server, the legality and liabilities have been hashed out, and MS isn't really even capable of pulling those fear levers anymore. MS itself has repositioned in the industry - their dreams of total computing dominance have been shattered: there's no chance of a windows derivative owning the server market any more, there's no money in browsers or consumer OSes (heck even MS's domination in gaming is showing cracks due the the efforts of valve). Point being - would it even make strategic sense for them to try to EEE anything anymore?
Note: I have almost no ties to MS. I haven't used an MS os or desktop software since before covid (in any capacity, even moving the mouse on a computer running windows). I don't use any of their SaaS products personally or professionally. There are integrations between the products I help build and azure, however those are not a major source of revenue for my employer and I do very little work that even touches that stuff. Point being - I'm pretty non-MS in my life and don't have any sort of loyalty or incentive to defend them. I do abhor their EEE actions back in the 90s and 00s when they were doing them, and those still make me angry... but that's not a reason to assume that different people at a company are going to act the same as the old-school ones.
While it may technically be open source due to it's license and you can literally go look at the source - Microsoft is operating these codebases as-if they are proprietary. Every decision is made out of public - and I would not be surprised to learn they have their own internal tracker for the "real" backlog items. You frequently see command/comments by Microsoft employees which clearly are triggering workflows in their real backlog tracker, and near-zero discussion happens in Github by Microsoft employees, and when it does - it's clearly through a PR filter.
Like I said, beggars can't be choosers and it's better to have this than nothing - but I don't really think Microsoft has grasped the true concept of FOSS as-of yet.
> Is SQLite not open-source?
Not really in my opinion either. There's no way to contribute at all... best you can do it raise hell on the forums about a particular issue you want to see fixed. So while it's Open Source in the strict sense, it's not Open Source in the general sense.
The sibling comments contain some sharper critique of Microsoft if you haven't read them yet.
> best you can do it raise hell on the forums about a particular issue you want to see fixed
Also, do you have any open source projects that you wrote, maintain, and accept contributions?
There seems to be a disconnect here. I agree, demanding someone else make changes for you is in poor taste. The issue is, some of these projects advertise themselves as being open source while having no meaningful way to contribute changes back upstream - ie. the spirit of open source.
If I use your program for free, and encounter a bug, I should be able to fix it and contribute that back upstream so everyone benefits. That's my way of "paying back" and helping the community. Projects that reject contributions, or make contributing difficult are not in the spirit of open source, even if they are technically open source via their license.
That's what I call "fake" open source - you want the positive image of being Open Source only.
I mean, you're not demanding someone else make the changes. You're only demanding that they engage and build a community around their project and all that entails.
As long as the license is reasonable, anybody else could pick up the project and do the community building around it. Apache HTTP Server developed around community patches to NCSA httpd. I don't think hitch (from the people who brought you Varnish) is well know, but it started as stud with community patches. If something like this takes off, the originator will either start taking the community patches too, or not; it's their choice.
In the meantime, as a user, I get the benefit of whatever changes the origin provides and I can patch it as I want, and fix up problems that I see. That works for code dump open source and community open source,.
Not everyone has time for a second or third full-time job.
Am I "fake open source"?
In my opinion, for something to be truly open source, I should be able to fix a bug I ran into, or implement a feature from the backlog and contribute it back upstream. If upstream is just going to ignore my contribution, pretend it doesn't exist, or reject it just because - then that codebase is just pretending to be open source.
That's not to say you are required to accept all contributions - I'm saying you should be open to contributions that A) save you time B) enhance the codebase or C) fix confirmed bugs.
In Microsoft's case - I don't see a lot of that going on. I see lots of Issues (bug reports), some PR's, but mostly opaque decision making, and complete silence on things the Corporate side of Microsoft doesn't want to comment on yet. Which is the beef - it's a corporate project run like it's proprietary but you can go look at the code. Again, better than nothing, but it's not really what I consider true open source.
I'd say the spirit of open source is that others are free to modify the code and that's it. This requires a good license, the possibility to fork, some documentation and a way to build the project yourself.
But why would accepting contributions be required?
This blog post is legendary (in my mind): "Open Source Maintainers Owe You Nothing" -> https://mikemcquaid.com/open-source-maintainers-owe-you-noth...
It perfectly sums up how this conversation is going.
I disagree. There's nothing about open source or the various open source licenses that require accepting engagement from the community and/or contributions.
Open source means allowing modifications, and sharing those modifications. It's in most licenses that the software is provided as is and without warranty.
> In my opinion, for something to be truly open source, I should be able to fix a bug I ran into, or implement a feature from the backlog and contribute it back upstream. If upstream is just going to ignore my contribution, pretend it doesn't exist, or reject it just because - then that codebase is just pretending to be open source.
A project not accepting outside contributions is still open source, not pretending to be, and the beauty of it is - if you want it to accept outside contributions, you are able to fork it and accept contributions on your own fork, or otherwise share your modifications. But there's absolutely no obligation of the original dev/owner to accept or engage with anything from the community. It's in the license, the software is provided as is and without warranty of any kind.
Maybe it's worthwhile to coin a new term, community software, to specifically make a distinction between projects that are community developed (accept contributions) vs those that don't.
How long after they release their code are the required to keep this up? Do they need to respond to your requests within 5 business days?
If they retire / move on to another project, does the source code stop being open source?
It was about being able to have access to, fork/modify, and redistribute the software. That's the important thing - that the software I use can be modified by me, and if I wish to do so, the license allows me to then redistribute those changes vs. proprietary software, which cannot be modified nor redistributed.
I'm not sure why the zeitgeist went from the above and turned into "all open source must be community software and engage with users and accept contributions" because that was never what it was about. It was a benefit of some projects, sure, but at the end of the day the important thing isn't whether or not the project accepts contributions but whether I have the power and license to modify something to my liking, fork it if I wash, and/or redistribute my changes.