Hacker News Reader

Comment by the_mitsuhiko | Hacker News Reader

> I would have rather see CodeCov stay completely closed than see them pollute and damage the open source community like this.

That seems highly irrational. As of today, CodeCov is scheduled for full, OSI compliant Open Source. In a few years people can fully fork and do what they want with it under the Apache 2 license. How is this not an improvement over closed source CodeCov?

Sure, Apache 2 straight away would be nicer but in practice that’s really impossible to accommodate in a commercial context. The only alternative I know is where you keep the interesting pieces closed (eg: open core).

For most people the BSL restrictions won’t matter and if you find interesting code in Sentry or CodeCov you want under Apache ahead of time, you can always mail us.

View on HN

You should really disclose that you work for Sentry/CodeCov in your comments about this.

Being "scheduled for open source in three years" is not the same as being open source today.

Keep in mind there is a third option- CodeCov could just be honest about what they're doing. They could just say "shared source" or "source available" and take the exact same actions they're taking, just without misleading people.

>Keep in mind there is a third option- CodeCov could just be honest about what they're doing.

They are. In no way was I confused about what they are doing when I read this.

It's practically speaking open source for everybody with a poison pill for companies like AWS that have successfully charged rents on open source without giving anything back (like elastic search).

Restricting the hosting monopolist's freedom in order to fund the development of open source appears to make some people extremely angry.

> Restricting the hosting monopolist's freedom appears to make some people extremely angry.

That's not why anyone is angry. They're angry because it's labeled "Open Source" in the title, and then turns out to be not actually Open Source.

It's the same thing. Theyre angry because they agree with big tech's gatekeeping of open source.

You may think it's purely an apolitical question of definition but it's about as apolitical as saying "Crimea is part of Russia".

No, it literally is not the same thing, and is literally not about big tech at all. It is in fact very simple: Is the thing you're calling Open Source actually Open Source, or is it not? You don't get to change what words mean because you think they should change, or because your business model isn't compatible with their real meaning but you'd really like to use them anyways.

> It's the same thing.

Let's see how committed you are to that stance: just have them change it to the proposed wording. Should be no problem, since it's the same thing, right?

I was assuming that writing “us” would be clear about my association.

From where I’m standing there is a massive difference between “source available” and BSL with Apache 2. The latter does not require goodwill from us in the future.

Most good-faith commenters put clear statements about their association to what they're defending. Not doing so immediately makes me suspicious.

Can I suggest calling it "Eventually-Open Source Software"?

> Software that has source code available that automatically becomes open source at some explicitly specified, unchangeable, point in the future.

> Can I suggest calling it "Eventually-Open Source Software"?

FWIW that's what I call it, but that's not exactly a well known enough term.

Eventually open explains itself. And makes anyone not sure what it means aware to find out. It is superior entirely to lying.

> As of today, CodeCov is scheduled for full, OSI compliant Open Source.

Then title the blog post, "CodeCov will eventually be Open Source" instead of being deceptive.

> Sure, Apache 2 straight away would be nicer but in practice that’s really impossible to accommodate in a commercial context. The only alternative I know is where you keep the interesting pieces closed (eg: open core).

"impossible", huh? Wow, that must make Zulip the company really mad to hear they're going to close up shop tomorrow morning, and those GitLab folks are never going to go public </snark>

I mention GitLab as a nod to your open core comment because the MIT product they ship provides real value, as does their very real hosted offering

Everything is always fine until someone comes along and starts selling hosting of Open Source SaaS projects. I cannot talk for Zulip and I truly hope they will succeed with not relicensing or closing part of the software.

This strawman argument gets trotted out every time and every instance that I've heard thus far is exactly that. It's the "otherwise the terrorists win" of my profession

Ordinarily I would have gladly used Sentry's community and my good experience with its hosting and customer service as rebuttals but now ...

At one point Sentry was packaged with GitLab and bundled as a capability/extension of the GitLab suite of products (see "Error Tracking"): https://gitlab.com/gitlab-org/gitlab/-/issues/39701

You are misinformed; they implemented a Sentry-compatible endpoint if the Project enabled it: https://gitlab.com/gitlab-org/gitlab/-/blob/v15.0.0-ee/lib/a...

I feel perhaps you meant to link to https://gitlab.com/gitlab-org/gitlab/-/issues/329596 which describes their intention to accept Sentry formatted JSON payloads and store them in their own database. Searching for "no need" in that issue will highlight the number of times they were drawing a distinction between the effort required to run GitLab and the effort to run the 15 containers of Sentry self-hosted

Do you disagree the Apache licensed version of Sentry doesn’t provide real value?

What about all the supporting tech that we have released as MIT, BSD, or Apache?

All of that is funded by our ability to stop companies like your beloved GitLab from being the ones who commercialize the other parts. Our goal is not to argue about proper nouns, but to maintain the spirit of open source, and to do that we need to move the conversation forward.

GitLab is a good example of not actually opensource. They are open corse which is much worse than BSL. There are tons of features they don't allow you to use even if you self-host unless you purchase a license.

BSL lets you use all features and self-host as long as you aren't a reseller. It is the best model I've seen.

I would enjoy seeing the specific features of the MIT codebase that they "don't allow" you to use

All the features they exclude from the MIT code base and only include in the The GitLab Enterprise Edition...

https://about.gitlab.com/pricing/#compare-options

There is a box for "Open Source - MIT License". You'll notice most of the features are not covered under it.

> All the features they exclude from the MIT code base and only include in the The GitLab Enterprise Edition...

> > I would enjoy seeing the specific features of the MIT codebase that they "don't allow" you to use

I feel we are not on the same page. But, good luck with your BSL future

What do you mean we aren't on the same page? These are two options when opensourcing things:

- GitLab went with Open Core and kept most of their features closed source and not available to the community

- Companies that choose BSL provide all their features to the community both from a source available standpoint AND a usage standpoint.

In my opinion BSL is a MUCH better place to be in than the open core model.

I agree with you.

If the choice is Open-Core vs Non OSI Approved License(tm) Open-Source, I definitely support the latter.

The OSI needs to be honest and push "OSI Approved Licenses(tm)"... Instead they're like the Simpson's Old Man Yells at Cloud meme, trying to pretend their special interest group has a trademark on "open-source"

https://knowyourmeme.com/memes/old-man-yells-at-cloud

Even though they admit that trademark was denied

https://opensource.org/pressreleases/certified-open-source.p...

In a commercial context, was this planned or some last ditch effort to get more users/usage?

Planned - this is how we operate at Sentry, it just took us a bit of time to get it ready to release

We generally Open Source our stuff. When we acquired specto for profiling all the stuff was opened up as well either under Open Source straight away for SDKs and supporting infrastructure or time locked under the BSL.

Reply on news.ycombinator.com