If you start a company and open source your core/clients, your product becomes part of AWS, and AWS runs you into the ground. If you mix in proprietary licenses to protect yourself, AWS forks your core, adds in open-source licensed clients, then runs you into the ground (and you lose open-source contributors/supporters as a bonus who may fork your core themselves).
I remember from a undergrad class reading Google's system design papers, that they publish only the top-level architecture for core systems they use, and only after 3-5 years of use when they have moved on to a better system. After all this (Docker/Redis/Elastic/Nginx), I think that might be the best path forward. You can provide the benefits of open-source and recognition for the architects, but not lose your competitive advantage. Open-sourcing your core product seems too idealistic.
They did open-source HHVM, React, GraphQL, and Cassandra, which are the closest things I can see to a secret sauce.
Running a service on AWS requires two goods. High-margin computing resources that Amazon really wants to sell, and the software to turn those computing resources into solutions to business problems. Solving the business problems has a fixed dollar amount to be split between the two, so the cheaper the software is the more money Amazon's customers can afford to spend on AWS.
So the final equilibrium is that Amazon ends up funding open-source solutions, and profits off it from increased AWS margins.
But they also figured out that making their free-as-in-beer tools also free-as-in-freedom open source, they'd lift all clouds and not just their own.
As the dominant player, Amazon loses from anything that reduces vendor lock-in. That's why precious little of Amazon's cloud tooling is released on Github.
With Kubernetes, Google made the the opposite calculation. As a challenger, it's to Google's benefit to open-source cloud tooling like Kubernetes. Even though their competitors benefit, Google benefits more from standardized tools that reduce switching costs.
It seems not obvious to everyone, but you don't have to use a license, that allows AWS to run you into the ground. Take a look at API Copyleft License: https://github.com/kemitchell/api-copyleft-license
Also, it's not clear this would prevent AWS from running you into the ground. Amazon is more than happy to publish the source code of what they run internally; they make their money off operations and not software, so they're perfectly happy to commoditize software. The copyright holder is the one trying to make an "open core" business. AWS can just reimplement it.
> you must contribute all software that invokes this software's functionality..
So that rules out all proprietary operating systems, databases, 3rd party services, but why stop there? give us your CPU microcode.
Look at Confluent/Kafka. The PMC is stuffed with Confluent employees and they behave that way. They aren't acting like an Apache project, they are only acting in their own self interest. Any new ideas get the run around, and only their ideas see the light of day. I don't even know why they bother being open source, except maybe to get the free development and bug fixes.
If your worst nightmare is that a big company like Amazon uses your software then perhaps your business model wasn't really for the cloud era. Selling licenses is to the VC crowd what sequels are to Hollywood, comfort food that everyone knows how to handle but simultaneously knows isn't going to be the future.
Linux isn't worse off because it is used by AWS and Google. Quite the contrary.
I'm still wary, though. I could imagine if the resultant fines or source code releases from violating a GPL license weren't a strong enough deterrent, you could win by using a GPL-licensed product enough, then parry off attacks from EFF/FSF until you do a complete rewrite of the product underneath, then pay the fine/contribution to EFF/FSF while toppling the original company. If the company is big enough, and can afford enough good lawyers, there may be legal ways to get around laws.
So anyone that refuses to pay for their tools will eventually either loose them, or contend to be happy to use lesser ones.
Open source software is clearly a net positive overall. However is it a net negative for the industry when enterprise developers rely on open source software without demanding their company provides financial support for that software? How is that different than the company relying on free labor from something like unpaid internships?
Where they make open source software for enterprise and provide services to support.
Why?
I don't want to be the subject of a constant dripping of emails, calls, and missings from a sales person who is constant to get their numbers and puts me in their sales automation pipeline.
Give me a ballpark estimate, I can go to whomever is needed, and we can go from there: I've never ran into a case where "I don't know" how much this costs is an appropriate answer to give a manager.
I understand we might be too small to matter for them if we aren't ready to dump thousands of dollars per month into their bankaccount, but it does makes me cautious about what is going to happen with them when their investment money runs out.
It's probably one of the next companies to be acquired in the coming years.
Open source strives where different entities develop the software together to the mutual benefit without a single company trying to push their roadmap, without a single company trying to grab all revenue.
See Linux, see different Apache projects, see PHP etc.
But when such projects take on tens/hundreds of millions of funding, it is inevitable that the technology becomes secondary to paying back the investors 10x, no matter what. Ironically most of that kind of funding seems to go towards sales and marketing rather than R&D. Usually core committers are only a minority of employees in such companies and things get worse when that no longer includes the C-level executives.
This creates a lot of friction when inevitably somebody else undercuts such projects in terms of quality, features or price. This is inevitable because all software eventually becomes a commodity. Your fancy pants DB clustering solution might be shit hot this year but you can bet there will be half a dozen projects imitating what you did within years.
This is basically what is happened to mongodb. It's all about diversifying, "adding value", proprietary extensions, etc. for their paying customers instead of doing what they were good at for all their users. And courtesy of the license, copyright transfers and outside contributions dry up and it's all on the company to do everything in house. Great, as long there's money but when that dries up it creates problems. Meanwhile projects like postgresql and others provide more or less drop in replacements, because they can and because there are users and developers in having that. Apparently they are still doing fine in terms of share price. Best of luck to them but I probably won't be using it.
Most healthy OSS projects out there have licenses that are well understood from a legal point of view and battle-tested in years/decades of use. Some have quirks that need working around (e.g. the classpath exception for GPL v2), others are fine as is (e.g. Apache 2.0). They also have a plurality of copyright holders spread over many companies that makes re-licensing impractical. Most such projects have a core of developers that are typically employed by a big company taking an interest in the project. Having key people in key projects is of strategic importance to them and ensures their interests are taken care off.
The whole point of OSS is commoditization and pooling resources between otherwise less likely to collaborate companies and individuals to get things done better than each of them would be likely to achieve by themselves. That's why most operating systems these days are largely made up of open source software, much of which has had multiple generations of developers working on it. Most of the build tooling around that, same thing. Apple, MS, Google, they all ship mixes of proprietary code and OSS code. Quite a lot of this stuff can be traced back to the early days of unix. Almost every big fortune 500 software company out there pays people to contribute to and represent them in OSS projects that are vital to their business. Even the less popular ones like Oracle actually contribute a lot. That's not charity; it's key to their success.
MS just retired two generations of their in house browser in favor of an open source project primarily backed with Google and with significant portions of Apple contributions from back in the Webkit days. If you'd have to choose two competitors for MS, those would probably be at the top of your list. Why did they do this? Browsers are a commodity and they were negatively differentiating with their in house efforts (as demonstrated by world + dog installing something else). They tried to fix it (Edge) and it didn't work out. All of the surviving browsers are now built around open source projects. I think Edge is probably going down as the last non OSS browser to be widely used.
I use open source components, libraries, and tools for almost everything I do. I love Github. I share code there myself. Most of the stuff I depend on has neither VCs nor much corporate funding behind it and its fine. Some of it does have VC funding and its also fine. My life would be hell if I had to reinvent all those wheels.
I agree funding OSS development is key but I don't agree that that needs to primarily come from companies that own the software and sell licenses+support. That's not how most OSS software I use works; it instead thrives on companies using and paying for people to contribute. Nginx is one of many software packages that I use. I don't think I'll ever pay for licensing or support; because frankly they are relatively unimportant to me. As for the dozens of npm dependencies and their hundreds of transitive dependencies, nope. Not a cent. I would probably consider SAAS solutions when it makes sense; as I have done with e.g. Mariadb and Elasticsearch. But mostly OSS works because it is free as in speech and beer.
In the case of nginx, there are dozens of OSS web servers out there. It's just one of many moving parts I need to worry about. I'll pick whatever is cheap and convenient.
But apparently, Oracle is a bad guy for doing this, and Google is applauded for stealing Java.
Can't have it both ways.
The benefits of FOSS are largely non-monetary. I know as entrepreneurs and professionals that might be a hard line-of-thought to default to, but I think it is extremely short-sighted (and borderline ignorant) to judge the merits of free software by its profitability.
In the world I live in, far more commercially supported open source runs outside of AWS, then runs ON AWS, then AWS has copied and usurped.
As somebody, who has no knowledge about that part of the business (Amazon Web Services in production), could you elaborate on that with a few lines or point me to some articles? Thank you.
A few months ago, AWS launched a MongoDb fork
Isn’t this a great win?
Had all the volunteers' impact being so big? Nginx was created by single developer who is NGINX, Inc CTO now, and then developed pretty much by Nginx employees only.
I don't think there is a future in open source enterprise software where trade secrets are hidden from the public.
I can recommend having a look at https://varnish-cache.org/ - while its performance might not be 100% up to par with nginx in some (very, very high-end) scenarios, it has many other fortes that nginx (at least in its FOSS release version; I've never used nginx plus) just cannot match in my experience. Having seen `varnishlog` and `varnishtest` in action alone are worth spending a day or two exploring it.
I don't have the wherewithal to get at these arguments from any angle (and I'm certain I'm missing many others).
Studious maintenance of the base code and branches/PRs besides build tried/true code bases and I hope that we're not being torn of that practice from this buyout; but only time will tell ...
nginx is fine, but there are now other options that work just as well.
Which only means that NGINX will get even better over time.
What are the contractual consequences if they don't keep that commitment? If the answer is "none", then it's not a commitment.
proxy_pass for example will only resolve a hostname at the time the configuration is parsed, unless you use a convoluted variable hack. This was a serious issue requiring you to restart your fleet if a backend server changed IPs. The bug fix for this was implemented only in Pro and sold as "DNS for Service Discovery."
I'm sure that's not the only feature it's missing compared to nginx. Envoy is not very comparable to nginx, in my opinion... but I also wouldn't reach for varnish as an nginx alternative either.
"There is more to life than increasing its speed."
No. Memory safety is a vanishingly small subset of all bugs and security problems. PHP is memory-safe, for example. Where has that gotten us?
> "There is more to life than increasing its speed."
Not if you're a computer.
1) You can't export and re-import a config. Just doesn't work.
2) For the Virtual Appliance (not a recommended scenario by F5, to be fair) it's temperamental about its host and doesn't like to be migrated or moved, and will stop functioning.
3) Upgrades sometimes corrupt/wipe parts of the config, sometimes not.
4) Reboots sometimes corrupt/wipe parts of the config, and sometimes changes to the config are not actually applied until a reboot, even though there's no warning of this behavior.
5) Latest release notes for 12.x (last version I worked with) has a lengthy page detailing known issues. https://support.f5.com/kb/en-us/products/big-ip_ltm/releasen... Why? Why are there so many? Why are most of them critical? Many just shouldn't make it to release.
-edit- It's important to be hopeful. I'd rather land on the side of "nginx makes F5 better" rather than "F5 makes nginx worse".
4: In over 10 years of using F5 never seen a reboot break a config. The part about needing reboot to make a config change apply might be https://support.f5.com/csp/article/K13253. In short F5 keeps the old config in RAM and applies it to existing connections. when the latter expire, the old config is gone. Can be very annoying indeed when you are not aware of it. You can delete connections manually though. No need for reboot.
3/5: Yes, all their releases have a list of all known issues. It's a bit odd indeed, but I think it's a good thing. Plan your upgrades carefully.
1) You can, if you are careful about what your doing. UCS archives are only intended to be restored on the same machines, restoring them on a different machine requires considering the master key for secret encryption and omitting the license from the UCS. If your restoring it on another model F5, you might be going about things in a sub-optimal way.
2) This typically relates to how stuff like VMWare deals with disk issues or migration. In (some versions) VMWare if there is a disk IO operation thats taking too long, it will pause the VM. It also pauses the VM when you use DRS or live migrate. IF your using a failover pair or cluster this will cause a failover because well, the other device went away for a period of time.
3) Ive only ever seen ASM config lost after an upgrade, and its usually because the unit was not relicensed before upgrading and wasnt licensed for the new version as a result.
4) Ive seen this happen an it was usually because something was in a bad state and rebooting just poked it into failing. Also, always save sys config after making changes in tmsh, it doesnt auto-save (same behavior as Cisco).
5) Because F5 has a policy of publishing a bug in the release notes and in bug tracker if it was ever seen by a customer. Contrast this with some other vendors who very selectively publish bug information.
Besides normal archives (that are just tgz files) or manual config changes and re-loading, try "(tmsh) load sys config merge from-terminal (or file)". It is going to be a gamechanger. ;-) Takes any config snippet from "(tmsh) list..." or the bigip.conf files without rewriting into create/modify statements and add/replace-all-with blocks. No problem to import even large configs like 100KB at once, all as an atomic transaction.
NGinx has had a commercial version of their code for a long time. Now it will be under new management. I could see the branding for the commercial version of nginx change.
That's one of the best parts of OSS code - You don't just have to follow them to the next version they release.
(One example is Tengine - It is really nicely setup and a lot of people prefer it to core nginx already)
Apache is really struggling on resource consumption. It's still living in the world of one process or one thread per connection.
Operationally it always ends up in a clusterfuck of rewrite rules and there are many gotchas with undocumented and misbehaving directives.
Apache has improved and now has things such as Event MPM inspired by nginx. Nowadays most of us would run applications behind a proxy, not by running mod_php or mod_python directly - which made old school apps very slow.
Also Apache is notoriously easy to configure. And Nginx still absolutely rules when delivering static content. There is also Varnish Cache which is very good.
[1] https://help.dreamhost.com/hc/en-us/articles/215945987-Web-s...
It's generally something around 20-50ms extra last time I did some benchmarks
See this benchmark for some inspiration: https://www.techempower.com/benchmarks/#section=data-r17&hw=...
So depending on what you are doing, varnish, lighttpd, apache, or haproxy (and likely more) might be used alone or in combination to match functionality.
Can you explain more? (Serious question, as a long-time httpd user who hasn't used nginx)
It is a very bad choice for critical sites that can't go down.
AWS's application load balancer with SSL is much more reliable.
Interesting to also see what aws is doing in response to some of the more complicated licensing agreements and specifically elastic search: https://aws.amazon.com/blogs/opensource/keeping-open-source-...
The challenge for nginx was they raised VC capital so they were in a forcing function. Either grow revenue or get acquired. Could have remained an independent oss product for ever but alas no more.
https://www.nginx.com/blog/nginx-plus-vs-f5-big-ip-a-price-p...
when visiting Taiwan and then Hong Kong in the late 1990's, a local said "there are no software companies here" .. everything with money had a hardware sale associated, software was just pirated as much as possible, end of story.. no one would pay for software if they did not have to.. It may be a "western" thing to have companies and people that can live from writing only software
What exactly is going on with open source licencing? Is anybody violating open source licences?
https://www.f5.com/company/news/press-releases/f5-acquires-n...
On another note, F5's poorly written code is the reason TLS 1.0 is considered insecure (using a variant of the POODLE attack), among other major security lapses.
Hmmm... like Apache httpd?
nginx is an excellent high performance webserver, which is something F5 don't really have. It is (or was, at least) at best a mediocre load balancer, with all sorts of limitations at the sort of scales you'd usually use an F5 box for. While it's probably fair to wonder how much more work will be put into the LB feature-set of nginx, I hope that this will be counterbalanced by increased funding for the core feature of being a superlative webserver.
NGinx is first and foremost a web server with excellent controls around caching. Haproxy is a load balancer with some caching as of version 1.9. F5 has always provided a web server in their load balancer via apache, but that is for management of the device itself. It can also serve up static web pages (primarily meant for error and landing pages).
In any case, I'm glad that Nginx is still available for free and the project will continue to have funding in the future from what looks like a cashed-up company. Besides, if it doesn't work out, it can always be foked. Hooray for open source software!
To be fair, it might just have to do with our company's implementation, our IT department pretty hit or miss when it comes to implementing new stuff, it only rolled our 6 months ago and we do have 30,000+ employees/contractors so I'd imagine it's headache getting everything just right, but still.
Their main buisness, hardware loadbalancing is rapidly diminishing, so buying in NGINX seems like a sensible move.
After all, its much easier to sell support to people who are actually _using_ your product.
In 2014 we had two, then I moved company to where we had 6 loadbalancers, in the four years we were there we killed them off with a mix of AWS and k8s
At most recent place, I'd no even consider installing them.
Interesting how recently nginx was continuing this campaign. I wonder how effective the "replace F5 with NGINX" marketing push was at increasing the price and urgency for the acquisition.
For the curious, the big headline at the top of the message was "Modernizing Applications by Replacing F5 with NGINX Application Delivery Controller and Signal Sciences"
Then the text of that top section was:
"F5’s rigid and centralized approach to load balancing and web application firewall (WAF) prevents enterprises from modernizing their applications. In this recent webinar we describe how replacing or augmenting your F5 deployment with the NGINX application delivery controller and Signal Sciences WAF helps reduce costs and improve agility."
As an engineer (so I can't speak to business strategy), I always thought of Avi Networks as market validation for ancillary software services like Amplify and Controller rather than a competitor with NGINX+. But that was just my thinking.
BPF allows to run user code in kernel modules, so things like packet rewriting and traffic shaping are possible. [2]
[1]https://news.ycombinator.com/item?id=18337429
[2]https://facebookmicrosites.github.io/bpf/docs/bpf-docs#tools...
People don't buy individual pieces of technology, they want packaged solutions that come with support. Tech almost matters less than good support
Up next is likely HaProxy....
Of course, this also means that you could expect any sort of future development that overlaps with their higher end products to vanish.
The world of economists has no idea how to value technology beyond narrow ad-based business models.
The connection with end users and ideology has been broken as everything from the kernel to major projects are corporate funded and driven.
And most inadvertently acknowledge this when they raise concerns about the sustainability of projects without financial or corporate backing. The exploding complexity of things like browsers and projects like Systemd make the idea of individuals and smalls team developing alternatives without corporate backing a non stater.
Most open source projects in the last 10 years would see this kind of acquisition as an ideal outcome and for vc funded ones a necessary one. Even a 'fork' of Nginx at this time would most likely be driven by commercial motives so the 'vague discomfort' expressed in this comment itself is perhaps misplaced.
I recall my first two F5 box purchases...
Tore it apart with the engineer installing it for us at Decide.com in ~1999 and each box was ~$35,000
After asking about and being shown what the box was, a low end machine with a custom linux distro with a custom LB logic that was complex... I was really turned off by their implementation....
Dont get me wrong, it was revolutionary as a product and what not - but from an engineer, I was kicking myself as to how much they could charge for the thing....
Now ELBs are "free" for same functionality in cloud...
So what is F5 doing - and Who is buying them, aside from governments? (I am not hating on them - trying to understand them)
https://medium.com/runa-capital-collection/nginx-and-runa-st... (from idea in 2002 to exit in 2019)
Let's see what follows.
After reading what they do I am not sure whether I should have heard of them.
