Collaboration, across companies, not ownership by one company is the root of open source. To do that you need some kind of governance model. Essentially "ownership" by one company is conducive to quick progress on specific problems, but not collaboration.
"open source" here is working as intended. the thing is, "open source" is misunderstood by many (most?) individuals.
"open source" was explicitly created by Eric Raymond and others in the late 90ies because the Free Software movement was seen as too extremistic by companies still deeply rooted into the proprietary model.
"open source" is a nice way out, in order to be able to look cool, while not actually playing it cool.
I said it in many posts and i'll say it again: if you're require to give up copyright on your contributions and the license isn't free-software... then it's just a matter of time before a company turns your code into proprietary intellectual property.
people that do not agree are simply delusional (or okay with that).
The mainstream FOSS licenses (GPL, BSD, Apache2, etc.) are all included both in the official list of open source licenses [2] and the official list of free software licenses [3], so these licenses are both open source licenses and free software licenses. These lists might have some minor differences, but they share a substantial subset and the definitions broadly speaking define the same thing.
[0] https://opensource.org/osd/
[1] https://www.gnu.org/philosophy/free-sw.html
OSS as a term was created at a time when free software, as defined by GNU, was effectively becoming the de-facto standard for collaborative efforts on the internet. Yes, MIT and BSD were around (barely, in the BSD case), but the rising star was Linux and Linux (and the software built on it - GTK, gimp, etc) was GPL.
The industry needed a way to get on the action without touching the "communist" GPL, and that's why ESR's definition of "Open Source" was endorsed. Obviously they coopted all the existing bits they were ok with (i.e. all the ones that did not impose any extra burden on companies), that's why the definitions overlap substantially; but they are not the same thing. If they were, there would not have been any need to create a new definition for it.
which against, doesn't really makes sense.
Stallman has repeated over and over that the Free Software movement is not about communism (despite what communist people like to say).
Most likely, the industry needed a way to get people to submit improvements and patches (essentially doing Development, QA and support) for free without having to give a way the right to sell proprietary services.
The distinction between copyleft and non-copyleft licenses, e.g. GPL and BSD, is different from the distinction between open source and free software, which is mainly ideological. The GPL is a copyleft license but also an open source license, as you can see on the OSI website.
For maximum context, here is a quote from the board meeting minutes [0] where the OSI approved the Free Software Foundation's copyleft GPL license as an open source license in accordance with the Open Source Definition: "The Open Source Initiative is pleased to announce that, based on broad review and acceptance by both the Board and the community, it has confirmed that GPLv3 and LGPLv3 both conform to the Open Source Definition."
But if you take a look at the Free Software Foundation's list [0] of Free Software licenses, you will see that it lists both the CDDL and the MPL as Free Software according to the Free Software Definition.
So why should a new definition have been needed to allow these licenses when they are already allowed by the old definition? Maybe you could supply some of that context you were talking about?
> So why should a new definition have been needed to allow these licenses when they are already allowed by the old definition?
Maybe you should ask the founders of OSI? If their work was fundamentally pointless, why did they do it? Because it wasn't pointless, it was seen as necessary to be able to say "we are Good Guys, but not like them dirty GPL hippies".
If that was true that would have been just some marketing campaign.
There would have been no need to divert the attention from the free software foundation.
In other words, we had a thing that would benefit everyone in many ways, but some people didn't like the marketing message of "users deserve these rights!" so a complementary marketing message of "cheaper and higher-quality software through collaboration!" was needed to reach that group.
[0] https://en.wikipedia.org/wiki/History_of_free_and_open-sourc...
"Open Core" means they open-source the core of their product portfolio, core which some enterprising people may use to develop applications on, but for others will really need the buy into the rest of the portfolio to get the best use out of.
I think the fault is with the consumers. Many companies consume but do not participate in open source. All the incentives are there for companies to become vendors rather than participants (stewards?) of an open source project.
I may be mistaken here, but I think we will see pure functionality become less important to enterprise customers, which might (maybe not, but one can hope) proper open source business models more viable again.
In fact there's been quite a bit of vitriol about Canonical (company behind Ubuntu) profiting (for what that's worth) from all the hard work from Debian volunteers and not sharing as much of that value back to Debian as was felt was deserved.
* I do realise that different release timings can fudge with the timing, but when fedora is building upstream versions and I hear it, its a bit.. disheartening.
I think this usually doesn't really have to do with Canonical at all, but with third party developers only testing against and building for Ubuntu.
You are assuming that a strict and stable governance model is good for OSS.
But often it is the least stable projects with lots of hostile forks and huge mailing list arguments which turn out to be the most successful projects.
Strict and stable governance model is perhaps dull and turns away contributors who feel they will never get to the top of such a stable project with long timelines and complex procedures for everything.
> "Ask bob on discord and he'll give you commit access to the repo"
and:
> "First you need to fill out the CLA and send 3 pull requests before you can then apply for committer access at the bi-monthly steering group committee. Present your case in an email to them at least 28 days beforehand, and make sure an existing committer seconds it"
It was cool to be a UNIX/FOSS zealot during the late 90's while still getting monetary support.
Writing M$ on the email signature and such.
Eventually I had to find a way to pay my bills.
You can even develop commercial software and still support FOSS. This isn't some think the kids of the 90s do. Most new open source projects are created by younger developers.
Younger developers are re-discovering public domain and shareware, while rebranding them as open core.
To me, many of the elements of political interest with free software in general don't really come into play with games (although some incidental issues, like privacy concerns, certainly do come into play in practice). Part of what makes software freedom urgent where it matters most is a very material dependency on software— it matters most when we depend on that software to make our livings, or to access medical care, or to access education. The stakes are lower for games, and I imagine that many people who care deeply about free software are still comfortable buying and running proprietary games. I know I am.
I don't think there's a serious problem with making/selling proprietary games, either, even if you're generally committed to free software.
Your comparison to Terraform is also interesting. Apache Kafka, for example, has been absorbed by Amazon (MSK). Apache Spark is Amazon EMR. Just looking through Amazon's paid service offering I find several Apache projects rebranded and for sale. A cynical take could be that Apache is an org that helps companies like Amazon profit off of the work of open source developers.
It's something I've seen countless times in my life. A piece of software achieves something pretty close to perfection for its task, but the self-imposed "need" to continue development on it ruins it.
But I keep getting told I need a "Slackware intervention" :P
Totally unnecessary.
I now try my best to avoid anything that involves Python.
With your argument about compatibility no programming language would ever be able to evolve or deprecate/remove some features. Look at how many things changed e.g. between recent C++, Rust or C# major releases. Python had only one major revision in 15 years in comparison!
If you are using software that still requires Python 2 that's very much a problem of that application and not Python. Complain to the vendor responsible, not about Python. They had ample time to update their code.
End users had no business touching Python 2 for at least a decade now. And upward compatibility between the point releases of Python is (and has been) generally pretty good.
> With your argument about compatibility no programming language would ever be able to evolve
"evolve" and "change" are not ends in themselves. If it was usable as it was, then there was no need to evolve or change in an incompatible way.
15 years ago: also irrelevant. World War One was unnecessary, and that was 109 years ago. Whatever issues existed are sorted out by now, but that doesn't mean it had to happen.
That you find them unnecessary because the original code was "usable as is" for you is irrelevant.
The reasons why these changes have been done (for a developer they have been fairly minor) has been hashed and rehashed for the past 15 years, Guido van Rossum wrote on it extensively too.
Most has been performance-related (Python 3 is significantly faster than 2) and probably the biggest user-visible change is the clean up of string handling with everything being Unicode now.
Frankly, anyone complaining about this stuff today is just beating the old dead horse for the sake of having something to complain about. The same like some people constantly bringing up the Linux systemd discussions after more than a decade, even though they are completely irrelevant today.
1. It's not true
2. It's true, but it's not important
3. It's true, and it's important, but we're tired of talking about it.
I'm not lying. This problem cost me a full weekend earlier this year. I may have misremembered the exact version numbers, though. Perhaps it wasn't between 2 and 3. Is there a Python 4?
The problem is that you can't have one Python interpreter that covers all versions of Python, and Python is very unforgiving about using the wrong interpreter version.
In any case, it was a serious problem that cost me a lot of time and really soured me on Python as an end user. I've not encountered a similar issue with any other language before, so this appears to be uniquely a Python thing.
But I don't know. I'm happy enough to just avoid Python-based anything whenever possible now.
If you have downloaded Python 2, you must have done it intentionally, it isn't even available from the Python.org website download anymore - and had not been for a long time.
>The problem is that you can't have one Python interpreter that covers all versions of Python, and Python is very unforgiving about using the wrong interpreter version.
Because it doesn't make sense. The language evolves. Nobody is going to stop working on it only because it could break some old code somewhere. The changes from 2 to 3 happened *15 years ago*.
There is no reason to try to compile/run old Python 2 code today - and if you still do need it for some reason, then you need to download the Python 2 version (which are still available, if you need them but one has to look for them). But then you better know what you are doing.
If some old code requires Python 2, any somewhat experienced Python developer will spot that right away (e.g. the use of print statement in Python 2 vs. print() function in Python 3 is a dead giveaway).
>In any case, it was a serious problem that cost me a lot of time and really soured me on Python as an end user. I've not encountered a similar issue with any other language before, so this appears to be uniquely a Python thing.
I don't doubt it has costed you a lot of time but this was a problem entirely of your own doing by not doing your homework.
You would have exactly the same problems if you tried to compile old K&R C code or C++ code from 20 years ago using modern compilers. Or tried to feed modern C# code to a compiler from 10 years ago. Or, God forbid, tried to run some modern Javascript code using old browser - or that old HTML with Flash and what not in a modern browser ...
Python is actually much more lenient in this regard because a major language change has happened only once, 15 years ago, with Python 2 being deprecated for well over a decade. The point releases are all upward compatible with no issues.
> You would have exactly the same problems if you tried to compile old K&R C code or C++ code from 20 years ago using modern compilers. Or tried to feed modern C# code to a compiler from 10 years ago.
If you feed 10 year old C# to a modern compiler it will compile it fine. I’d imagine most C and C++ of even 20-year vintage will still compile. The issue is of forward compatibility, not backwards.
Likewise C and C++ have had enough breaking changes since 2010.
With that said, neither IL nor C# itself had any changes breaking forward compatibility (aside from a very early change to foreach recently discussed here).
Also, "it depends" isn't the same as "If you feed 10 year old C# to a modern compiler it will compile it fine."
If you're shrinking then a competitor is providing better options, or your problem space has shifted.
Various dependencies, like XML parsers, JPEG decoders, HTTP libraries, etc, change over time, drop deprecated APIs and need the main application to adapt. It'll also bump into the tech changing around it -- UTF8, year 2038, 64 bit CPUs, etc.
For a project this size it takes work just to stand still and keep it comfortably buildable on a modern Linux distro.
death is part of life though, and the only thing that grows without and end is cancer (quite literally).
I don't see why project can't just be considered "done": yeah you update dependencies and make it work with new/current formats, but essentially it's done. The use case is now clearly defined, implemented and tested.
AWS offers hosted versions of each. They are not, as you say "rebranded and for sale", but rather are hosted services, running whatever upstream releases.
But to say that the project as been absorbed by AWS (in either case) is simply false. Spark is developed by a community of numerous companies, of which Databricks is usually most prominent. Kafka is likewise a community of several organizations, of which Confluent tends to be the most influential.
Yes, Apache is (and always has been) business-friendly. The license enables companies to profit on those projects. But, for the most part, companies that benefit from those project also contribute back to them, as a way to ensure sustainability. That's how it is supposed to work.
Apache httpd certainly helped tons of companies profit, so helping companies profit doesn't seem off-brand.
This is the right thing to do from a helping the world perspective, but it’s clearly hurt ASF’s reputation.
They should simply start saying no to some of these dead/dying projects. Or at the very least brand them differently.
And while it's not exactly common there have been forks of Attic'd projects outside of the ASF that went on to be useful to people.