It seems that “younger generation” programmers underestimate the value of governance in OSS. The recent Terraform kerluffle couldn’t have happened if Terraform was in the ASF, etc.
Agreed... We are seeing dozens of database companies turn their OSS into basically proprietary shared code licenses. And we seem to still pretend its "open source"
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.
To put it another way: many startups today have adopted the "Open Core" business model, and it's really more about marketing than actual open-source.
"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 can't really fault companies for using this model. Development is expensive, and business models around open-source are hard. I mean, just look at what Red Hat ends up doing to fend off copycats. Getting people to try your product and also rely on it is a tricky proposition.
I don't fault them either. In fact I'm a big fan of many of those companies.
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 think we are heading towards a bit of a shift in this regard. With the CRA in Europe and similar legislation in the States it will become more important to have "enterprise" services surrounding open source software. This is for example support, but also vulnerability assessment and similar things.
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.
Debian is not a commercial entity. It's a volunteer organization.
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've always wondered about that, I feel like ubuntu sometimes doesn't contribute fixes upstream. When I hear 'it works on ubuntu but not on distro X', it makes me wonder why ubuntu devs didnt post the fixes upstream.
* 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.
The flipside is that companies don't seem all that interested in this sort of collaboration, though, nor should they be. It doesn't really make sense for a company that believes its edge is its technology to both give up the secret sauce and accept the dillution of that edge that comes from taking code from outside contributors. The modern version of "open source" is a natural evolution of the concept when this is how companies think.
> We are seeing dozens of database companies turn their OSS into basically proprietary shared code licenses. And we seem to still pretend its "open source"
"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).
Well, sort of. Open source was just a different name to describe free software, with the purpose of emphasizing the collaboration benefits this gives the business rather than the freedom it gives users. But this "business source" stuff is a different thing which is not open source at all.
No, not really. The first three criteria of the Open Source Definition [0] are essentially freedoms 1–3 of the Free Software Definition [1] and freedom 0 more or less maps to criteria 5 and 6.
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.
You can't interpret things like these out of context.
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.
Yes, basically a marketing campaign. Wikipedia [0] says (in part): "Netscape's act prompted Raymond and others to look into how to bring free software principles and benefits to the commercial-software industry. They concluded that FSF's social activism was not appealing to companies like Netscape, and looked for a way to rebrand the free software movement to emphasize the business potential of the sharing of source code."
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.
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.
"Strict and stable" isn't quite the important feature, its being community-managed. Chaotic projects with lots of forks, and disorganized governance may be a sign that there is a strong community. If the chaos goes on forever, then you're going to probably lose people to the drama (or the forks themselves will eventually stabilize). If the chaos is short, spasmatic, and leads to a better outcome, then it was overall a good thing in the project's governance.
> "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"
In the current market you reliably can do both. Nobody in software can deny the importance of open source software, if only for learning or training. Without FOSS, there would only be stagnation.
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.
> Try to make a living from [...] open source games.
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.
There is a quote: "When you stop growing you start dying" (William S. Burroughs). I am not sure I believe that the kind of governance that Apache is providing is helping to grow the projects under its supervision.
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.
But with software, sometimes there comes a time when it really should stop growing. When any further "enhancements" make the software worse.
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.
Certainly not everyone. Personally, I pay little attention to that sort of thing at all. I don't care if it's a "dead" project or not -- as long as the software is meeting my needs, that's the only thing that matters. If/when it stops doing that, then I'll look for alternatives.
Same here. I run Slackware on all of my engineering and development workstations. It does what I want, nothing gets hosed when running updates, and I don't feel like my main job is sysadmin.
But I keep getting told I need a "Slackware intervention" :P
The move to python 3 helped shake loose a number of text processing bugs with library I work on, that was never caught in python 2 with its loose goosy text type handling.
But as an end user, it's made using applications based on (or even tangentially using, as I learned first-hand a couple of months ago) Python highly problematic due to extreme version incompatibility.
I now try my best to avoid anything that involves Python.
Sorry but that's nonsense. Python 3 has been released in 2008 - 15 years ago. And the last Python 2 version has been EOLed 1.1.2020, three years ago, after a decade of deprecation!
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.
I'm fascinated at your characterization of both Kafka and Spark as being absorbed by Amazon.
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.
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.
It needs at least a stable set of users, but maintaining a set of users is essentially managing the set of people onboarding and the set of people migrating off.
If you're shrinking then a competitor is providing better options, or your problem space has shifted.
Software as big as Open Office may not need to technically grow, but still needs a lot of work to stay current.
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.
There is giant amount of actively worked upon, very heavily used software projects in Apache: Airflow, Spark, Flink, Kafka, Lucene and a lot of foundations on which those are written or use: Parquet, Arrow, Iceberg.
Maybe the real problem is that the ASF has been adopting too many abandoned projects that have been “donated” by much bigger entities (e.g. Google donating Wave).
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.
It's important to note that the ASF did say no to Wave. It never made it out of the Incubator, because it was unable to build an active user community.
And in addition, simply by virtue of going through the Incubator at all, these projects ensure that the source code is available under a well known, well understood, popular, ALv2 license - and the code, email archives, and other artifacts that were created are preserved by the ASF even when the project is sent to the Attic. This is still a net good for the world in general, IMO.
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.
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.