Congrats on this! I noticed though that the license [1] this is provided under puts restrictions on use and therefore wouldn't typically be considered open source, at least as per the commonly regarded open source definition, but maybe instead just "source available".
IANAL but the license (CCL) is quite permissive except for the one use case of building a competing SaaS offering to Confluent [1]; the same type of license most cloud providers are using these days. But source available is definitely a valid term as well. I really do hope people will use this code!
Sure, it is fairly permissive as licenses go but those added restrictions fundamentally make this not open source, the use of this project is no longer fully open for use due to the restrictions you've place upon it.
It might seem overly pedantic, but it can be quite important since many companies try to blur the lines of what open source is for their own benefit. If interested, I go into a little more detail on this here: https://danb.me/blog/posts/why-open-source-term-is-important...
I think this is an overly dogmatic way of looking at Open Source. I think this way of looking at Open Source, and more largely OSI's stances on the term are out of touch with the realities of successful open projects and the challenges their developers face from the current software market and further out of touch with how the term Open Source is colloquially used by a large amount of people.
You should be able to share source, allow individuals to use and modify your work and build a community around that work without worrying that same work will be co-opted by an entity seeking to undermine the effort you and your community have done for years, by slapping a different name on it and hosting it, competing directly against you with your own work as a business.
I'm fine if "Open Source" can't be used to describe these projects which are working with imperfect situations and looking to protect themselves while still providing their software with generally good intentions, but by the same token I then hope the software community will come up with a new good name for these type of projects, it becomes the common name, and the dogmatic definition of "Open Source" fades into the relative obscurity I think it deserves from being so divorced from reality.
I think this is an overly dogmatic way of looking at Open Source.
Open Source is a functional definition that served us for 25 years. E.g. if software is Open Source, it can be included in a Linux distribution. Most distributions do not accept software that is incompatible with the Open Source definition. Diluting the term open source makes it more difficult to talk about a certain class of software licenses.
And why dilute the term if we have the perfect alternative term source available?
Because it is open source. It's not Free Open Source Software (FOSS) as deemed by some foundation or another. There is a lot of great open source software not included in Linux because of licensing issues (e.g. BSD clashing with GPL).
Source available has generally meant you can have the source if you meet some criteria (have a license), but the license prevents you from redistributing it. I haven't dug into this license but it seems less restrictive than the AGPL.
Is it now? I was under the assumption it was an ideological definition, at least that's how people present every time one of these projects are even a smidge off from the OSI definition.
I don't think most major Open Source projects in the last 10 years have even once considered,
'E.g. if software is Open Source, it can be included in a Linux distribution.'
That is exactly what I mean by "out of touch".
If I had to guess the primary motivator for being Open Source, are the communal and moral aspects of it.
> You should be able to share source, allow individuals to use and modify your work and build a community around that work without worrying that same work will be co-opted by an entity seeking to undermine the effort you and your community have done for years, by slapping a different name on it and hosting it, competing directly against you with your own work as a business.
The project in question is a CLI tool to a cloud platform that wraps an open source project (Kafka), complete with a page advertising why to use the wrapped software instead of the open-source version.
Its great that this person can work on a project, and share the source, but if anything, they're literally the ones doing the undermining of a community by re-branding existing OS Software. There's no community to form, no reason to expect anyone to contribute. The only reason anyone would want to modify this codebase is to interact with the centralized service through a different way.
"Source available" is a perfectly valid state, and describes a codebase like this which you can view, and even edit locally. "Open Source" is a term used for years to describe certain freedoms regarding software that has led to the abilities of many software users to modify and use software for whatever purpose they like, like the company in question using Kafka. Using an open-source codebase to make money is not undermining the project, its explicitly allowed in the license. We're all so much better off because open source projects, like Kafka, don't have these controlling and self-serving license.
The "dogmatic definition" of open source is what has been used for decades. Applying it to something that doesn't meet that definition invites confusion.
If a project wants to do something different, and develop an "open project" under some terms that aren't open source, they are free to do so, but they shouldn't call it something it's not.
Sure, I agree. Let's start popularizing other terms, but I think the relevance of the term Open Source will see a substantial decrease then, because I don't think people now largely use the word to mean what it meant decades ago. I think the popularity the term has now is for reasons entirely different, reasons like community building and some reasons of morality, and I think the term can either evolve to fit the industry's current norms or be reduced.
I would assert/guess/think that there are more developers who have started in the last 10-15 years who use the term for its colloquial meaning than there were developers in the entirety of the field in the preceding 50 years. Just from a numbers perspective, if I'm right, the colloquialism is going to win out.
> without worrying that same work will be co-opted by an entity seeking to undermine the effort you and your community have done for years
That literally is the point of open source: that it's not reliant on a single vendor. That's what open source was created for, and that's a big part of why it's thrived.
It's fine to create other structures, but as many have pointed out here, those other structures aren't open source. There are a lot of licenses that allow access to source code (very common in enterprise licenses) but have restrictions on what you can do with that source code.
Companies want the goodwill and community support that being open source provides without the obligations (copyleft with GPL-like licences and the do whatever you want with the code of MIT-like licenses). Defending attempts to redefine open source like this is just carrying water for megacorps.
"entity seeking to undermine the effort you and your community have done for years, by slapping a different name on it and hosting it, competing directly against you with your own work as a business."
The ability to fork was always a core value of Open Source. Especially if there was a community around a project that invested lots of energy into it - and then drama comes. Without forking it means it will always be dependant on the creator. Not the spirit I would like ot get into myself and I also don't like to see those 2 concepts mixed up.
Exactly. Such a definition of open source is hardly universal. I think of it as a sliding scale - to what extent is this open source? Does it allow me to:
* view, download and modify the source code?
* distribute the code as part of another project?
* distribute modified versions of the code?
* do whatever I like with it?
Arguing that unless you meet the OSI definition, you can’t call yourself open source is a little like saying you can’t call a peanut a nut: it all depends on the context of the conversation. At the OSI annual conference, sure this isn’t open source. On a Show HN I’m fine with it being open source.
The software becoming source available is great, but calling it open source is still misleading. Open source implies an expectation that everyone is able to use it without restrictions, possibly on the condition that the derivatives should also remain under the same license.
> the same type of license most cloud providers are using these days
Very few pieces of software are attempting to propagate those non-open licenses; far more software is just using Open Source licenses.
If you want to call it "open source", use an Open Source license. If you don't, please use terms like "making the source available" or similar. (But please, consider just making it Open Source.)
Have you considered using a license like Business Source License (BSL) that would eventually become a true OSI license, like Apache, after a few years?
I think it's valuable for old source available code to not bitrot away when the value of it to the company decreases.
Absolutely, we picked the path-of-least-resistance license for the initial release in order to get the code into the open, but we'll continuously evaluate and see whether switching to a license like BSL makes sense. It's been awesome to see the evolution of licenses in just the past few years, and there are a lot more options than when I started this project. Hoping that having the project public will enable us to build a community and gain continuous feedback that will help drive technical, licensing, and other decisions in the future.
Considering how much Confluent depends on Kafka, maybe you should consider tying a future version to whatever license is used at Kafka, so you can give your users the freedoms that Kafka gave you.
"quite permissive" and "open source" are terms quite far apart.
Open Source software provides certain clear guarantees to the users of that software. Even small changes to these guarantees probably render the software not open source.
This is not pedantic rhetoric, there are clear reasons why open source software should be clearly told apart from proprietary (including source available): given the OSS guarantees, potential users of a given software may make usage / no usage decisions without further due diligence. If those guarantees are modified, due diligence and risk studies may be needed, specially for companies (what if we're not a competitor today but tomorrow we want to? what do you call competitor? etc).
Open Source exists for a reason, which is to provide a firm ground on those who are good with the guarantees it provides.
Agreed. It's important to use the correct terminology. This does not qualify as open source and should be described as source available instead (or should switch to a license which is open source). I've written about this subject in detail here if you're curious about why this is important:
<quote>
There is the free (libre) software movement, and
there is the open source non-movement: two different viewpoints based
on different values.
</quote>
(RMS, from emails)
"open source" is misleading, since it often refers to proprietary software which is just software with open source code, and you can't do much with that source. I would kindly recommend to revisit your vocabulary.
No it isn't. The term "open source" is unpopular with Stallman and his acolytes, but is in common use and has a very clear definition stewarded by the Open Source Institute: https://opensource.org/osd
Whether that term or that definition is or is not aligned with your priorities isn't relevant to the fact that this term is in common use in the IT industry and this definition of it is the most commonly accepted.
In other words, nobody claimed it was free software, and Stallman doesn't get to just "declare" open source to be a non-movement like Michael Scott "declaring" bankruptcy.
I've worked on building Confluent's CLI for the last 4 years, and after a year of technical work, security reviews, and sign-off meetings, I'm excited to share that the whole project (including all dependencies) is now open-source! https://github.com/confluentinc/cli
The CLI is optimized to work with Confluent's on-prem or cloud managed Kafka offerings, but the end goal is to have this be an amazing CLI experience for vanilla Apache Kafka as well. Regardless, there are some interesting bits in the repo (like doing SSO login from a Go terminal app, or mocking API servers for integration tests) that could be useful for other devs out there.
Happy to answer questions on Go, CLIs, Kafka, or how to convince big companies to open source their software. I'm really proud to share all the work with the community and to know that the code will be preserved. Cheers!
Congrats @reducks! Looks like a slick CLI. I assume the CLI has been available prior to now, just behind closed source. Curious on what ended up being the deciding factor that helped bring it to full open source? Or maybe what had been holding the team back previously your team was able to overcome?
Love to see these types of developer tools in the open so great work!
Thanks! We've been shipping the CLI since early 2019 but had a few blockers along the way (alluded to in the blog post). We built the CLI on top of a lot of internal dependencies that were never going to be open-sourced, so we had to do a lot of creation and migration in order to have the CLI only rely on public dependencies (and in other cases, we went through the approval chain to release certain packages like `go-editor` and `go-ps1` into the open). Once we did that, once we cleaned up the codebase, and once we successfully pitched the business case for open-sourcing the tool, we were finally able to flip the switch. It's a small team so there was also always a prioritization question of working on open-sourcing vs. adding new features.
Why didn’t this project use one of the well known and (court) tested open source licenses but instead opted to use Yet Another New License that is not adhering to the Open Source Definition by the OSI? Muddying the waters this way isn’t really helpful from a community perspective, it only serves to help corporate lawyers and makes reuse of code in other projects a legal risk. Le sigh.
Because they like community contributions to their stuff, so "open source" it for that, but don't want their competitors benefiting from the initial work they did. Which I understand.
Kafka was already FOSS, so anyone can vendor it, what Confluent has that gives it an edge is the ecosystem of tools that make Kafka more useful, e.g., Kafka Connect connectors, Schema Registry, kSQL etc.
(Although I'm of the opinion the last one exists mainly to dazzle engineering VPs. The abstraction leaks rather quickly IMO, just using Kafka Streams or Flink from the get go)
When I was at RH, we couldn't ship or bundle or provide any of the above in our FOSS projects, because of that licence, so hey, it was working I guess.
> Because they like community contributions to their stuff, so "open source" it for that, but don't want their competitors benefiting from the initial work they did. Which I understand.
The distinction between competitors and community contributions is false. Why should the publishers be entitled to exclusive monetization of the contributions of their community, and why should their community be denied the right to monetize a product they contributed to? The ability to share the wealth is why the open source movement works.
This approach stems from a position wherein the publishers view themselves as separate and privileged from their community, which is valid if you are the only entity investing in the software, but unjust if the community is an active participant in the software's development.
The mainstream view on OSS is often good for the original publisher, in that an organization which monetizes their software then has access to more resources with which to contribute back to the software -- particularly in the presence of a copyleft license to enforce this behavior. The original publisher is then able to benefit from a larger and more consistent workforce developing the project with them.
I agree with you on that one also (and I see that Confluent has retracted their definition of it as OSS - it's now "source available").
I was just saying that I can understand why they use that licence from a "just IPOed and the MBAs are hungry" POV - it ensures that they're the only managed Kafka vendor that can also provide a managed Kafka Connect / Schema Registry / KSQLdb, it's a significant point of difference in the market, because aside from that, what differentiates Confluent from AWS MSK, or Aiven, or Instaclustr, or RH's managed Kafka etc. etc. etc.
[1]: https://github.com/confluentinc/cli/blob/main/LICENSE