Hacker News new | past | comments | ask | show | jobs | submit login

So...what is the future of enterprise open source? Is there a future for enterprise open source?

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.

My understanding is that Google has recently deviated from this strategy. The result of the strategy you mention is that the industry standardized on other companies' implementation of ideas that came from Google: Hadoop (MapReduce), HDFS (GFS), ZooKeeper (Chubby, and more. For examples of newer open source projects that see more active maintenance from Google, see Kubernetes and TensorFlow.

But K8s is not a development of Google software. It is developed specifically for the public, it throws out all of the interesting parts of Borg, and Google themselves don't use it, or barely do. As for that other stuff it seems to have worked out fine for Google: they describe obsolete technologies and the outside world develops hideous analogs of those and uses them for decades. Hadoop for example is just an unbelievably bad implementation of map reduce as it was ten years ago and is laughable compared to what Google replaced it with. HDFS is a joke of GFS which Google turned off eight years back. It's really remarkable the way the industry is essentially self-disabling in this regard. Meanwhile Google does not burden itself with trying to adopt every idea they read in a paper, and maintain a significant cost and efficiency advantage by doing so.

> it throws out all of the interesting parts of Borg

This is not true. It throws out the Google-specific parts of Borg (like integration with Google's service discovery, load balancing, and monitoring systems) and improves a number of things compared to Borg. For a good reference on the evolution of Borg into Kubernetes, I recommend the recent Kubernetes Podcast interview with Brian Grant: https://kubernetespodcast.com/episode/043-borg-omega-kuberne...

> Google themselves don't use it

This is not true, and the reasons why it hasn't replaced Borg are related to the integrations I mentioned above (which will take time to integrate or replace) and the zillions of lines of borg config that have built up over the years, rather than concerns that people outside of Google would have (production-worthiness, reliability, etc.)

(Disclaimer: I worked on Borg at Google, and now work on Kubernetes at Google.)

Unfortunately we can't discuss the parts of Google's platform that aren't in Kubernetes on this forum. If we could, I think I could defend my statement reasonably well. But perhaps you just don't think that the pieces I would mention qualify as interesting.

go/-link or it didn't happen.

well my secret document says you're wrong and i'm right.


Partial information is better than none.

aphorism rejoinder:

disinformation is worse than no information.

Implementation matters to google, more than to say the average company that uses Hadoop. At "Google-scale" small imperfections become huge imperfections.

What's good for the bottom 90% of tech companies probably isn't for the top 10%.

I am a consultant working on Hadoop installations across the globe. As an average I usually able to save 70% disk usage and 30% overall cost by changing the defaults to a reasonable value as well as migrating companies out of HDFS to something like S3. I have spent majority of my career (10 years) working on Hadoop and I can tell you that it is a terrible piece of software with insane ineffciency all over the place. If you would switch over all the Hadoop installations on Earth at once to something more reasonable it would be visible on the global CO2 production chart quite a bit. What is good for the bottom 90% of companies is a financial question not a technological question. It is a bit unfurtunate that Hadoop is so popular and nobody cares about efficiency, not even the Hadoop vendors (maybe with the exception of MapR, which is not opensource).

> This find | xargs mawk | mawk pipeline gets us down to a runtime of about 12 seconds, or about 270MB/sec, which is around 235 times faster than the Hadoop implementation.


Well this is great until you need more nodes. :) I am talking about the same scalability while maintaining a much lower ecological and financial footprint.

Using hadoop/spark for <2gb of data seems like a terrible idea.

When all you have is a hammer everything starts to look like a nail.

Is there a good open source alternative that meets the HDFS use-case (i.e. file or blob storage, rather than a KV store designed for point lookups)? Or is tuning the HDFS defaults the best you can do without migrating onto someone's cloud platform?

I'd argue Kubernetes isn't the best choice for the bottom 90%. There's a lot of companies you could describe as tech and many are doing just fine in the old world of manual application provisioning.

I don't agree at all. While the large majority does not need the scalability it offers, it can benefit from all the other stuff applying the 'best practices' offers. The problem is - that many people do not stick to the best practices and do not know how to build containerised applications.

Implementing the whole "DevOps" idea just becomes a whole lot easier when developers don't even have the concept of their snowflake server anymore. And yes - k8s has a ton of overhead and is pretty complex to get into at first, but it all makes sense. There are many points that could be criticised about it, it's far from perfect, but having a standardised way of deploying whatever application has been a massive game changer in the development environments I've been thrown in.

Source/disclaimer: I'm a consultant that has seen quite a few k8s/openshift fuckups and success stories, both on large and small scale.

>I'd argue Kubernetes isn't the best choice for the bottom 90%.

Exactly. Instead of having something so simple that scales for 90% of everyone's needs. We have solution that Most enterprise wants and filter down from top to bottom. And it is true in almost all Tech things related.

Google offers their most recent infrastructure as a service in GCP, e.g. Cloud Dataflow, and it hasn't exactly taken the world by storm. Industry standards matter, even if they are inferior implementations; the differential is just not that big.

Dataflow is based on oss Apache airflow. I don’t know how well it’s doing in the wild but every IT admin I’ve worked with are super excited to use it.

Airflow and Dataflow are not related.

Google open sourced dataflow as Beam - https://beam.apache.org

Dataflow it's self isn't open source. Beam is not open source Dataflow, however you can use the Beam SDK with Dataflow as a runner.

Ah, apologies, my bad.

Can you mention some of the interesting parts of Borg that are missing in k8s?

among other things, I miss Autopilot and generally the extensive machinery to help with massive capacity planning.

Think of Autopilot as an automation that tweaks a pod's request/limits according to what it actually needs in order to reduce waste and thus improve cluster utilization.

(I _think_ this no longer qualifies as secret after https://github.com/kubernetes/kubernetes/issues/44095)

That said, k8s is quite extensible and it would definitely be possible to add such a component as a controller.

Well, nobody should be using MapReduce now, and HDFS now is a lot better than 8 years ago.

Without Google using, validating and releasing those design, we might be stuck with MPI and NFS for a lot longer.

How many GMM can MapReduce do? What about lattice quantum chronodynamics performance? MPI and Lustre exist for a reason: map reduce isn't great for all problems.

MR never claimed to be great for all problems. It main selling points was big-data and easy-of-use.

Sure, MPI might blow MR out of the water in term of number-crunching, but it is also way harder to use.

I know some people who develop on top of Tensorflow; from my conversations with them, Tensorflow's moat is Google making a lot of breaking changes by incorporating a lot of new functionality. I've also heard complaints that the online documentation isn't terribly great for triaging not-happy paths, to the point where you kind of have to just dig through the source code to figure out what's going on. Also, if you want to poach the maintainers, you would somehow have to poach them away from Google (which isn't happening, since ML at scale is something Google does best, and is an ongoing field of research). You can't become as good at using Tensorflow as Google is by simply forking the project.

Does that deviation lineup with Google's entry into offering cloud computing?

Pretty much. That's when it became clear that Google would have to support whatever is popular outside Google.

Gonna just chime in and mention Yahoo for Hadoop (yes I know Big Table was Google), and Zookeeper. Great tech started at Yahoo, but they didn’t (unlike today) make too much of a fuss/self-pat-on-the-back about it

Those projects were initiated by Yahoo, but the designs are taken directly from Google papers. Hadoop (HDFS and Map/Reduce) was based on the GFS and Map/Reduce papers. ZooKeeper was based on the Chubby paper.

Note that none of the successful large companies are actually open sourcing their 'secret sauce'. There is no open source version of Google's search engine, Facebook's social network etc. It's only supporting tools and infrastructure they release (i.e. commoditization of their complements or dependencies.) A product company open sourcing their core product is committing suicide on the product front. Sure, there will be services companies who may benefit (Red Hat or providers like AWS etc.) but the company that actually produces the software rarely will.

I don't think Facebook has any "secret sauce". The integration and scale is certainly impressive, but there's no part of the functionality which is at all mysterious to me. Unlike, say, Google Search, everything on Facebook appears pretty straightforward.

They did open-source HHVM, React, GraphQL, and Cassandra, which are the closest things I can see to a secret sauce.

Their ad-targeting infrastructure likely has some secret subtleties to it.

Meh, not really. Cookies all the way down.

They can and do jump the incognito mode regarding ad cimplaints. I have proof.

You’ll be surprised how many ways there are to track you even in Incognito

nah... after working in Internet Marketing I am convinced the only way to not be tracked is to simply not use any device or credit card.

That situation is so rare someone meeting those criteria could be tracked by the lack of that data

Other companies do this too, so it doesn’t qualify as secret sauce.

These comments so much remind me of the infamous Dropbox comment when they launched: https://news.ycombinator.com/item?id=9224

Well, looks like you just have to assemble known parts in specific order to make something users like.

To expand on this, these companies are not open sourcing their data. Facebook no longer gives you access to the social graph. Google doesnt have an open API for their search results or search volume.

Providing an API doesn't mean open sourcing the data. Because the API provider can very well restrict who can use it, and how it is used, and throttle it.

There absolutely is a future for enterprise open source. It's not through direct monetization, but rather driving down the price of complements for existing product lines.

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.

Amazon figured this out and surrounded their high-margin computing resources with a dizzying array of free-as-in-beer tools.

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.

This! Kubernetes in some ways was a shot in AWS’s direction. It gives companies a reason to switch to Google. GKE is still far more stable and mature than EKS.

AWS still beats gcp in most other ways though (imho), so it’s far from a slam dunk. But it has opened up a door for Google.

Interesting read on this topic by Stratechery - https://stratechery.com/2016/how-google-cloud-platform-is-ch...

> If you start a company and open source your core/clients, your product becomes part of AWS

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

This is not a FOSS license in the sense of the Debian Free Software Guidelines or Open Source Definition: it compels you to publish your changes, even if you're only making internal use. Free software / open source licenses do not require that. Most obviously, it fails the "desert island" and "dissident" tests of https://people.debian.org/~bap/dfsg-faq.html . (There are plenty of perfectly fine licenses that are not DFSG/OSD licenses, but it's not what most people mean by "open source," and importantly it will be impossible to get this software into a mainstream Linux distro, so you won't have the sort of adoption that actual open source licenses get you.)

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.

Oh boy, just skimming through that license and I can see a bunch of lawyers having a good giggle and a field day over 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.

Enterprise open source is bleak. There aren't very many enterprise open source projects with pure intent anymore, they are all looking for the big payday, which unfortunately companies like Google and Facebook have encouraged.

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.

Obviously open source isn't going away. It's just that VC struggles to understand the implications, still, and the past half a decade has been imprinted deeply by all the cheap money.

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 agree. Open Source software is not a good way to build a moat, and investors should take this into account. It's good for companies that focus on building employees, teams, and customer relationships, and keeping them strong at all times. They can't fall back on exclusivity of their code, hosting, or support offerings. The ideal Open Source company would probably be something like Red Hat.

You could AGPL and sell proprietary exceptions. Amazon won't touch AGPL code.

Others are happy to provide AGPLv3 code as SaaS, look at MongoDB's issues. You can build a ton of tooling around said code to enhance performance, adding features and billing, all while not modifying the core AGPLv3 code and thus avoiding the need to contribute back. This is a scummy business practice, but technically legal.

Why is it a scummy business practice?

Because your core business feature is done by someone else and you just take it and use it for your own profit without giving anything back. Do you need a definition of what scummy means?

No need to be rude. I know what scummy means. It's just not clear to me why this is considered scummy. Anyone is welcome to take the open source and benefit from it as long as they comply with the license. This is a very fundamental aspect of open source.

A company invests money and engineers in building commercial tooling, which you then pay for because there is added value. You are not paying for the open source - which is freely available. How is that scummy?

I apologize for the brash response.

The "comply with the license" part is the problem you're not seeing, using open source as SaaS is a loophole not a license feature.

An example being, I license something as open source which means if you don't pay for it (assuming there's an option for that), you are bound to follow the license I provided which means all further work has to be open source (the same license I used) and source has to be provided with the product. In an ideal world this would mean either:

1. We both get paid

2. We both contribute to open software which is available to anyone

But in our world it means, technically I'm not selling software but a service so I don't have to do shit. so the result (with scummy companies) is the following:

1. I don't get paid for software critical to your business

2. No one gets the benefit of the new product created despite my license

Hence, scum.

> technically I'm not selling software but a service so I don't have to do shit.

This is entirely untrue. If it were the case that 'I don't have to do shit', then why doesn't someone else do it too? Running a service takes a WHOLE LOT of work, and writing the software is, in many cases, the easy part.

We know this is true because whenever there is a conflict with a software license, the big cloud vendors just re-write it themselves.

Using someone else's work and making money on it without contributing anything back (code, funding) is morally wrong.

So there's "Server Side Public License" based on GPL.

Maybe. At least our company won't touch GPL code; as one colleague described to me, if you violate a proprietary license, a company will come after you for money, while violating a GPL license gets the EFF involved who will come after you for your source code.

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.


(Usually not the EFF; more likely Software Freedom Conservancy or someone. EFF is more digital rights and privacy stuff, not copyright.)

A copyright holder can't get anything more from you by using the GPL. Infringement is infringement. The difference is that a company is usually happy to settle in exchange for a properly paid license, and an open source hacker instead is happy to settle in exchange for complying with the license. You're always free to take it to court and pay the damages from infringement, but you're not going to end up with a valid license in either case, so you'll have to stop distributing the software.

The actual difference, probably, is that you're a (moral) competitor of the open source hacker, and if you're not a competitor of the proprietary company, they have no interest in undermining the secrecy of your code or causing you to go out of business, even if the could potentially force that if they went to court. They're likely to consider "pay us a percentage of revenues" as a win condition.

Also, lawyers are not like Pokemon. You cannot beat the opposing team's lawyers by having more stronger lawyers. You can certainly lose by having bad lawyers, but you can only be guaranteed to win by being in the right.

You can't actually be guaranteed to win by being in the right. You can be in the right and lose.

>> Also, lawyers are not like Pokemon. You cannot beat the opposing team's lawyers by having more stronger lawyers. You can certainly lose by having bad lawyers, but you can only be guaranteed to win by being in the right.

> You can't actually be guaranteed to win by being in the right. You can be in the right and lose.

What he's obviously saying is that there is a seriously decreasing marginal benefit to more expensive (and presumably competent) lawyers.

It's better to have competent lawyers and be right than have amazing lawyers and be wrong.

Obviously there are shades of grey, nuisance lawsuits are a thing, etc.

Well his intention is clear. But stating you are guaranteed to win if you are in the right strikes me as naive at best and woefully neglectful of reality at worst.

It's probably best stated like "lawyers are not _always_ like Pokemon". Sometimes they very definitely are.

Yeah, my phrasing was sloppy: you're not guaranteed to win whenever you're in the right. But being in the right is a precondition of being guaranteed to win (along with having competent lawyers, a competent judge, etc.).

The only claimants to your source code are those to whom you've distributed binaries built from GPL sources. Anyone else can pound sand.

If you were the author of a GPL piece of code whose licence was violated, and the EFF came to you and said "we'll pay for the lawyers and in exchange we get publicity", most people would say yes.

not the case for AGPL: then it's everyone who has access to your online service built with the code.

I don't think it works like that.

This is a copyright license at its heart. It is a contract between the copyright-owner and the service owner. The end user is just 3rd party.

Wait, isn't the whole point of AGPL that the "user" entitled to the source code is now the service user, i.e. potentially everyone?

That's true, but GGP comment mentioned AGPL presumably for a reason :)

You actually can't magically lose your rights to code you created. You could rewrite your code so it doesn't depend on gpl code if you found you had included code you had no right to.

I mean if you're planning to violate the license then does it really matter what the license is? Your company sounds shady if you evaluate software icenses based upon how much it will hurt when you violate them.

There's a difference between "planning to violate the license" and worrying about what happens if you do because someone didn't pay attention.

Well, most enterprises wouldn't: https://blog.dgraph.io/post/relicensing-dgraph/

Has the AGPL ever successfully held up in court?

Yes, Artifex sued Hancom over their use of Ghostscript [1]. (The article says GPL, but Ghostscript has an AGPL license.) The judge denied a motion to dismiss the claims, and they reached a settlement for an undisclosed amount.

I don't think many developers are aware that Ghostscript has an AGPL license, and I've heard that the commercial license costs $25k per year. It's very easy to just `apt-get install ghostscript` when you want to work with PDFs (e.g. with imagemagick), but this violates the AGPL license when you are running a SaaS application.

There are some permissively-licensed libraries (Apache 2.0) that provide similar functionality, such as PDFBox [2], or PDF.js + Node.js.

[1] https://www.fsf.org/blogs/licensing/update-on-artifex-v-hanc...

[2] https://pdfbox.apache.org/

[3] https://mozilla.github.io/pdf.js/

$25k seems a bit on the high end - https://ironpdf.com/licensing/

Also, it's 2019 - Artifex, it's OK, you can publish your prices (https://www.artifex.com/licensing/)

> but this violates the AGPL license when you are running a SaaS application

Only if you modify the Ghostscript source code.

From what I was reading, I think your interpretation might have been the intention of the people who wrote the AGPL license.

But I also know that the AGPL license is usually adopted because they want to sell a commercial license, even if the source has not been modified. Artifex is very explicit about their intention on the licensing page of their website.

It depends on the definition of “modification” and “derivative work”. Artifex is adamant that any software using Ghostscript is a derivative work, and the copyleft will apply, so all of your source code must also be released under the AGPL license. This is especially true if your software cannot function without Ghostscript.

If you are only distributing your application (i.e. not a SaaS app), then you could make Ghostscript an optional plugin that people can manually install (like LAME for Audacity.) But a SaaS app provides access to the application over the network, so you cannot use Ghostscript without a commercial license, or without releasing your application’s source code.

I didn’t see anything about Hancom modifying the Ghostscript source. It was the fact that they distributed Ghostscript along with their own application, and their application depended on Ghostscript for some functionality. That was enough to trigger the GPL copyleft, so they were violating the terms of the license and had to settle out of court. The AGPL means that you would be violating the license by providing access to your app over a network.

Surely it doesn't need to—either you accept the license or you don't accept the license. If you don't accept the license, you can't use the software.

I'd imagine that the challenge with the AGPL is catching and suing the non-compliant services.

If the source is available, I absolutely can use the software—regardless of license. The only thing preventing me from doing so would be either criminal or civil law, and while IANAL, I don’t believe there are criminal penalties for license violations. The copyright holder would have to sue me, and prove that I violated the license, and then they might be able to get a court to force me to stop, pay them, or both.

I am curious whether there are any practical observations, one way or the other, about the AGPL’s enforceability.

Obviously you can use the software. Of course you'll probably get away with a license violation if you're not shouty about it. Similarly, I can use a pirated copy of Windows XP too, with effectively zero risk of getting caught.

Nobody is suggesting that an AGPL licence violation would result in a criminal penalty, but if you got caught you may be forced to release any changes you made to the source code. And you could lose the ability to use the software in future—if your business relied on it you might be screwed.

Personally I think the AGPL is stupid, but people are free to pick whatever license terms they like for their copyrighted works. Whether I like it or not is irrelevant.

The way you get forced is by someone filing a civil suit. My question was has anyone done that and been successful. It looks like the answer is yes, although it was settled out of court and not adjudicated. I am curious if a judge has ever found the AGPL to be a valid license constraint.

Personally, I find “you are licensed to use the software without releasing your modifications on your internet connected computer, however if you open a port and offer it as a service, you are not” to be entirely ridiculous. It seems to me that a license can’t (or at least shouldn’t) hinge on what other software I am or am not running on my computer (eg a webserver).

That is why I asked. I’m all for copyleft (despite the fact that its validity hinges on an inherent affirmation of the validity of the concept of intellectual property), but I passionately hate the AGPL because I think it is an unjust infringement upon my freedom as a user. It’s like saying “you have a license to use this software as long as you don’t run a browser that accesses porn on the same machine”. I think it oversteps the boundaries of copyright-as-designed.

agpl will not save you if they choose to re-implement the solution.

Nor will anything else, I reckon.

That's basically how the first GPL software came into being -- as a (partial) reimplementation of commercially licensed unix.

keeping the system proprietary will make it harder for them to understand what you are doing; but that will also be very limiting move - in the enterprise software space.

But will anyone else?

What happened is the realisation that FOSS developers also have to pay their bills and idealism only takes so far.

So anyone that refuses to pay for their tools will eventually either loose them, or contend to be happy to use lesser ones.

“Loose” is the opposite of “tight,” “lose” is the opposite of “find.” Easy to remember because the opposites have the same number of letters.

It always amazes me how often I see this spelling error.

Given that lose is pronounced looze and loose is pronounced looce I can see why it’s confusing.

I learned how to spell it in early grade school--maybe eight years old--so I don't understand what's confusing about it but I'm an educated man.

Maybe because not everyone is a native speaker that learnt how to spell it properly at eight years old.

It's confusing if you try to apply phonetics or any kind of logic to it, as an ESL person might, or many native speakers for that matter.

It is certainly not confusing it you learn it by rote and remember the rule. It is burned into my brain, but I see the mistake a lot so I assume it is hard to remember for some people. For me its vs. it's is something I still have to keep looking up.

Let's not let the minority become the rule. I have only had one person ever come back to me claiming they were a non-native English speaker when having made the mistake over many years of correcting people.

then maybe you should learn that a lot of HN readers are not native English speakers.

None of the people I've encountered--save one--ever came back to me saying they were not.

Very impressive...

In fairness it feels rather arbitrary and counterintuitive of a spelling rule.

Thank you for this public service.


What is interesting is that we are seeing people in other industries shamed for hiring people in unpaid or underpaid jobs and even people shamed for taking those jobs. I wonder if that is something that will ever happen in the software industry.

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?

I think a lot of it truly is passion. Interns have goals that typically don't align with the company they go to work for. That's why they take crap pay. They get to not care and in return the company doesn't have to care about them! Everybody wins, and it's a choice all around. So it's mutually agreeable that the intern will put in some effort and get some reward.

Speaking for my own open source projects; There are already better, cheaper, and easier alternatives to my software. I'm already paying out the ass for something I could just download. I'm doing it for reasons that I can't, or won't, buy. And I know that sounds cliche because it is cliche, but passion is cliche.

We're programmers and hackers here. Just like a hot rod enthusiast spends $200k and 3 years building a car he could buy in a catalogue for $75k; we don't pay as much attention to cost/benefit relationships as we'd like to think.

How is having a passion for a particular piece of software different than having a passion for a specific job or company? Plenty of people have enough passion for an internship that they are willing to take it for free. However society has been discouraging that over recent years because that route is only available to people who have outside financial support and it can easily be abused by employers. Open source software has the same potential drawbacks.

Not every piece of open source software is diminishing the value of enterprise software developers just like not every unpaid internship is reducing the value of entry level labor, however both systems can easily (and even unintentionally) be abused by businesses.

The interns' goal is to learn the trade. The companies goal is to attract talent and/or get a ROI.

In my company an intern conducted research on scalability - creating tools to measure and monitor the software in the mean time. So not only does the company have some neat monitoring tools now, the intern actually found a bottleneck and improved the product. The company is now offering her a contract...

Caring about eachother doesn't have much to do with it.

Exactly right. Its amazing thing in software industry that developers want to be highly paid themselves along with free work from other software developers.

I guess it's the "eat or be eaten" attitude. Give someone a chicken that hatch golden eggs, and they will kill the chicken.

I think Hashicorp[0] has nailed down the open source enterprise model perfectly.

Where they make open source software for enterprise and provide services to support.

[0]: https://www.hashicorp.com

I love Hashicorp products, however, all of their pricing behind "Contact Sales" is a major turn off.


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 agree, but since so many companies still do this, the math must work out such that having sales staff work out the prices results in higher profits even including lost sales to people like yourself who won't jump through the hoops.

The polar opposite of this would be Atlassian, who publishes every price and doesn't negotiate at all. At least it's easy to deal with...

> Atlassian [...] doesn't negotiate at all.

Untrue if you license multiple products from them at scale.

It is quite hard to A/B test. And the sales people making the bonus is often part of setting the strategy.

> since so many companies still do this, the math must work out

survivorship bias

"How much is it?"

"How much you got?"

Pretty much this. Not Hashicorp, but another vendor I was speaking to initial gave me a $10,000 a month quote that we got knocked down to $500 a month after some negotiating.

This has been my experience with I'd say 80% of the "Enterprise SAAS" outfits I've interacted with.

Was it Confluent?

It’s likely because they give different pricing based on who’s asking, which is normal for products that aren’t commodities.

Have to agree with you. At least their site says "Get Pricing" vs just "Pricing" and it says "Contact Us".

Hashicorp is one of those companies I want to support, but all of their pricing and enterprise details are behind a "Contact sales" button, so it is really hard to get to know their offerings and their pricing.

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.

I really dislike when companies don't put pricing on their website. 1. I need to spend hours or days just to understand if I should consider it or walk away 2. Feels like they may give different price to different customers and we have to negotiate price like on asian market 3. If price is kept in secret who know what else is hidden from us

They barely have any revenue and they're struggling.

It's probably one of the next companies to be acquired in the coming years.

I'm one of the founders of HashiCorp. We don't publicly talk about exact numbers, but we broke through 9-figures last year, and a very low % of that is support (its mostly enterprise software). That also isn't using any accounting tricks (such as a ton of multi-year deals). We're doing very well. We're in no talks to be acquired, either.

I can't prove any of this, you'd have to take my word for it! I guess if we ever go public in N years (not saying we are, but _if_), you'll see for yourself on historical results. :)

Congrats on the success! Given your enterprise traction, though, how do you guys intend to avoid the problem Elastic is facing from AWS?

Fantastic to hear you’re still crushing it.

HashiCorp is doing VERY well revenue-wise. They are not struggling. Where did you hear they are struggling?

(I have no affiliation with HashiCorp.)

Instead of taking either of your words for it, are there any actual direct sources on Hashicorp's earnings?

The only source I found was https://www.hashicorp.com/blog/2017-year-in-review which just says the company "can be successful", not that it is making money.


From Mitchell himself - at the very least they are growing very quickly. For all the complaining about "pricing pages", I think hashicorp is doing the right thing. Focus on selling to the big dogs who can give you a sustainable business and don't cloud your pipeline with smaller shops who wish to shop around.

Hashi should honestly set up a donations page, we'd love to throw them some money because we use their entire suite, but the pricing is clearly geared towards whales.

Do you have inside knowledge of this? I wouldn't be surprised; open-source enterprise software is incredibly hard, but Terraform Enterprise for example is a really solid offering and not to expensive. It is actually very doable even for small (< 5 people) startups.

I have always wondered what this enterprise support means? So if a big company starts using vagrant, they would dole out 100k for a support contract? I find this hard to believe but what do I know.

You would be amazed at the spread between big companies who decide "we won't pay $20 for support for something critical!" and other companies who decide "OMG, we can't run /bin/bash without a support contract and someone to yell at if it goes wrong!"

My enterprise company wont even get us Postman Premium to the tune of ~$150 per seat per year...

So here we are slacking postman collections back and forth on our current year mac books.

Did you consider to create testing app to simulate customer experience? I can be a single html+js file in a git, for each major feature

When developing an open source product and trying to do a business around this is a tough ride, as competitors who do less development can do services cheaper.

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.

I'd say this is more of a problem with VC funded OSS companies treating a commodity as an investment that needs to be milked where a few individuals working efficiently might otherwise be able to make a very comfortable living doing e.g. support and consulting. Many smaller projects are surviving just fine like this.

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.

Yeah, it's almost as if it makes sense to copyright the API to prevent unlicensed usage of decade long investments.

But apparently, Oracle is a bad guy for doing this, and Google is applauded for stealing Java.

Can't have it both ways.

Gitlab and Hashicorp are going pretty strong. Maybe they get acquired though.

I think the issue here is that you're viewing the merit of open-source entirely based on the immediate profitability of the software.

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.

This is incredibly deft on F5's part. What are the alternatives to F5's products? Cloud products, and home rolled Nginx configs.

I imagine haproxy might get more popular if F5 does anything to hobble the open source part of nginx.

haproxy is amazingly functional and has done a fine job of evolving over the years. At a particular $DEFUNCTCLOUDVENDOR we implemented a haproxy based ELB-ish solution with home grown control logic to replace a F5 installation whos configuration size grew unwieldy (the F5 config parser was falling over in their LBs) while we were nowhere near the F5's touted connection/throughput numbers. F5 wasn't really willing to work with us on licensing, so we implemented a system based on haproxy VMs that worked because we were more than a bit overprovisioned on switching capacity and were able to shard that configuration base more effectively over more VMs.

This was 2011, so I'd hope newer F5 gear has gotten past that.

18 months ago I was in a shop that used F5 and it was a nightmare. Some of the best network admins I've ever worked with and they couldn't nail down why the load balancer did the things it did, when it did them. It was bad enough that the config had more exceptions than rules just so that we could try to eliminate anomalies.

I hope NGINX doesn't suffer too much under this new ownership.

It may get embedded tcl.

* If you start a company and open source your core/clients, your product becomes part of AWS, and AWS runs you into the ground. *

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.

> your product becomes part of AWS, and AWS runs you into the ground.

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.

Just today, AWS announced a fork of Elasticsearch: Open Distro for Elasticsearch - https://news.ycombinator.com/item?id=19359602

A few months ago, AWS launched a MongoDb fork

For context, Elasticsearch merged their proprietary add-ons into the main repos https://www.elastic.co/blog/doubling-down-on-open and MongoDB relicensed to a not-quite-open-source license that compels you to release code for your entire infrastructure if you're running MongoDB as a servie https://www.mongodb.com/licensing/server-side-public-license... . If you make your money on support and not open core, it's difficult for Amazon to do anything to you, e.g., Red Hat is doing just fine despite Amazon Linux being a thing.

(There's also https://aws.amazon.com/corretto/ , a long-term-support version of the JDK, because Oracle is getting more aggressive about Oracle JDK licensing.)

Or use copyright licences which the big tech companies are scared of. Affero GPL or some of the more radical "copyfarleft" licences.

The company sold for 650 million so it isn’t a bad outcome. They took open source code made better by tons of volunteers, added their proprietary bits and were successful and sold the company.

Isn’t this a great win?

> They took open source code made better by tons of volunteers

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.

Very big yes! No doubt Igor deserves the majority of the honour for Nginx, but volunteer contributors were a big part earlier on, both in patches, investigations and community support.

Search through the change log for "thanks to" http://nginx.org/en/CHANGES and you'll see a lot of contributions. Two people who stand out as frequent contributors are Piotr Sikora and Maxim Dounin (who went on to actually work at Nginx!).

And this does not show the mailing list discussions and bug investigations or the documentation maintained by the community in the early days.

[This post is not intended to mean this sale is bad, just to highlight some of the awesome community contributors]

Support, certifications, and subscriptions all seem to work fine for a number of companies.

I don't think there is a future in open source enterprise software where trade secrets are hidden from the public.

is there such a thing as available source, closed license?

Yes. Source code is copyrighted and you can make it available under any licence you like, including a proprietary one.

can be, I am interviewing quite a bit lately, among start ups there seems to be a renewed interest in doing devices. Probably because it is harder to do the commoditization trick or to re-implement the solution when hardware is involved.

Or keep open source and do enough antitrust that businesses must compete on other axes.

Source-available commercial software might be a more viable route to go.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact