If you work for a big engineering organization you will find yourself questioning things that are being built a lot. Open Source alternatives often have higher quality and better support, yet engineering organizations opt to build their own. You might wonder why? It's because growth is the name of the game. Any engineering leader wants bigger and bigger organization under her/him so what they do is they green light projects that mostly don't make sense but they can pretty much lie about how essential it is to build in house to the board/CEO.
When winter comes, those projects don't make sense anymore because cost cutting measures are in mandate. The same leader might even make the case for the Open Source alternative.
I've seen this enough times to know it is a pattern in our industry.
sometimes building something new seems obvious. i have to push hard to get people to back up that obviousness with evidence. (provide me with evidence that these existing solutions are not suitable before we build a new one from scratch.
sometimes building something new seems easier or cheaper than the effort required to evaluate alternatives, especially if the solution only takes a few days or weeks of work (take the obviousness factor above into account).
another factor is the seemingly common dislike of working with other peoples code. especially when it's known that modifications will need to be made. do we take this system with a lot of legacy code where we have to modify 20% or is it easier to start over and build what we need?
In house tools can also offer a lot more stability than OSS/commercial equivalents that will often require you to be on their upgrade treadmill. Very few companies will plan for this kind of maintenance so it's important the developers align with that and don't take on unnecessary burdens.
There's more OSS than ever but there is a huge lack of stability in most of it.
This is key. Extremely many "OSS" projects are also not up to quality standards and require significant engineering time for understanding, auditing and perhaps integrating the thing, even before deploying it. The bigger the set of useless features on a project, the bigger the risk in introducing an unknown into the critical paths that allow you to ship/provide a product/service. While many global "base" technologies like Postgres, enterprise Linux, Redis, NodeJS, Tomecat, the JDKs, etc are solid lighthouse projects with better quality than what "just writing your own" without world-class engineering teams and investment could produce in a reasonable amount of time, many others are just not that good. The cost of "adopting" a 2nd- or 3rd-rate FOSS solution may be very high and introduce significant technical debt down the road.
In way to many companies, engineers (including engineering managers) have to explain to a non-technical C suite that OSS/FOSS IS NOT FREE and NOT GUARANTEED TO BE CHEAPER than going with proprietary or self-written, minimal, tested and concise solutions in any given context. They can be, of course, and with some engineering investment they can be for the longest time in the feature, but every case is different and a "wave" certainly is not what just removes the need to do this kind of evaluation.
i disagree that extremly many Free Software or Open Source projects are not up to quality standards. i use them every day and 95% is of high quality. higher than many closed source applications or libraries.
this is not a FOSS question. (i would not touch a closed source library as s potential dependency with a 10 foot pole. it's either FOSS or i write it from scratch)
this is a question of the ability or willingness to adopt and maintain 3rd party dependencies.
fear of FOSS could be added as another reason, but that reason is even worse than mere unwillingness to work with other peoples code.
in order to use a 3rd party application or library as a dependency you must be able or willing to maintain it yourself, in case you run into an issue with its support. (that's one of the big points of FOSS, btw)
you are right about unnecessary features being a risk, but again, that has nothing to do with FOSS as a choice.
this is a general problem with humans. They are "convince" that they do good even when they don't.
> sometimes building something new seems obvious. i have to push hard to get people to back up that obviousness with evidence. (provide me with evidence that these existing solutions are not suitable before we build a new one from scratch.
The main issue here is that the perceived cost of starting from scratch is very low especially when from his ebony tower the programmer ignores all the issues the previous programmer had to confront.
> sometimes building something new seems easier or cheaper than the effort required to evaluate alternatives, especially if the solution only takes a few days or weeks of work (take the obviousness factor above into account).
... days which become weeks, years , decades. Why is a software project (exept TeX) never complete ?
> another factor is the seemingly common dislike of working with other peoples code. especially when it's known that modifications will need to be made. do we take this system with a lot of legacy code where we have to modify 20% or is it easier to start over and build what we need?
If builders made buildings the way programmers make SW ... Why do SW cannot improve the code ? Why do they have to "invent" the wheel every day and in the end they obtain the same thing or even worse ?
I'll give examples:
1. KDE and GNOME. With every release the interface is different. Old programs do not work anymore - they have to be ported to new KDE 4 or 5 or 6 or whatever. They were at the beginning way ahead of windows (r) and Mac now they just copy. Same with GNOME.
2. Win 10 looks the same like Win 1.0. Functionality is the same. Will Win 31 look the same like 3.1 ?
I think framework is extremely abstract today. Sometimes I need to check the source code to understand what kind of magic is going on inside the framework.
Yes, I've seen this numerous times as well. I call it "vanity hiring". "My department needs 12 new headcount because the other department is getting 10".
The sad thing is that you often have to play the game defensively -- I've seen semi-decent organizations end up consumed by the 80% overweight departments because bigger departments end up with all the advantages just as a function of their size, even if they're almost completely worthless. Have to keep pace with the useless hiring just so they can't say "well it's our smallest group, only 5 guys", etc.
I see "empire building" as a larger campaign. In some cases, vanity hiring is really just vanity hiring, motivated by noting more than the impulse not to let your peer's headcount pull significantly ahead of your own.
I think you could argue it already has a more general name; individual self interest. The peak headcount you’ve managed or directred has a pretty direct impact on the level of manigeiral roles you are in contention for.
> From your experiences, tell me more! How could this problem be avoided? How does one sniff out such glut?
To a certain extent:
Create a corporate culture where people can get work done without needing to be "protected" from the rest of the company around them
Select against empire-building folks.
Push a culture of reusing and improving existing tools whenever possible.
Recognize and reward people for avoiding and eliminating technical debt, not just for building new things. What you recognize and laud, you will get more of. (There's a balance here: you need both kinds of people.) Hire more collaborators and less "ninjas".
If you have enough budget, empower people to experiment with interesting things without having to hide those folks under a corporate-level justification smokescreen. Understand that some explorations and experimentation will not pay off, and support that anyway, so people don't feel like they have to hide things until they're successful.
Encourage people to report organizational issues and organizational friction, and fix it as early as possible, so that people don't have to create "shadow infrastructure" to get their job done.
Personally, I think this problem is inevitable as organization scales. So, if you don't want to fall into that, remedy is simple: don't scale. As in, you can scale in terms of revenue and user amount, but avoid reinvesting it into hiring more and more people. (Classic examples of companies that achieved that, at least to some extent and at a certain moment, are Instagram and Whatsapp, but there are many more less famous ones).
I guess, when you're on the rocket part of the hockey stick it seems that you can solve anything by hiring more people. A lot of leaders kind of forget what they sacrifice when they do that.
If someone comes to you and says "we need to hire more people to do my job so I can move into a leadership role" say "sure, if you take a pay cut," or "no"
If you are making a lot of money and one of your employees has performed well, and never asked you to hire more people to do their job, give them a God damn raise
I think this is true in some cases, but there are others where an engineering org is proposing building an internal solution on an open source stack vs fewer dedicated internal resources with a proprietary solution and the argument becomes one of using internal resources to do something which is maybe a little outside of "core competency" areas vs a proprietary solution that may claim to do everything needed with a risk of limiting options either technically or financially in the future. There I've seen a pattern of short term financial cost overriding future risk, but maybe that shifts a little due to pandemic outcomes.
Last month, we lost a big project against SAP (budget 5m€): the company choosed SAP because their holding was willing to pay for the project. Last week, the same prospect came back to Odoo: as the holding could not afford such a project anymore, the company has to pay from its own budget. So, they choose Odoo (<1m€ budget)
I believe the next wave is a replacement of proprietary expensive business applications: ERP, SAS, BI...
Basically, anything not open-source is not cool any more - SAS, matlab, SPSS. Kids are not learning these frameworks in school and don't want to use them. I see open-source taking over Data Science by the time this recession is over: Jupyter, conda, Scikit-learn, TensorFlow, PyTorch, RStudio, and even PySpark.
Octave[1] covers most of Matlab uses, and it's FOSS. And there is Sage Math[2] that integrates many different FOSS components to be something like Mathematica. Both are developed quite actively and covering many differences with proprietary analogs every year.
> I still don't understand why Wolfram Mathematica doesn't have wider adoption.
High prices for hobbyists who are not students.
The Wolfram store does not even give you the option to pay with anything else than credit card (in Germany, other methods of payment are strongly preferred), so you have to use a reseller if you don't have or don't want to use a credit card for payment.
Side story concerning the previous paragraph: I got a voucher from Wolfram Research to update my Mathematica license via the Wolfram store for a price that seemed fair to me at that time. So I wrote to the support that I would love to accept their offer/voucher, but have no credit card. Wolfram Research support told me, this is not possible; I have to use a reseller in this case (for which the voucher does not apply). OK, I get it: Wolfram Research does not want me as a customer.
Kind of like “follow your passions”, “open source” is a great way for software developers to work at way below the market rate to provide provide great value to corporations for very cheap. Through github stars and “recognition” the corporate world has managed to gamify software development and get enthusiastic developers to develop and give away literally billions in software value.
No wonder the MBA’s view software developers as suckers.
Read through HN, and you see maintainers of hugely popular open source software that probably has saved corporations billions of dollars, burned out, mentally exhausted, living in poverty and begging for donations.
I think there's substantial value in replacing expensive system components with free alternatives. Things like FusionAuth / https://fusionauth.io/ for user identity (full disclosure, I'm an employee) and Pentaho Kettle https://github.com/pentaho/pentaho-kettle for ETL and data transformations can help.
It is important to recognize the value of developer time too, though. There's a cost in dev time for setting up a "free" project.
That's why I think that any open source project that gets too popular will have to have a cloud vendor strategy, otherwise they'll get done to them what AWS did to Elastic Search.
I also thought it was interesting that the author mentioned support for the various application libraries. I know that there have been several "tip" type applications (gittip, gitcoin.co) that try to align incentives and allow open source developers to make a living.
>>> That's why I think that any open source project that gets too popular will have to have a cloud vendor strategy,
This.
In fact sadly one of the marks of a successful OSS project is ability to pay yourself, and even perhaps commercial success. In Linus' day it was enough to have a whip round online to buy a faster Pentium machine, but these days it's a foundation and cloud offering.
I was at a conference last year and talked to someone who said that the investors he knew were shying away from investing in open source software companies because anything that was successful would just be copied and operationalized by AWS/GCP/Azure.
I hope that isn't the case, but we'll see. Maybe the answer is niche operations that are too small or domain specific to be noticed by the big folks.
There are lots of niche operations, but they tend to build their domain-specific work on top of these cloud providers.
AWS's fork of Elasticsearch (ES) is a good example of the operationalization you talk about. If I was building a niche eDiscovery solution for the compliance market on top of ES I'm likely to want to offer that on AWS or another cloud provider at some point. If they offer their managed version of it, then I don't have to support it.
You can make obvious arguments like special extensions, or all compliance customers don't use the public cloud, but ultimately many users are going in that direction. Any type of general-purpose tool like ES is ripe for the picking by any cloud provider when it gets popular.
The only options I see are licensing it in a way that's prohibitive for adoption by cloud providers, or engaging them early to become their subcontracted maintainer for the product on their cloud so that you remain in the value chain.
Ultimately, it's not the type of business that should be taking VC money because the upside is, so limited when you have the typical successful outcome. The only way to get to an outcome that VCs might like is to use the income stream, or talent acquisition, from the open source product to pivot into something that isn't as limited. Doing that is really hard.
I'm pretty sure there's room for smaller verticals these days. It's been demonstrated many times that if you have the best front-end to the problem space, and you add some services on top, everything under it can be totally commodified but you'll still get customers.
From there the strategy would depend on whether you want to stay small or not: To get bigger, you'd start going deeper into the open stack to scale things up and provide a wider array of services. If you stay small, your organization will necessarily be more focused on interfaces and compatibility while maintaining that top-end UX. In both instances there are plays for open source, but with different characters; the big company will tend to code-dump an enterprise toolchain, the small one will primarily be a contributor to a foundation project or open some of their internal interfaces.
> It's been demonstrated many times that if you have the best front-end to the problem space, and you add some services on top, everything under it can be totally commodified but you'll still get customers.
One big area where open source unfortunately falls flat is end user application software. In this market, proprietary applications do add real value.
Unfortunately, there isn't a very good business model to fund developers to work on such applications, when the application itself is not a sell-able product.
These sorts of projects can work if there's a significant overlap between end-users and capable developers. If there isn't, then they're often woefully inferior to the commercial alternative.
Open-source sucks at UX. I think because there's no community behind open-source UX like there is in the inner workings of systems, where people just want to get shit done.. You have to pay UX developers and designers to do their job, because it's generally not a job you'd do for free or in order to accomplish "something".
> Open-source sucks at UX. I think because there's no community behind open-source UX like there is in the inner workings of systems, where people just want to get shit done.. You have to pay UX developers and designers to do their job, because it's generally not a job you'd do for free or in order to accomplish "something".
Closed source also sucks big at UX (see Office 365 for details). But M$ offers "integration" a thing which OSS cannot offer. Also , having enough lobby (corruption) or market share , the UX does not matter.
As a software developer, I'm writing to benefit me because I use the code I write.
What I write and share is directly re-usable to others.
We can walk a path and share our work, and others can take it and copy it immediately.
Whereas with UX.. Most of the time it's written for the benefit of someone else. And it's not something that can be used elsewhere very easily.. Often needing to be completely re-worked to be useful anywhere else.
You're talking about libraries. And parent answered to message about end user software. Sure, you might use your own end user software, but so can UX designer.
If the designer isn't also a software developer who writes a new application to scratch their UX itch, then they must work with some existing project, which presumably has existing users..
It's probably always going to be harder to contribute design overhauls than bugfixes & features.
Because for programmers coding is a passion. I've met one person in my life with a passion for UX, all the rest really wanted to be doing something else and just do it for pay. Not to say they don't enjoy their work, just that it's not a personal or deep passion.
I think the growth is on a continuing streak and there’s not a need for a RedHat style support for every package.
I think using these packages and projects requires more due diligence and planning on staff to pick and support, but I think the current highly variable support project by project works out well. And then for big stuff (Linux, Postgres, etc) some commercial support is brought in.
I’d much rather see more support for companies donating developer hours to patches and features. Some way to recognize in kind and labor contributions and expand recognition for these kinds of contributions. I think this works better for software than trying to get every company to pay into some support fund. If you want to pay structured licenses for everyone, there’s a model for that. Trying to shoehorn license fees on top of open source loses a lot of the efficiencies, I think.
I think you're missing the real value here of the support model and services a company like Red Hat can provide to large orgs.
It's not about having support for every package, it's more about having others do the hard, expensive work of presenting you a portfolio of projects known to work well together, so you can focus on adding your own business value rather than spending hours duplicating effort from others and debugging arcane issues.
To some extent you can't out-source everything (and I personally wouldn't recommend that. I think having some in-house experts is really important), but not everybody should roll their own OS, DB, container orchestration, etc.[1], and finding consistent options that work together can be difficult when you have huge, diverse, engineering departments with different values/priorities.
I don't disagree with you: I think contributions in either code or donations are a great way to support FOSS projects. I just think there is also a lot of business value in the support contract style method, because you're not just buying insurance, you're buying real value in the form of somebody presenting you with a portfolio of disparate open source projects that have been integrated and tested together.
[1] Note I'm not talking about "React v. Vue" which I agree support wouldn't make sense for.
As a developer running a couple of servers I understand your point. I used to love updating to the latest version of all software I was using. Now I am quite happy to use what my Linux distro packages. The stability is the best feature.
Thanks for the insight. How might someone in a position to spin up services for this be able to think about capturing this sort of a market?
I work at a DL/ML hardware company; and many here on HN would know that packaging DL libraries correctly is a nightmare and a half. In fact a good chunk of our value prop is offering an open source pre-baked bundle. It's great (and I've deployed it on some friends' machines and they love it) but it's, let's say three-quarter-baked and moving it into a "fully supported" model with domain-specific expertise isn't something that our company has figured out how to transition into (also not easy given our company is really small), and given business strategy and software strategy are independently difficult enough problems.
This is purely a thought at this point, but I have seen a few small companies in situations like yours be able to get some adoption by:
1. Having a product that solves a real need for the buyers (and preferably one they already know they have)
2. Getting that product "certified" with a partner, such as OpenShift.
I cannot get specific, but there are a few companies I've seen that developed a clever solution to a problem, packaged it into a Kubernetes Operator, got it certified with OpenShift, and because they had that logo they got the audience with the people with purse strings. At that point it's classic salesperson strategy.
A lot of big customers right now want to be able to point-click install stuff easily into their existing platforms/stacks, and then "check a box" in their list of requirements. If I were in your shoes, I would look at how people are already using it (OpenShift? AWS? Azure? Google Cloud?, etc and go from there. Getting "certified" is usually a mutually beneficial arrangement. It will take a bit of work with bureaucracies (which will annoy you greatly), but the payoff can be huge.
Luckily it's not the only path for growth... As I mentioned we're a hardware company so it's more like we want to wind up as a Dell (or in a worse scenario, IBM, which isn't too shabby)
As the article the grandparent links to shows, RH is maybe the singular example of a big successful pure OSS software company. It seems almost all other big successful OSS companies have adopted some kind of 'hybrid' strategy such as open core, many after first unsuccessfully trying to emulate RH.
To a hw company, I think the issue of how to monetize SW is to some extent clearer as well as pretty different than for a pure sw company. You're selling a tangible physical product, but customers are not interested in the raw hw but the complete package of hw plus supporting sw (drivers, SDK, whatever) + support. So you have to choose what is the appropriate model for you. E.g.
- Use profits from HW sales to develop OSS that makes the HW more useful to customers, and thus increases HW sales. For instance, one argument in favor of this would be that drivers included in the upstream kernel and user-space software in distros makes it easier for customers to use your HW. And you'll get OSS brownie points which might also help drive sales.
- Or make the SW free but not OSS, in case you're worried that your competitors could just take your OSS and use it with their HW.
- Or make proprietary SW that you sell in addition to the HW. I'm not sure customers care about how you split the total bill they're paying, and free (as in beer) software is certainly a lot easier to deal with for customers (e.g. license hassles). But again, it depends.
- Oh, and another potential advantage of the OSS SW model is the 'commoditize your complement' angle (do a web search on that phrase if your unfamiliar with it). tl;dr You can use OSS SW to undercut a pure SW competitor, as your income is protected by your 'HW moat'.
RHEL (CentOS) is only a small piece of what Red Hat offers. If all you want is a base RHEL system (that can be a week or two behind on non-security patches but is otherwise the same), and you don't need any support, then yeah I'd do that (and I do in fact. I use CentOS for personal stuff all time). Since all of Red Hat's stuff is open source, you could install them all individually just fine. I think of Red Hat as more of a competitor to cloud companies than to Linux companies. A lot of what we do is help people build their own private clouds on the hardware they own. RHEL is at the foundation of course, but RHEL is very rarely the end goal of the customer.
If you are doing this at scale, you're going to end up paying way more in salary to employ people to do it than you would if you just went with Red Hat support. And since early in an effort you need more people, you would either have to lay people off or find new jobs for them.
I often swoop in and knock out tasks in hours that would take the company's infrastructure/SRE teams days or weeks to do, because I've done it a lot and I know what I'm doing. Its also less likely that I'll make a configuration error that exposes itself in prod, simply because I've already made those errors in the past and learned from that mistake. And when I do screw it up (which is a very, very, rare occurrence ;-) ), the company isn't scrambling to fix it. They call up support and we get it fixed ASAP. Again it's not for everyone, but it is for some people. I usually find that buying Red Hat saves a lot of money rather than costing money, which is why so many big companies do buy us.
RedHat (or Ubuntu let's or SUSE Linux enterprise) have reactive support: call them if something goes wrong, and the, have proactive collaboration with paying customers.
If you think you don't need that: use free riding flavours i.e. centos/ SUSE leap/...
Tech support can tell by looking at the system if you are a paying customer or a free rider. And sales can look at the download numbers and management servers if your installed base is what you claim it is.
Could be, but only if companies that are behind OS products will survive by themselves. We hear crack sounds here and there already.
Yet, "the rise of hosted cloud services like AWS, Google Cloud, and Microsoft Azure" is just "anti-pattern" for the subject of the article. Commercial companies that exploit (fuzzy term here but still) OS software.
I think the next wave of OSS products will be AGPL-v3 licensed. It's the "cloud condom" model - it protects you from the cloud vendors. They have internal bans on using it, as it forces them to open up their internal software architecture. But AGPL-v3 is still a valid open-source, despite what the shrills at AWS will tell you (they just want to operationalize open source projects, not lead them).
AGPL-v3 isn't going to protect you from cloud vendors, they will just release the source and beat you with their marketing budget. Or they will just re-implement your APIs/interfaces from scratch and still win.
Open source is a two edge sword. If developers voluntarily contribute to the projects, it could be positive.
But increasingly it's becoming a source of cheap labor. It used to be that you get a college degree and start a job. Now you need years of schooling, unpaid internships, postdoc and unpaid scientific contributions, an extensive GitHub page with open source contributions, etc to get the same job. The competition for better CVs will push individuals towards taking years of unpaid jobs against their will, which is negative.
I get that expectations have changed, but I have lots of friends graduating with a Computer Science BS, with nothing on their githubs, who do well on their interviews and get entry-level positions making six figures.
Edited: And no one I know does unpaid internships -- most CS majors are making $20-40+/hr over the summer of their second or third years in college.
I graduate this May with a CS degree, that about mirrors my experiences. The vast majority of competent and even semi-competent students have no problems getting good paying internships, and jobs out of college. I appreciate that unpaid internships are a really bad situation in some fields, but fortunately CS is pretty lucrative right now.
That article was nearly content-free. Brief review of history and then some talk about a supposed "third wave" of migration is not clearly characterized, nor actually foreseen in any detail ("certainly X would be a good place to start" - thank you captain obvious).
No discussion of anything signifcat:
* Are commercial corporations contribution back to FOSS software they use?
* * Additional functionality and bug fixes?
* * Grants/donations of money, hardware or even developer time?
... Amazon, Google, MS run mostly FOSS on their clouds, and pocket billions, but certainly don't give much back.
* Does "open source components" just mean FOSS inside but closed commercial outside, or do companies transition to making FOSS?
* What about hardware? Or at least, device drivers and firmware?
* What about all those SaaS and PaaS platforms even the article itself mentions? Their engineering setups, and software in particular, are mostly closed. Where's that promised "wave" for them?
The third wave of open source software is no software at all. It is only a matter of time before Amazon doesn't care whether it's licensed Apache2 or not. They will just take software and sell it. You have a problem with that? Have fun suing them... Year 1..2..3..oooo. you are quite the fish..4..5. broke. Out of money.
Initially, licence the software as AGPLv3. Then, if necessary, assign copyright to someone like the FSF or the Software Freedom Conservancy who has the goodwill to attract sponsors to keep up a suit for as long as necessary.
Me too I realized that criticism towards AWS brings downvotes on HN. A bit strange because it's usually the opposite online. Maybe a lot of HN readers are working for AWS.
"Vendors developing those open source products started accusing AWS of strip mining, i.e., reaping the benefits of the products, without contributing back to their development."
Linux contributions are not the best example, since it's GPL, and you pretty much have to contribute back to get your changes mainlined, and end-users can request your changes at any time.
Now, if they contributed back to FreeBSD, that would be meaningful, since they don't have to.
Amazon doesn't distribute Linux on server hardware (just consumer hardware like the Kindle) so they don't have to give back for server aspects of Linux like KVM, yet in the Linux kernel code, the Amazon employees are mostly submitting patches for things like KVM, not for Kindle hardware support.
It would surprise me if Amazon use FreeBSD, I thought they use Xen & Linux KVM exclusively?
It's truly awesome that I can send an email to Amazon
saying "we're seeing an odd performance issue here" and
get back "here's a FreeBSD kernel patch I just wrote which
provides a 10% performance boost".
And people claim that Amazon never contributes back to
open source...
"strip mine" is in the zdnet article linked above, have a look. (Resells without contributing back in any meaningful way, instead hurting the oss company financially).
"Destroyed" was an exaggeration, at least as of today.
However I like and use some of the oss projects Amazon strip mines -- if Amazon instead paid the oss companies a part of want Amazon makes, that'd let those oss projects hire more people, improve the software even more -- and that I would appreciate, and could be made in a mutually beneficial way I think.
This isn't a new problem, for eg web hosting companies have been selling Apache/PHP hosting for decades. Apache and PHP were made more useful because of that reselling rather than being negatively affected by it. I think the only difference now is these OSS companies are VC backed so they have to get huge growth to pay back their giant loans.
I watched a talk recently that argued that Amazon increases the size of the market available for the software the OSS companies are producing. So the pie increases in size and the result is likely to be more money available for the software, not less.
The OSS companies you refer to are more about using OSS as the new shareware, a loss leader or poison pill to sell proprietary software, their business model isn't about open source at all.
> 'the only difference now is these OSS companies are VC backed so they have to get huge growth'
That's a good point.
> their business model isn't about open source at all.
(What do you consider open source biz models?)
> OSS as the new shareware
I think I understand what you mean. At the same time, in my case using only the OSS parts of the open core software, has been more than what I've needed
> I watched a talk recently
That talk sounds interesting, ... If you remember the name or speaker maybe I can find it?
It wasn't the talk I was thinking of, but this NextCloud talk discusses various OSS business models and mentions the AWS vs VC-OSS issue, especially during the questions section.
The Postgres git repo doesn't make it easy to discover the employer of the commit authors, but yes, they do send patches to Postgres, here is a search of commits referencing mailing list discussions started by Amazon, plus a couple of examples of where they sent patches:
Some open-source projects have companies behind them - e.g. I am the founder of RudderStack, an open-source segment.
We have thought about this quite a bit. The way to address this is to make offering your OSS as-a-service from day-1. Initially, you are small and AWS won't care. Once you become big, you should be able to compete with AWS on the service offering - afterall you know your code best.
The problem arises when the OSS vendors had a different business model (open-source, on-prem support only) and AWS is able to completely own the as-a-service market.
I'm probably naive but I don't think you need that much money to sue AWS. They may afford an army of lawyers, but that's their problem. You can't buy a judge as far as I know.
I think this wave may have been started by Arduino, but I mean... Raspberry Pi? Teensy? MBED? Any microcontroller manufacturers' dozens of reference designs?
How much more open hardware do you want? I'll be thrilled once reasonably sized phones and laptops are reasonably straightforward to get with open hardware of course, but there is lots and lots of open source hardware.
I feel like now would be a good time for an open source FHIR-compliant electronic health record to start building integrations for any non-Cerner/Epic company in the market. Which the more I learn about healthcare is approximately all of them.
>Now, after one of the longest bull market runs in history, the road ahead is again uncertain.
The rumors of this bull market's death have been greatly exaggerated. The DJIA is still up over 18% over the last 3 years, or ~6% annually; barely a percent below average. The NASDAQ 100 has almost completely recovered its' losses from the initial COVID-19 crash. Major drivers of the market over the last 10 years like $FB, $AMZN, $MSFT, and $AAPL are through the roof. Granted that a lot of this is fed meddling, and yes a lot of people from the service and hospitality industry are out of work, but the primary engine of our economy is humming along. I would not be surprised to see a record Q3 this year.
Amazon's marketplace and delivery service have a "captive" market due to the closure of bricks and mortar retail.
The general move to the cloud rewards AWS/GCP/Azure with the two primary "winners" currently being AWS and Azure. This will continue as companies move to the cloud, but expect there to be a flattening of growth.
As for Facebook and Google, they rely on advertising, which relies on consumption. When there is 10+% unemployment and 20+% underemployment, consumption is highly likely to at least flatten if not fall off a cliff, particularly in elective consumption like high end electronics.
The share market is not indicative of the economy and is a lagging indicator of company revenues.
Have you considered the possibility that momentum carries forward for a bit like Wile E. Coyote running off a cliff and hanging in the air for a moment before plunging? If consumers can't afford to spend then why advertise, why buy a new smartphone?
I don't understand the second wave relation to open-source and free software. They moved to cloud platform to save cost and non of these platforms are open source.
When winter comes, those projects don't make sense anymore because cost cutting measures are in mandate. The same leader might even make the case for the Open Source alternative.
I've seen this enough times to know it is a pattern in our industry.