This is why I don't mind using Varnish Enterprise, but I'm reluctant to go all in.

I actually worked for Varnish Software. I know these people personally. I helped hire some of them. I meet them semi-regularly. They are good people.

But if they are acquired by Oracle, it's important for us that the open source Vinyl Cache is still a viable alternative. It's not going to be a drop-in replacement, but it's not going to be a nightmare move either.

That's a pretty OK balance for me.

I don't like that Varnish Enterprise, a proprietary ... version? fork? ... exists. But I'm also one of the people who know best exactly how it came to be, since I was there when it happened.

Ideally I'd like to see Varnish Software focus much more on free software. All these mods that are proprietary seem excessive. The divide makes Varnish or Vinyl Cache adoptions suffer. Nobody benefits from this in the long run.

Rumors are that they are FINALLY getting into the kubernetes space. It's something like 10 years late, but better late than never.

This work, whatever it is, needs to work with Vinyl cache, and should be open source, if we want adoptions of EITHER Vinyl or Varnish to grow.

In 2010, it felt like "everyone" talked about Varnish, now, it feels like something left behind in the past, but the alternatives all suck.

@kly we have this out for ages: https://gitlab.com/uplex/varnish/k8s-ingress

but instead of collaborating, some people decided to rather vibe code something…

@slink and this animosity is both childish, and based on a false history.

Varnish Enterprise happened because the development process was WAY WAY WAY too slow, not for some nefarious commercial reason. And those features were continuously pushed, but not accepted, without any clear path to how to GET them accepted.

And it got worse with the absolute infantile attitude towards TLS.

We used to sandwich Varnish between Apache to get gzip, that got fixed, but now we're back to doing it for TLS?

@kly i agree with the historic view on tls.

i disagree that a closed source fork is necessary to make progress.

and i do not advocate for the sandwich, you will hear about our work in this area later this year (i hope).

@slink Hopefully we can meet up and continue this discussion over a beer or something.

Amedia has done some really advanced stuff with Kubernetes, but unfortuantely, it actually predates ingress controllers somewhat, so while it effectively functions as an ingress controller, picking up application changes automatically from the cluster, it is _very_ Amedia specific.

What I find most sad and alarming is that it seems the Vinyl developer/contributor community isn't growing.

@slink My primary feeling here isn't really "everything with vinyl is bad" or something, so please forgive me if it comes off as overly negative.

I see Varnish/Vinyl as really uniquely useful, but the adoption and spread doesn't reflect this. It felt like it sort of DID in 2012, but finding examples for basically anything leaves you with instructions for nginx and traefik and god only knows, but rarely Varnish/Vinyl.

I mean, you can get by, because you get Fastly-examples...

@kly i agree

we are actively working on changing this, and i would be more than happy if you decided to join us and help. this kind of work only happens because we work hard in the open, while in the past those with the resources decided to go closed.

two examples for new docs: http://vinyl-cache.org/tutorials/index.html

@slink Well, for the last year and a half I've worked in Amedia, who has been using Varnish since version 2.0. We use ESI extensively and rely on varnish for SO much.

I've recently taken it upon myself to start referring to what we've built as the Amedia CDN, since it's so much more than just Varnish and I want to build it into a product.

Part of that, to me, means engaging with the wider community. Including, of course, Vinyl Cache.

The divide between Vinyl and Varnish is a headache though.

@kly we can still collaborate and we do, for example on vsvs, see yesterday's news.

but yes, the way i see it is that we have taken a lot of additional work upon us to change the name, and now i think it's time for some visible work in the open which benefits \( (that is the vinyl cache logo in ascii) and not just some of several downstream forks.