In my experience there are two main advantages: reproducibility and cross-language support.
Build systems like maven can read from the entire filesystem (e.g. it reads from ./~m2) and you might end up with artifacts that depend on the state of the machine. This makes debugging production issues harder. You can of course be careful with other build systems to stay reproducible but it's easy to make mistakes and buck will enforce that you don't.
Companies like Meta and Google have huge monorepos and are using multiple languages. It's common for developers to deal with multiple languages and for projects to depend on other languages. Buck can deal with that very naturally and avoids the engineers to deal with multiple build tools.
There are other upsides and downsides listed on their website.
Facebook has a terrible track record when it comes to open-sourcing their internal tools. See: Phabricator, HHVM, Flow, Jest, ...
Even React, which is their most popular library, is not actually "open source." They're very transparent about the fact that their priorities are Facebook's needs -- even if they do take community input.
None of this is per-se bad, but you should definitely treat an open-source project out of Facebook with skepticism when it comes to adopting it for your own use cases (possibly making sure you're not too locked in when an incompatible v2 comes out with virtually no warning after FB's internal implementation drifts).
> Even React, which is their most popular library, is not actually "open source."
How do you define "open source"? It typically simply means the source code is available. By any definition I can think of, React is definitely both free and open source. How they design the software or if they take contributors isn't really relevant.
"Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose"
The license is the key bit.
On the other hand, there's "source available" software (also on wikipedia https://en.wikipedia.org/wiki/Source-available_software ), which is what your definition equates to, and I personally don't want to see confused with open source or free software.
There's three domains where people usually use the term "open source".
- Freely licensed software (eg: MIT, GPL, etc)
- Code visibility (eg: ForgeRock)
- Community focus/contributions
Not all "open source" implements each of these, and just because they implement one and not the other doesn't mean they're not expressly open source. Just some ecosystems are more open than others.
I'm aware React is MIT and of the various licenses etc.
As I see it commonly defined, "open source software", FOSS, and FLOSS all mean the same thing more or less. That the project uses an OSI approved license, or one very close to it, whether it's MIT, Apache2, or GPL.
"Free software" is the only of the phrases that I see having two competing common definitions, the "free as in money", and "free as in Free Software Foundation's definition of free software". This seems pretty understandable, since "free" is overloaded.
I only infrequently see people mixing up "open source" and "source available", and that's the specific thing I'm trying to discourage people from mixing up. I think keeping those terms clear, and especially calling out "source available" software as _not_ being "open source" (i.e. not granting you the freedom to modify it or run your own copy in some cases) is important.
I see the opposite often argued too - that open-source is too wide a term as could also be understood as source available, and that FOSS/FLOSS should be preffered. But you're right, looking at most literature, most people seem to refer to oss and foss to be largely the same thing. I guess my biases are showing lol
Coming back to the original argument - which was that React was not truly open-source - being MIT, it 100% is, so I still don't understand it. That they prioritize their own needs for feature development is pretty much irrelevant, the source is there and you have permission to fork, tweak and publish changes on your own at any time. You legally are in your own right, but they don't have to make it easy on you.
As I understand it, "Free Software" is the term the FSF and general hacker community settled on for licenses that preserve user's freedom to modify and redistribute source code.
From there, I see "Open source" being slightly more often associated with companies or younger developers, and "free software" more often being associated with the GNU project, copyleft projects, etc.
I'm curious if you have references or more explanation about the difference you're trying to draw, since it's one I haven't seen before.
> I'm curious if you have references or more explanation about the difference you're trying to draw, since it's one I haven't seen before.
My distinction between the two is whether outside contributions make it back into the original project. Free Software is about the rights of end users to inspect the code and make and distribute their own modifications, but then Open Source takes it a bit further by explicitly soliciting contributions with the ostensible aim of building a better project through cooperative labor than an individual programmer could build alone.
In practice though "Open Source" has turned into unpaid project management work for billion-dollar corporations, bitter disputes between contributors over conflicting standards of morality, technical visions in constant flux as contributors come and go, and endless bikeshedding about semantic version numbers / code style guides / other things that don't matter. For years I thought I was totally burned out on Free Software and walked away from all of it, but what I was actually burned out on is Open Source and have been able to love programming again by working on things that are explicitly "Free Software but not Open Source".
The `actix-web` drama a few years ago is a perfect example, when a huge crowd of onlookers felt morally justified excoriating a popular project's creator / maintainer for not managing their project to the crowd's standards: https://steveklabnik.com/writing/a-sad-day-for-rust
>Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose
??? Isn't React licenced under the MIT licence? It seems to me that it tickes all boxes?
As I wrote at the top of my comment. "I agree with you that react is definitely open source" (and no, I did not edit that in, it was there when you read it)
I'm aware react is licensed under the MIT license. I was just talking about how the parent comment chose to define "open source".
By that definition, any software project that is driven by a BDFL wouldn't be open source, including Linux.
The terminology hasn't drifted that much. I think there is a small and vocal group of people who are trying to take back "open source" by reframing what it means, so as to exclude corporate projects. It doesn't make sense to me.
>any software project that is driven by a BDFL wouldn't be open source, including Linux.
There are certainly a push in that direction. And that you need a group of people, core or council to be considered as Open Source. And Linux has that.
>The terminology hasn't drifted that much.
It depends how you measure it, but Twitter and HN are at least two places where lots of developers are suggesting Open Sources equals to Community driven. And yes, there are also some movement towards MIT, BSD or Apache 2.0 as being not considered as Open Source because they do not contribute back changes. Although that hasn't gotten any traction. ( yet )
Everyone is going on tangents, but yes React is as open-source as they come. What people are conflating are the notion of community-driven and open-source.
React is a successful Facebook OSS project. An example of one which went poorly is Thrift. Facebook open-sourced it and then internally used fbthrift which diverged drastically. OSS Thrift isn't that popular these days any more.
Disagree. We need to stop trying to cram meaning into phrases that are already defined. Open source means the source code is freely available. Adding anything else requires a different name.
Free Software is an established term, and React certainly is not Free Software, due to its patent. I very much doubt that React is Open Source either, for the same reason.
So react is MIT-licensed and has a patent. How do those two work together? If I modify React's source-code might I not infringe on the patent and then get sued by Meta?
I’m not a lawyer, but from my perspective, that’s indeed a concern. And perhaps you could get sued just by using React. It could differ between jurisdictions as well.
A standard open source license with a patent grant, like the Apache license, would have been a lot clearer, but Facebook has so far refused to license React in that way.
A problematic patent grant was offered for earlier versions of React but that’s not the case anymore (and didn’t really fix the problem anyway).
I'm not a lawyer either and I wonder about the scope of Apache patent grant. Does it give you the right to use any patents the software in question "uses" in any possible context? Or does it simply allow you to modify the software any way you like and not get sued for infringement? But then how much can I modify it and still retain the right to use those patents? I mean if I create a totally unrelated software package which however shares some code with the original work, can I keep on using those patents anyway I want?
What's wrong with Flow, Jest or Graphql? I think these are all fantastic projects. I mean, Flow "lost out" to Typescript, but, it's usual for one winner to emerge from competing frameworks.
Graphql is great. With Jest, that project feels a little abandoned because the Typescript support (ts-jest) is pretty janky and has bad performance. Meanwhile in the ecosystem in 2022, it's becoming the norm to have first-class Typescript support.
React is patented and Facebook is actively choosing not to offer a patent grant, so unfortunately that’s not the whole story.
A fork may not be an option. Perhaps a given organization may not even be allowed to use React, if Facebook decides against it for some reason. Jurisdictions can differ as well.
In my opinion, the best thing would be if Facebook simply made the terms clear by using the Apache license or similar. But hey, it’s Facebook, so I’m not expecting much…
I'm actually curious what the strategy is here. To my knowledge only FB, Google and MS do megascale monorepo, and Google and MS already have a solution. Are there now other companies outgrowing Git that Facebook is hoping to build a community with?
Open sourcing an internal repository with extensive, ongoing work on it is always a difficult affair, because you're creating a second source of truth. (It isn't just how you manage external contributions, but also workflows like releases and CI.)
It means they haven't (yet?) transitioned to open-first and it'll require proving themselves that they'll do open-first development before trusting them. Not willing to bet my work on a product where the governance isn't open but everything is driven by and for a single company's needs.
For what, another Phabricator, that I’ll inevitably have to migrate my company away from again?
So if history serves the next announcement to watch for is your departure from Facebook and the launch of Edenity, which will be sunset and abandoned inside a decade once it fails to IPO. Am I close?
I have built a very similar project some time ago and although it's not as beautiful and organized as yours, it's pretty fast! It's in Portuguese, but if any of you guys want to check it out: http://wikigraph.russoft.tech/
Build systems like maven can read from the entire filesystem (e.g. it reads from ./~m2) and you might end up with artifacts that depend on the state of the machine. This makes debugging production issues harder. You can of course be careful with other build systems to stay reproducible but it's easy to make mistakes and buck will enforce that you don't.
Companies like Meta and Google have huge monorepos and are using multiple languages. It's common for developers to deal with multiple languages and for projects to depend on other languages. Buck can deal with that very naturally and avoids the engineers to deal with multiple build tools.
There are other upsides and downsides listed on their website.