I went to IBM(India) interview sometime in 2011, after leaving GlusterFS (Red Hat). Interview went well, during final call with management. I was asked to stop working on Open Source during weekends or off-hours even though the IBM project and my Open Source work has nothing in common.
I said, "I thought, IBM support Open Source right?" his response, "Yes, but that's another team"
I am currently working for IBM and I'm tied. I had to supress my commercial project once I joined big blue. What I have in contract is - if you want to open a company, you need IBM's permission first.
And it's just frustrating as they try to block it for as long as possibe even if you're not doing IT in your private little business.
A long time ago I joined IBM via an acquistion of the company I worked for. One part of the (lengthy) contract I had to sign, was a form listing any side projects I may have that I would be required to no longer work on. I simply omitted that page when I returned the contract and no one ever noticed.
I'm curious. Anyone care to outline the legal ramifications of this action? What would happen if IBM tried to stop his side-project?
1. Would IBM be able to enforce the original contract as it was outlined when they sent it to him? Would he be liable to fraud or other similar charges (for instance if he altered the contract after IBM representative added their signature)?
2. Or would the altered contract stand up in court?
I routinely alter almost every contract I receive. It drives a lot of doctor offices/emergency rooms nuts. But they have so far always calculated that their liability will be higher if they refuse service than if they allow me to cross out the part that says I won't sue them if they kill me.
It is a point of amusement to me to see that the receptionist is extremely uncomfortable agreeing to the terms I have come up with in the last five minutes. They don't think it is reasonable for me to expect them to execute the altered contract without consulting attorneys. I point out that five minutes ago they asked me to sign a contract without consulting a legal expert. Their multi-page contract had been painstakingly drafted by a team of expensive lawyers and meticulously tweaked over years. Yet they gave me mere seconds to read it, understand it, and sign it under duress of not receiving medical attention. If they balk at the contract I hand back to them, how can they expect me not to balk at the original contract?
On the other hand, if they refuse to provide medical care because I wouldn't sign away my rights to any photographs that might be submitted to medical journals, they had better be very confident in their lawyers.
Banks, rental agencies, repair shops, etc., on the other hand, can safely refuse my revised contract. Most don't glance at them when I hand them back.
If they choose to have a judge nullify the contract, I'm good with that. I didn't add any verbage to the contract anyway, so that would just mean that the entire contract is void and not just the parts I crossed out. We can re-negotiate the whole thing. Oh, but this time, seeing as we're in front of a judge and all, I have a lawyer with me. And we can examine the reasonableness of every single line item on the bill without any medical time constraints.
The new contract can be something we collaborate on. Them, their lawyers, me, my lawyers, the whole happy family. We can take four or five years to do that. I'll pay them when we sort it all out.
Or... they can accept my thanks for sewing my toe back on and bill my insurance.
Either way, we are on much more equal ground after the fact.
Very interesting read. However, he changed it before the bank added their signarture. I imagine that if you change the contract after a signature is added by one party, and then add your own signarture, that would surely be fraud... right?
If you presented the post-hoc changed contract as binding, I believe so. If you presented the post-hoc changed contract back to IBM and went "Hey, do you agree to an updated contract?" then you'd probably be laughed out of their office, but that's not a crime to ask them to update a contract.
You could make an intentionally vague reply saying; "Thanks! Here is the updated contract with my signature back.". Making the other party think you just updated the contract by adding your signature.
I remember the story. The bank's CEO (the guy is a billionaire of considerable notoriety in Russia) threatened to put the story's protagonist in jail for fraud for 4 years.
The protagonist took the threat very seriously (as he should have) and in a later interview to banki.ru (i.e. banks.ru) said that he was fleeing the country to a destination he preferred to keep secret. Reason being the precise "4 years" that was used. Not 2, not 3, not 5. Meaning that the CEO had already made "arrangements".
Then 2 days later there was an article that both him and the bank have reached a peaceful resolution and were recalling all mutual lawsuits.
At least for real estate contracts in the US, both parties have to initial each of the alterations and amendments to the contract that typically come up during negotiations. I doubt a random line crossed out in a contract would hold any legal weight in court unless acknowledged by both parties.
On the other hand, if I intentionally mislead you about the contents of a contract, it might not be binding. If you hand me a 10 page document, I pencil something in on page 7, sign it and hand it back to you without notifying you of the change, I don't thing you'd be required to honour my modifications.
Or you know, it might be fraud, as in the crime. Misleading someone about the contents of the contract they signed is exactly that. The paper (they printed) and gave to you in the understanding that you would sign and return it was altered in flight.
Essentially: if IBM wants you thrown in jail, you will be thrown in jail for this. Have fun in court.
> I had to supress my commercial project once I joined big blue.
I am pretty sure this is the standard practice at all large companies, at least in the US. Small companies may just not care too much, but even at a small company if your management notices you might have to choose between that and your day coding. I wish it was not like this, but to me this is at least somewhat justifiable.
Much worse is the desire of most employers to control everything you do, including your work on open source project off hours. Want to fix coordinate computation for an open source satellite sim? Call the lawyers first. Lead a robotics club at a high school? Check with the management. IMO many employees do it anyway and hope to not get called on this, but this is formally going against the contract.
I've only worked at one large company (EA), but they were ok with side businesses as long as it wasn't competing with their core business of gaming. IIRC you could even promote it internally. This was about 9 years ago.
For game related things you could list them as existing inventions when joining. So you can carve out exceptions. Which is common with game companies.
How do enough people agree to those terms to make them plausible in the first place? That's like going to work at a restaurant and being required to stop working at a soup kitchen on the weekends.
I would never agree to those terms and strike them out. That's ridiculous.
One way of looking at it is paying for mindshare. Sometimes companies want your brainpower only focussed on one programming problem. They might not want you at work, thinking about items in your side project.
Focus is a big deal. Doesn't make it right but it's the only business justification I've ever heard that actually seemed legit.
At the same time, there should be an expectation of compensation to give something like that up.
People are aware that they're not required to sign any contract they're not happy with, right? You are well within your rights to cross through any section of a contract or amend it until you're happy with it.
I've routinely done this with every contract I've ever signed. Nothing gets signed without legal scrutiny on my part and it never will; and I've quite literally never had a potential client or employer balk at this.
All of them have agreed that my amendments have been quite reasonable - and that includes scrubbing through any sections that prevent me from working for other clients or writing my own projects, commercial or otherwise.
Ensuring a contract is fair and equitable is part of doing business. There is nothing wrong with this. When you work for a company, you are still an autonomous person with your own agency. Any company that seeks to deny that agency don't deserve your employ.
Any reasonable and honourable company expects you to review contracts and amend them. You shouldn't feel bad about doing this. Nor should you feel coerced by the fact that they have given you a one sided contract. Make it equitable.
I don't care if you're IBM, Microsoft, Apple, Facebook or God almighty, himself. If you choose to attempt to quell my agency, our relationship is done. I will not be denied my agency and neither should anyone else.
Those companies that over-reach in a bid to control their employees are unscrupulous. This is the same kind of toxic behaviour that people seek to avoid in their relationships, yet somehow they're quite willing to live their life working in relationships like this... I don't understand the double standard.
I've heard soooooo many people say that "contracts are just standard paper and if I rock the boat I won't get the job."
Don't be bullied into signing a contract because you feel like you don't have any other option.
Contracts are not "standard paper," they are legally binding documents that seek to limit your behaviour. Don't let any employer reach outside their jurisdiction and into your personal life. Ever.
>People are aware that they're not required to sign any contract they're not happy with, right? You are well within your rights to cross through any section of a contract or amend it until you're happy with it.
How do people do this these days? Virtually everything I sign these days from my employment contract to my lease to the vast majority of the paperwork for my mortgage was all signed electronically. There's no apparent mechanism for redlining sections when e-signing.
You don't get coerced into signing for something electronically for a start. If this is the only way they allow to do this and don't allow for you to amend sections, you tell them that you will print it, have your lawyer amend it and then fax it back.
If they want your business, they will make concessions to win that business.
If they don't allow for this, then you need to be the one to decide if you still want to do business with them. I sure wouldn't. I'm not signing for anything that gives away my rights.
I generally refuse to sign edocuments, I'll print it and mail it. I might email scanned signed copies. But I have enough experience to know DocuSign sucks. I have zero faith in it.
(OT) I interviewed with IBM after they were acquiring my companies resources at the time. My first two interviews went swimmingly. On my third the interviewer had marked through my last name on my resume and when I asked about it she said she assumed I had spelled it wrong. That was the best thing that happened in the interview.
Years later I had a thought that she was trying to throw me off and see how I reacted under pressure maybe - but bizarre is a great way to put it. She took everything I said out of context.
Funnily enough, one of the most praised points in Red Hat's code of conduct is the fact that it specifically says that you can work on open source projects _even if it is to the detriment to Red Hat_. Guess that's going to change now.
That's a great example. I remember a lengthy thread about this on memo-list back when I was at Red Hat. Always made me smile.
It's also how we were able to spin out our company and raise VC on something inspired by experience, if not using the same code, as what we worked on internally. Having one of the Red Hat founders as our investor helped, but I just loved this attitude of "go build something awesome and keep in touch".
Hey ndru, I'm a reporter with Bloomberg and I'm keen to stay in touch with Red Hat employees to get an accurate picture of how the acquisition is going. Can keep it completely anonymous. gerritdevynck@protonmail.com if you're interested.
Thanks!
So...not completely true. There was that one memo-list thread last year where someone complained loudly that they were not allowed to work on an intentionally competing solution and repo, even if it was on their own time.
He was certainly allowed to work on it on his own time. He just was no longer being paid by Red Hat to work on it, or to travel to conferences/conventions to work on it.
As IBMer you should know there are a plurality of local IBM all over the world, each with local laws and regulations to abide. In Italy all work produced off hours as subordinate is intellectual property of the employer by default unless you sign off a release form for each of them. In Ireland at least they don't want you to touch third party open source code without license vetting because it could inspire you subconsciously and result in copyright infringement.
These terms would be illegal in the Netherlands as the company cannot infringe on personal time.
> In Italy all work produced off hours as subordinate is intellectual property of the employer by default unless you sign off a release form for each of them.
I'm pretty sure that will not hold up in court if you go high enough (e.g. European) as it would impede self determination.
I can see Joel's points here and this is relevant to the discussion.
It's probably the article he has written I disagree with the most as there is a simple way to deal with this; be very clear about the projects, code and designs the employee works on each month and sign them over as they are delivered. That way the employee's own work will be clear should there be any legal wrangling. This could be done by a status in Jira for example.
What wouldn't be the 5th time I've heard such stories, but I don't think it's in any way specific to IBM. Employers like that want any OT you do to be dedicated to THEIR endeavor, not somebody else's...even your own.
If you're able and willing to code in your off-time, you should be doing it for the good of the Company. /s
So when you come up with a solution to a work problem in the shower in the morning or while lying awake in bed in the evening you could sell it to the employer, since you owned that time?
What happens if you create something patentable in the eve information related to your employer's business, maybe even to your project. Can you patent it yourself and then collect royalties from your employer?
What happens if you infringe Copyright on a competitor on your GitHub project, where your GitHub profile also says where you are working, can the competitor distinguish wether it was you personally or as part of work?
For creative work it is tough to fully distinguish between work and leisure time ... some companies deal with this better though, than others.
In a right to work state, you could indeed walk in, terminate your employment, and file a patent later. You could then charge that company for that work. In civil court, it would be argued as to when you actually had the idea.
In these civil suits, the one with the most money wins, so you would still lose even if you indeed solved the problem after you left.
No need to defend those huge corporations. They're perfectly capable of bribing officials to screw over employees all by themselves.
This is a fair argument, but the solution isn't to just strip the employees right to own their own thoughts.
The specific problem seems to be about patents and trade secrets. If a contract covered those two things well, would an employer have legitimate cause to push further than that?
One relatively benign reason behind such policies is that the employer wants your free time to actually be free time that helps your recover, not a second job that leaves you exhausted and fighting burnout and sleep deprivation.
This happens because the "first job" doesn't pay enough (so doesn't allow for long-term free time), or has hours that are too long to begin with (so doesn't allow for short-term free time).
More the opposite. Your contract says 8 hours, but everyone does 11 on average, so there is no way you could dispute ownership of those results.
Secondly most IT companies have 'innovation participation' programs that want to have first dibs on all your creative ideas, whether it's on the clock or off.
Thirdly, in an industry with very low start-up costs (all you need is a computer)and high competition for talent, even the potential threat of a former employer claiming IP over your new business can be a potential deterrent that nudges people into just not do it.
That doesnt stand up to reason. There was no enquiry into the amount of hours put into this that would indiciate it was second job or exhausting, they also don't do a full enquiry into any other activities outside your work that might exaust you. That would make contributing to open source a totally arbitrary thing to pick on, which of course it isn't.
Yeah sure, and if you like I can also clean the bathrooms because I know how to do it...
Off-time is for your own not for your company regardless off what you do with it.
Radical differentiation from competitors is the name of the game for entrepreneurs. Online communities in general and Hacker News in particular have every reason to push back and reject low-effort Redditisms and 4chanisms.
Having worked at IBM for 10 years, this is what I have come to know how IBM operates top-down:
1. To make significant profits, we need to sell services on top of our software products (this is essentially GBS and their "strong" sales people)
2. To make very good profits, we need to make highly customizable software (for example AI and BI offerings).
3. To make even more profit we need to make sure the software is tuned to the hardware we make.
If one of those weakens the entire IBM portfolio and profits weaken dramatically.
Here's problems in last 7 years tho:
1. People moving to the cloud so the hardware business flatlines.
2. Because people moved to the cloud they found replacements to IBM software.
3. At the end of the day IBM is forced to deliver professional services on top of other companies' software and hardware (and services employees are not cheap).
At some point the IBM execs must have had an epiphany that their AI offerings don't sell because they don't have a platform that sells other commodity cloud services on top of which AI components can be sold as high-priced addons.
So thus IBM decided to do what it does best --- take control of the entire stack.
With this acquisition IBM has the potential to become a next gen. cloud vendor. For example IBM has been trying to sell Bluemix as a hybrid PaaS/IaaS but haven't been very successful. The engineering team in Bluemix is weak and one way to really up the ante is getting access to top talent in the industry to do this (CoreOS team, Openshift.io team, linux kernel devs, distributed storage devs).
What's not clear here is that why would one company, which is dong pretty well, better every year, would want to be sold to another company, which doesn't look well (from your own description), instead of just continuing growing and eventually "winning" the cloud market by themselves? Is that just because top Red Hat people wanted to cash out more quickly?
Maybe because IBM would have provided a superior price, and RedHat is a public company answerable to shareholders.
Let's take reality, RedHat is still a small player compared to Amazon, Microsoft or Google. They don't have the bandwidth to compete on all the additional hosted services offerings. By partnering with IBM, they get access to IBMs entire suite of enterprise customers and hosted products, making them a serious competitor to the 3 big players instead of being a "me too, cloud". They could make it big together, looking optimistically. But it's on IBM to not screw this up.
>> Maybe because IBM would have provided a superior price, and RedHat is a public company answerable to shareholders.
I think a lot of readers probably don't understand what that line means. Even if the C-suite at RedHat did not want to do this, they have no choice. Shareholders can riot and oust you(executives) for not taking what they consider to be the "best deal"(and this is one heck of a deal). Long story short, even if you don't want to sell - once the price is high enough, the shareholders will force you.
redhat was trading at around $120 last week and IBM announced "Red Hat for $190.00 per share in cash, representing a total enterprise value of approximately $34 billion."
That $120 was really high for redhat, who just crossed the $100/share price last year. (unless you count year 2000/dotcom-IPO-madness) RHT's market cap was previously $20B.
yeah it's not raising my eyebrows but I was trying to give the data to explain why an established and somewhat profitable company (like redhat) would sell to a player like IBM. It's just a lot of money to turn down!
Guys, this is not just, or mainly not RH Linux. :(
- kernel development
- Ansible
- JBoss (I know HN hates Java, especially Java EE, but it was and is an important factor in enterprise OSS adoption)
- OpenShift
- Ceph, Gluster
All these are in danger, not just RHEL. I don't know about any other company that is large, successful, focuses on the enterprise and absolutely behind OSS. Canonical is way behind Red Hat in terms of revenue (1/20).
I don't know of any other OSS company that does _exclusively_ OSS.
Canonical, for example, has a number of proprietary solutions built around their core OSS stuff, so they function as an open core business. And they're not doing anywhere close to as well as Red Hat does.
WSO2 - an open source integration software company - is exclusively OSS. We will do $50M in sales this year with 80% of that subscriptions for on-premises open source software. We are the 6th largest OSS company by revenues. We'll probably jump up to 5th next year because of the RedHat acquisition of IBM.
Nowadays, yes. SUSE Studio was the main proprietary thing we had in recent memory, and it was sunlit a few years ago with KIWI being its successor.
As far as I know, everything we develop is free software. You can get the full sources for any package in SLES or openSUSE (which isn't really SUSE but SUSE engineers work a lot on openSUSE) using zypper.
Personally, not only is everything I work on free software, I also exclusively work upstream-first (and I maintain several upstream projects like runc and some OCI projects). To be clear, this is not a company-wide thing -- many of my colleagues do not consistently contribute upstream -- but regardless all of our products' sources can be downloaded under free licenses. In fact you can get the sources from OBS (it's what openSUSE Leap is directly based on).
Now, there are some things that we distribute which are proprietary to certain customers (think flash or the NVIDIA drivers), but these are mostly because customers pay us to repackage other peoples proprietary code. We don't develop them. Personally I'd prefer if we didn't do this, but it is a very small part of our business.
@cyphar - I would love to chat with you about SUSE's policies and encouragement to enable working exclusively on upstream-first. We are working to bake that concept into our policies at WSO2 (I'm its CEO). While we practice that in motion, we are codifying it within policies. If you could email me tyler@wso2.com, would appreciate a chat about it with your or management there.
Is openshift really open source? I was under the impression that nobody really runs origin on its own since it's far too hard. It seemed more like they just wanted to point out but it's open source, but you need support and a lot of know-how to actually use it.
OpenShift comes in two variants: Enterprise and Origin. Everything you can do in Enterprise can be done in Origin (Origin is ahead of Enterprise), but Enterprise comes with support.
We run OKD (formerly Origin, the project was rebranded) as well and have for two years in just a couple weeks. It's been a pivotal part of our application stack since we adopted it, the developers on my team love being able to paste in a git URL and have an application live in a few minutes.
It seems to me that Red Hat is based on Fedora. Fedora being the fast release gratis community version and Red Hat the slow release commercial corporate version.
Then CentOS would the community gratis version of Red Hat.
Also with RH's recent acquisition of CoreOS, that suite will also be in IBM's arena.
I work for "a corporate". We used to be big IBM shops (AIX, IBM Java, websphere, etc, etc...). But AIX is now hardly used and neither is websphere. It's mostly off the shelf k8s, wildfly and other open source projects deployed on RHEL (not my personal favorite since its kernel is way behind the times).
I think this is IBMs way of playing catch up in the arena. I worry how they will handle entrenched "political interests" - e.g. Webpshere/AIX/etc.. and the more open source friendly RedHat suite. Pretty sure its going to be one big mess in a few years time.
They _did_ pay a lot of money to acquire them, so there's a reason to believe they're committed to fully integrating RH technology. Considering Jim, who certainly has an interest in the survival of open source software, signed this off also gives some hope.
The OpenShift folks sit on a ton of critical posts in the Kubernetes project. I'd suspect this is what IBM wants, but it's a risk that they stop contributing to the open source project.
It goes much deeper than that, Red Hat maintains or contributes regularly to a wide swath of the Linux ecosystem. They also have a policy of open sourcing acquisitions. If the deal goes through, it's a dark day for open source software.
Red Hat's Open Source only approach does mean that none of these projects can be closed down, though: AFAIK, IBM are acquiring people and a brand, but no significant proprietary IP. If higher-ups at IBM turn out to be as clueless as Oracle, then key engineers will just walk and continue working on those projects elsewhere.
Where elsewhere? The landscape of options to be paid for your OSS has just become a barren field.
Yes, OSS as a concept can survive only on gratis work. However I'm not sure the portfolio of projects supported largely by Red Hat maintainers could. If maintainers are forced to start walking as they did with Oracle I expect to see quite a few projects fall into disrepair.
I guess they can start a new company and keep working on the same products. The community would have to change to their new repo's but other than that RedHat could get a new start, with a different name.
We'll see. Often talk like that is just buzzword soup. What matters to large companies like IBM is money from services, not owning the coolest tech stack. If it is clearly contributing lots of money or it has a champion in IBM they'll keep it.
In progress greenfield projects with no obvious monetisation are just the sort of thing that gets cut in this sort of merger, after the assurances that redhat will be run as a completely independent unit are forgotten and a new manager comes in looking to trim fat.
I use coreos and am now very concerned about its future.
Well over in Fedora, it is full steam ahead. CoreOS is going to be merged with "atomic" (in particular rpm-ostree style updates and layering), and then base Silverblue on that, which will become Workstation. Could all of that work just stall out? shrug Yeah sure, and Red Hat could suddenly decide they want to support Btrfs.
Red Hat could suddenly decide they want to support Btrfs
Red Hat won’t be deciding much about anything after the merger goes through. I sincerely hope you’re right though and it survives and makes money somehow.
Pivotal is probably next in line for size for independent enterprise OSS but still a fraction the size of Red Hat, at under $1b in revenue. And some proprietary bits.
Super pessimistic point of view. Why do you think these are all in danger? These are things that people and more importantly enterprises use. Why would IBM ruin that?
Sure rationally the products should be a success, that's why IBM bought them. But GloboMegaCorps have a consistent record of acquiring great products then running them into the ground by smothering them with shitty internal policies.
It seems like a fair % of SVers haven't had the pleasure of working for one of these Kafkaesque giants. They operate on dream logic and risk aversion.
Though I dedicated a few years of my life to OpenStack at HP, I sometimes wonder if OpenStack would be healthier if GloboMegaCorps didn't get involved.
> I don't know about any other company that is large, successful, focuses on the enterprise and absolutely behind OSS.
Doesnt Microsoft tick all those boxes? Even if they aren't exclusively an open source company, they are "absolutely behind OSS" if you go by how much open source code they have contributed.
How on earth is Microsoft "absolutely" behind OSS? Which of their main products is Open Source? Windows? Office? SQL Server? Azure? Exchange? What exactly makes Microsoft a company "absolutely behind OSS?"
Their stupid boot loader still ignores any other operating system for god's sake.
Kudos to people at Microsoft's Marketing and "developer relations" department who won the hearts of developers by allowing TypeScript and VSCode to be FOSS. Suddenly MS is "Absolutely behind OSS".
I work in the public sector in Denmark, and we’ve delt a lot with both IBM and Microsoft over the past 25 years.
Microsoft has been one of our best partners, including for the open source software we run, especially since Azure became their mission.
IBM has been one of the worst, so bad that I’d dread making any deals with them ever again.
I wouldn’t say MS is fully behind OSS though, they contribute a lot these years, but their main goal is still to sell you Azure. I think they won the hearts and minds with .Net core though, I mean VSC is the best ide and typescript is typescript, but the future of a lot of web programming lies within .Net core.
You are likely coloured by being in the one marked where .Net became significant and that’s mostly bacause the only accepted altilernative in Denmark’s monopoly friendly procurement systems were IBM mainframes or Oracle solutions.
Everywhere else RedHat/Jboss won the game and is being replaced by new JWM languages rather then node or .Net though node hides in strange places like the latest SAP framework.
Frontend/native .Net apps are fastly becoming extinct.
MS pretend love for Linux is more an acknowledgement that no one wants dotNET on IIS or anything windows centric in the cloud than any genuine love for Linux so they kind of have to pretend to like Linux workloads and unix tools if they want azure to be more then an niche product.
Oh we have JBOSS in our stack, it’s what handles our service bus. I’d rather we didn’t though, it’s really hard to find JBOSS developers/maintainers for public sector pay checks.
We used to see a lot more of it from our suppliers, but it seems to be rapidly going extinct. Possible because there just aren’t a lot of JBOSS developers/maintainers in general.
I am coloured by my environment of course, but I do work in software cooperatives with 97 other muniplacities, as well as a few European communities and I don’t see anything to indicate that .Net, JAVA and PHP won’t remain the dominant techs in Europe for the foreseeable future.
I like node.js, I use it for hobby projects and I genuinely think graphql is a lot better than rest APIs (and there isn’t a graphql adaptation for .Net that isn’t bad), but I just don’t see the adoption anywhere outside of what you hear from American startups.
And again, I didn’t say .Net would rule all web development , I said it would be important, and if the European public sector continues to run on .Net then it’ll continue to be a billion dollar industry.
dotNET will stay around just like the mainframes but it’s not a growth market nor the worldwide norm for enterprise web backends.
I work on legacy platforms so I know there is good money in dead technology. But that don’t make it the future.
I just don’t see any legacy codebase being rewritten as dotNET and a similar amount of new greenfield dotNET projects as new Perl project being launched due to NETs heritage as a windows component.
If I were a Perl consultant I’m sure I would say the same about Perl and my region and it’s not that long ago that IBM stopped claiming the future was still the mainframe.
The most available job in my country for any programming language is C#, followed closely by JAVA. On third place is PHP. Fourth is Sharepoint and RPA. Around half the number of the C# jobs include some kind of JS requirements but almost every JS job uses a different backend than node.
There is one fullstack JS job. Three JBOSS jobs and six DJANGO jobs.
How is it not? I mean, we’re a muniplacity, we operate around 500 IT systems, that are all moving toward becoming web apps in some form.
The core tech behind these is in 95% of the cases either .Net or JAVA.
Our in-house development has moved from .Net to JavaScript, mainly because we’re small and if our front end had to be JS then our backend might as well be, but now you have something like Blazor.net emerging, allowing for full stack C#, of course we’re going that route.
I didn’t say all, but I frankly think it’s obvious that .Net will play a big part of web development future, considering how big a part it already plays today and considering how Microsoft is moving it forward in all the right ways.
Does it JS really have that much traction on the backend? Maybe outside of Denmark, but our little department is actually one of the few places which uses Node for serious backend application in the entire country. At least that I know of.
I mean, I can go on job databases or LinkedIn right now, and there isn’t a single full stack JS job available in my entire country. There is a lot of JS including jobs of course but they all require you to also/mainly do C#, JAVA, PHP or Python because JS is almost exclusive used on the frontend.
Don’t get me wrong, I actually really like the JS environment. There’s a reason we moved to it, but it’s not like it doesn’t have its flaws either.
I think WASM will absolutely change web development, but I think it’s already made it to the is, I mean, we’re launching our first minor Blazor app this week, and it’s something we typically would’ve build with vue and graphql Apollo, but now it’s all C#.
The world of enterprise typically moves slow though. We’ve recently bought an on boarding system that’s made with web forms for instance. You may laugh at that, but the truth is, at least in my part of the world, that JS hasn’t seen that much adoption outside of hobbyists. Eventually these companies are going to upgrade their client sides, but would you pick modern JS or full stack C# if you were coming from web forms? Hell even if they go vue, react or angular chances are they’ll still use .Net on the backend, as that seems to be the trend pretty much everywhere except for us.
Does it JS really have that much traction on the backend?
I cannot speak to the whole industry as I moved to the states a year ago and my view is quite limited. But for sure Node has a lot of traction and usage in here.
However, generally, I feel developers live in their own echo chambers. For example I personally am very much connected to JS people and Linux/Open Source people. I rarely meet any ASP or Java based stacks.
I think it also depends on who you are developing for. Governments and enterprises for sure use more Microsoft or Java based solutions while startups and private companies are more "bleeding edge".
So to answer your question, I think you're right. If an organization is using WebForms, their most probable choice for upgrade is the newest offering by Microsoft. That's where they have already invested it. collectively.
But other stacks have a lot of users too. And they are not going to switch to .NET even if it becomes FullStack.
This Google Trends results [0] are interesting. Not sure if they tell us anything meaningful or not though.
I manage though, so I get to do the contracting. Mainly our software is enterprise, and it’s always either .ner or java, these days typically with an angular front.
We’re part of several muniplacity driven OSS communities though, where we buy OSS development from small startups and take ownership over project management as well as the codebase.
None of the startups are big on node.js, it’s nostly python, .net, java or php because that’s what they teach at the universities and it’s what they work with in their free time.
I think the node.js environment is great, like I said, but I don’t think it really has much adoption in Europe.
Meh. They have a bad reputation due to calling open word source software cancer the new windows business model.
Also, while their engineers are certainly smart, their software seems very crusty (the down side of infinite backwards compatibility) and usually doesn't play well at all with existing open source software. Thus: Mostly useless.
The early 2000s called and would like their objection back. Microsoft isn't that same company any more and haven't been for a long time. Sure, some of their technology is pretty awful but they definitely changed their tune around OSS.
When I worked for IBM (via acquisition), I wanted to fix bugs in Cygwin (owned by Red Hat). Red Hat does not accept patches unless you get permission from your current employer. I could not get anybody in IBM to sign Red Hat's permission slip. Nobody would sign because it's all risk, no reward from IBM's point of view.
I have the same problem in academia, being in a non-CS department, I'm required to notify the University's Center for Technology & Venture Commercialization about assigning my copyright over software to another entity (like the FSF), but so far I have been unsuccessful at getting them to sign the letter the FSF wants, despite the code I would be contributing being completely outside of my work at the University and so therefore theoretically outside of their purview. I suppose the moral is that all large organisations converge towards bureaucratic processes that waste the time of high$/hour employees and attempt to hinder all not immediately commercialisable progress.
Come to Sweden then :) As a researcher you explicitly own the rights to any foreground, i.e. results, as stated by law — the so called teacher’s excemption.
Might be, but in general the attitude and laws surrounding ownership of code (and most anything else) is very different in Norway, and I would assume Sweden. Here anything you make is explicitly yours and you have full ownership over it, even if you made it on company time. I've talked to several larger IT firms in Norway about this and they all have said that it would be suicide to force their employees to sign away their rights to personal and side projects, but that it would also more or less be impossible to enforce.
> I suppose the moral is that all large organisations converge towards bureaucratic processes that waste the time of high$/hour employees and attempt to hinder all not immediately commercialisable progress.
All large organizations have a decent amount of bureaucracy around copyright and IP, but the difference is good ones make it easy and straightforward for employees to go through that process.
Google, for example, has a well-documented and clear process for contributing to open source software (both in work hours and in personal time): https://opensource.google.com/docs/patching/
My contract requires that anything I develop using University resources, which in practice means potentially anything in my areas of specialisation, the University has some claim on.
It's not entirely unreasonable - imagine someone in Biochemistry developing some drug using University labs etc. and then turning around and selling the formula to a private lab.
But it's the petty bureaucratisation which is infuriating. (And usually the people making the decisions aren't practically qualified.)
While I was working as an assistant researcher three years ago, my contract also considered all research-derived knowledge uni property. In this case, pretty much anything tangentially related to HTTP performance enhancements would have been claimable by them.
GPL is a license applied to a work by the copyright owner after (or at the time of) creation. It has nothing to do with authorship of the work and who owns the copyright.
To elaborate, even if GP developed code as part of a GPL project, the copyright owner could prevent him/her from distributing that code to anyone else, whether that distribution occurs under the GPL or any other license.
It's the standard in many universities and many countries that consider the university your employer if you have a full time equivalent dedication, even if the university only considers you under some kind of stipend or scholarship.
Only if it is directly related to your research under office hours and is done solely by your university. If you use the university laptop to do some OS at home it is not, though in the US it could be and usually is.
I totally understand that large organisations don't want to sign papers about things that are none of their business. It's ridiculous that they need to sign them. This shouldn't be a requirement for Open Source contributions. But with some businesses claiming their employees' unrelated work done in their free time, I can see how this has become a necessity.
It's harmful for open source, and a terrible situation that's not to anyone's benefit. I guess US law should make more clear that employers don't own their employees' private work?
It's not only owning the outcome that is the problem, if you develop a software system that in any ways competes with your employer they may have a reason to fire and/or sue you.
The problem as someone else stated above in this discussion is that with a company the size of IBM it is hard to do anything that is guaranteed not to compete with anything they do.
I always imagined it stems from historical experiences where staff ran off with ideas that they were paid to have within the scope of their employment. So perhaps this is the only way employers have thought of protecting themselves against that. Ie., what other way do we have to offer them?
I doubt it, but that's not the issue. The issue is that the FSF wants a signed "ok" from the University that I can assign copyright to the FSF, and the University's Center for Technology & Venture Commercialization won't issue that. I'll wait a year or two until I'm (hopefully) tenured and then press the issue again.
If I were sure it's ok and the university/company is not going to be mad at me I would just publish my code as public domain and let whoever can make use of it decide on themselves. Perhaps some FSF-approved developer would pick the code up if it is useful to them.
In some courses publishing coursework on GitHub can break academic integrity rules related to plagiarism. It’s hurt students as more hiring processes assume portfolios. CS departments are behind the times.
For a lot of those courses there's pretty much one way to solve the coursework, so all solutions are pretty similar. It's practically impossible to tell the difference between an original solution and a copied solution with the variables renamed and some code moved around. Or the student can look at the solution and reimplement it themselves, without solving it on their own. Sharing solutions can even get you expelled in many unis.
I'm going to suggest that it's on the universities to find a way around that problem. It's a real problem, but everything being publicly available online is how the world is now. Just varying assignments every year should be enough. If reasonable variations don't make the assignments challenging enough? Well the students are always going to be able to find some reasonable variation online. Starting from absolute scratch is just not a thing anymore in most fields.
It should be on a student to choose whether or not do they want a challenge, what particular aspect and what degree they'd like to be challenged in. The job of an educational institution is to educate, whoever interested can easily invent a challenge for themselves or use an old challenge without looking at ready solutions if they so desire. Forced artificial challenge policy is questionable.
It appears that this is one of those issues that polarizes people very strongly into one of two possible options. My response to the complaints above is usually "tough luck", because I do not see it as my task to ensure that other people cannot cheat. In fact, with today's availability information, I'm certain all those that want to cheat can and will do so easily, no matter what.
This leads me to the conclusion that the fundamental problem is actually the conflation of two very different purposes which are often at odds: teaching and certification. Universities try to do both and it often ends very badly. Certification should be removed from universities and put into separate, specialized organizations.
This is also a major obstacle towards open science, and one that the open science community seems generally unaware of. Every day there seems to be another journal article extolling the virtues of data-sharing and imploring other researchers to share, but very few folks seem to treat the elephant in the room, which is that universities have no motivation to allow their researchers to release data for free and potentially relinquish valuable IP.
I'm a current IBMer, and there is a process for getting CLAs signed - it's a bit bureaucratic if it's not a CLA for a company we already work with, but otherwise IBM has no problems with contributing to projects like that.
I left IBM a few months ago, but I led a bunch of developer advocacy efforts for a couple years.
There are several internal programs at IBM that enable employees to make contributions to open source with very little bureaucracy. Go to the intranet site w3.developer.ibm.com for details.
Deeply regrettable. One of my colleagues identified and fixed an issue with Duplicity while he was working on a backups subsystem for our server estate, and after a quick check with a Director I was able to sign off the work for release back to the Duplicity project.
This actually seems like fair policy to me, think of the mess Red Hat would be in if IBM decided that they had copyright on your contributions to Cygwin.
Many employers have clauses about owning any IP you produce while employed there, regardless of whether or not it involved company time or property. Whether said clauses are actually enforceable varies from location to location.
I think that, if you were to ask open source maintainers, "What would you think of me committing fraud to get around your project's policies?" most of them would say, "Thanks, but no thanks."
You'd be surprised. I have first & second-hand experience with the maintainers of GNU projects just agreeing to accept patches on the sly and commit them as themselves with the consent of the submitter because the submitter can't be bothered to sign a copyright release form.
I do understand your point, but I wouldn't spin it that way or bring it up with them, just start committing using a "new" identity, assuming they have no knowledge of your "main" identity.
That dishonesty is exactly what makes it fraudulent.
They're asking you to sign some legal documentation. If you forge a signature rather than getting it signed by your employer, that's fraud. If you create a false identity in order to hide the fact that you have an employer, that's also fraud.
You have exactly two legal (and, just as importantly, honest) options in this situation: Get permission from your employer before contributing, or don't contribute. If you like the project and don't want to create trouble for its maintainers, you will pick one of those two options.
The reason this permission exists is that contributions will not be owned by your employer, but will be part of the project. It depends on your employer if they allow you to work on personal software that they do not claim ownership for or not. I think you are right to not use a pseudonym. I once did, and regret having done so.
It depends on the type of CLA. There are many CLAs that do not imply copyright assignment, it's just legalese to make sure that you are taking liability for making sure that you have the right to add your contributions to the project -- basically a longer-form version of the Linux DCO.
In those cases, your employer would own your contributions and thus you need permission from them to license their copyrighted work (your changes) under whatever the project license is.
But in any case, contributing under a pseudonym is something that you should think about very seriously. This has been done before in the Linux kernel and luckily nobody got sued over it, but it is basically copyright infringement mixed with various levels of fraud and deception. Don't do this to us poor maintainers.
> In those cases, your employer would own your contributions and thus you need permission from them to license their copyrighted work (your changes) under whatever the project license is.
How does your employer own what you do in your free time? AFAIK there is no job contract like that which is legally enforceable. At least in California.
It depends on the country. In some countries, work related to your job but done outside work (or work using company resources like a company laptop -- I believe in California this is also the case) might possibly be owned by your employer (if your work contract says so). For instance if you work on databases and in your free time you developed a really awesome database from scratch, that might be owned by your employer because of the training and learning resources your employer provided (I think this is the reasoning -- but personally I find it quite abhorrent).
But I assumed that GP was talking about wanting to contribute something they did on work time, not on their own time.
It's jurisdiction by jurisdiction. And even if it's not enforceable, it might still be very expensive to duke that issue out in the courts.
Worrying about these details is the last thing a project maintainer needs to be worrying about. Easier to just require everyone to have a belt, even the ones who say they own suspenders.
Well, the permission exists to ensure that the contributions will be owned by the project and not anyone's employer.
If that permission isn't secured, though, and the employee has a contract with their employer that signs ownership of some or all of their off-hours work over to their employer, and the employer decides to try and exercise those rights, then it's anyone's guess who the real owner would be. Might vary by jurisdiction. Might be down to whether the open source project can afford to lawyer up in the first place.
Given all that, a FOSS project isn't unwise for asking for a permission slip. You could argue that it's being over-cautious, but that's the project maintainer's decision, and it deserves to be respected.
Contributions can be owned by employers and things still work. That's how Linux development works for instance, and the DCO is arguably a similar "permission slip" (though it mainly depends on the honour system with contributors just asserting they have the right to contribute). Some CLAs are very similar to the DCO (for instance, the Apache CLAs or the Google/Kubernetes ones).
A very interesting point. I think it's fraud. You're doing it for (potential) monetary gain. Not your own, but the ownership of copyright which you're claiming and reattributing on behalf of your pseudonym. Still fraud, I suspect.
I haven't used Windows in quite some time, but I believe they are quite different. WSL is more like a very basic version of Wine in that it implements Linux system calls and can execute ELF binaries, and as such requires you to install a host OS for libc and any other libraries you want. Cygwin is more like Winelib in that it provides a custom libc implementation and toolchain that are natively compiled, and as such requires you to rebuild your applications.
My understanding of WSL is that Linux software runs natively on Windows by virtue of a compatibility layer. Eg. if there is a fork() in my code it will be translated into CreateProcess() or something like that.
I have always been curious on how WSL differs to coLinux or andLinux ( http://www.andlinux.org/ )
About 10/15 years ago I used andLinux to have a Linux shell and other apps inside Windows. It was really good and it seems ahead of its time, as it was not virtualized.
Wine is a lot broader in scope than WSL, while Microsoft is fine with implementing a kernel-level ABI and then shipping a download for an Ubuntu userspace, Wine cannot ship any official Windows components. They had to re-implement every important DLL from scratch in addition to the ABI.
I can see why you would think that, but there is a reason that many think the opposite. Wine is obviously less compatible than WSL, but it is also a much more ambitious project. For WSL to work, it "only" has to implement the kernel translation layer and then run the various userspace tools that Linux does (GNU tools, Gnome, etc).
For Wine to implement even enough to run Notepad, Wine needs a reimplementation of huge portions of userspace. Of course, this also means it is a little bit of an Apples to Oranges comparison.
Perhaps you're right, maybe WSL can do all the job nicely so maybe there is little if any point in developing cygwin. I have never tried it to be honest. I just prefer Windows 7 and loosely-integrated solutions - a 3rd-party Linux in a box feels better than a Microsoft Linux in the Windows kernel (yet just using a VM doesn't feel great for performance reasons and beacuse of not rally seamless file system integration).
Honestly I probably would have just scribbled a name in a terrible hand writing (not hard for me anyways) and called it a day. They just wanted something on file that would never be looked at again.
I don't think in the short term this will be a problem. However IBM has lost it's way. its a very large unwieldy organisation that doesn't change very fast.
It also has an awful lot of lifers, who would flounder horribly outside the soft warm IBM shell.
But, there are some brilliant engineers and technologies that are inside IBM. The ones I know are about are to do with GPFS, which is a shining beacon compared to ceph and gluster.
A clever organisation _could_ mix GPFS, the vast experience with scheduling and resource allocation, and second to none documentation (have you read a Red book? they are marvels of readability.) to make a spectacular platform. One that unlike K8s would be easy to use, understand, tune, script for and run.
They won't be able to execute it properly, but they have the potential.
I definitely agree with you. I’ve been paid more or less to run GPFS over the last 15 years or so (finally free of it for the last few months), and while I hate it with a searing passion, a) it’s far better than the alternatives as long as you can afford it, and b) the people who lead and do the real work on the project are very, very bright. If they keep these people working on hard problems, they’ll do well. If they try to replace them with inexpensive staff, it will fall apart in months.
Parallel POSIX-compliant filesystems at scale are an astonishingly hard problem, and adding the feature set they have while keeping it relatively stable and performant is really worthy of admiration. Every one of the dozens of conversations I’ve had with their developers and technical leads have left me more impressed. They literally can’t test it internally at the scale that their large customers run it, but they’re really good at finding problems and pushing out hotfixes that work pretty well.
That said, if I never have to touch it again for as long as I live, I’ll be a very happy man. From an HPC perspective, I think we’re long past the scale where parallel filesystems should be POSIX-based.
At the risk of topic drift, I'm curious where the problems are with being parallel and POSIX-compliant. I'm at a point where I think I need to consider a parallel file system and I don't have much experience with them, so I'm not aware of the issues.
Basically every time that POSIX makes a guarantee which is difficult to fulfill performantly in a distributed environment.
* Some directory operations require an atomic update to 2 different inodes, confounding sharding strategies and requiring some form of global synchronization.
* write() -- write syscall guarantees that when it returns, the filesystem will serve all future read() calls appropriately, with the contents of the write. This matches up poorly with big streaming writes -- in order to fulfill the spec, you need all these giant pockets of latency waiting for an ACK from the remote host, instead of just streaming it all and getting one ACK at the end.
At least on the real big systems, most of our work was with a small number of research groups basically doing the same workflow: start your job, read in some data, crunch, every 15 minutes or something slam the entire contents of system memory (100s of TB) out to spinning disk, crunch, slam, your job gets killed when your time slice expires, get scheduled again, load up the last checkpoint, rinse, repeat. Because of the sheer amount of data, it’s an interesting problem, but you could generally work with the researchers to impose good I/O behavior that gets around the POSIX constraints peculiarities of the particular filesystems. You want 100,000,000 cpu hours on a $200M computer? You can do the work to make the filesystem writes easier on the system.
Coming into private industry was a real eye-opener. You’re in-house staff and you don’t get to say who can use the computer. People use the filesystems for IPC, store 100M files of 200B each, read() and write() terabytes of data 1B at a time, you name it. If I had $100 for every job in which I saw 10,000 cores running a stat() in a while loop waiting for some data to get written to it by one process that had long since died, I’d be retired on a beach somewhere.
The problem with POSIX I/O is that it’s so, so easy and it almost always works when you expect it to. GPFS (what I’m most familiar with) is amazing at enforcing the consistency. I’ve seen parallel filesystems and disk break in every imaginable way and in a lot of ways that aren’t, but I’ve never seen GPFS present data inconsistently across time where some write call was finished and it’s data didn’t show up to a read() started after the write got its lock or a situation where some process opened a file after the unlink was acknowledged. For a developer who hasn’t ever worked with parallel computing and whose boss just wants them to make it work, the filesystem is an amazing tool. I honestly can’t blame a developer who makes it work for 1000 cores and then gets upset with me when it blows up at 1500. I get grouchy with them, but I don’t blame them. (There’s a difference!)
But as the filesystems get bigger, the amount of work the filesystems have to do to maintain that consistency isn’t scaling. The amount of lock traffic flying back and forth between all the nodes is a lot of complexity to keep up with, and if you have the tiniest issue with your network even on some edge somewhere, you’re going to have a really unpleasant day.
One of the things that GCE and AWS have done so well is to just abandon the concept of the shared POSIX filesystem, and produce good tooling to help people deal with the IPC and workflow data processing without it. It’s a hell of a lot of work to go from an on-site HPC environment to GCE though. There’s a ton of money to be made for someone who can make that transition easier and cheaper (if you’ve got it figured out, you know, call me. I want to on it!), but people have sunk so much money into their parallel filesystems and disk that it’s a tough ask for the C-suite. Hypothetically speaking, someone I know really well who’s a lot like me was recently leading a project to do exactly this that got shut down basically because they couldn’t prove it would be cheaper in 3 years.
You are of course very correct that if you have a massive number of processes using files for IPC, things will fail in very strange ways.
One of the very positive things that AWS/GCE provide is simple scalable primitives, with obvious metrics to measure limits. For example SQS is a brilliant primitive for many-many message based processing. It avoids the horror of running a HA kafka queue(or worse).
_most_ object storage is actually used as a pseudo filesystem (ie S3 et al) because a shared, fast & reliable filesystem are vanishingly rare.
Apart from openstack (and I've never seen a successful deployment of it outside of rackspace) most use cases I've seen involve either bolting on a NFS head, or some other filesystem to ceph and serving it publicly.
which is frankly not all that great. I like the _idea_ of ceph, but I don't want to have to support it. Like Nexenta, it seems great, but it soon hurts during crunch.
What I like about GPFS is that it allows you to join up large amounts of block storage, regardless of the underlying fabric.
Everything has a hook, so if a file has been created/updated/moved/deleted/metadata changed, you can attach a script to that action. There is an inbuilt HSM, which allows you to shuffle files about based on their content: raw footage? move it to the spinny disk array, final deliverables? move it to the storage based in the other country. File bigger than 1TB, and hasn't been touched in two weeks, sure you can kick it out on to tape.
crucially because its all one name space, the end user doesn't have to care about where the file is, the system takes care of that based on rules.
The best part is, there are no special tricks needed for the end program, its just standard file io.
However it is one global system, which is it's downside. for pure uptime its better to have an array of file servers, to limit the blast radius, but then you don't get the goodness
GPFS is excellent as a clustered filesystem backing a number of servers that need high-throughput, low latency, coherent storage. It's block-oriented.
Ceph is a SAN replacement: can saturate 100 GBps switches with massive parallel throughput. Object based, can also serve up block and (recently, with limits) cooked filesystem.
Gluster is a distributed filesystem - easy to set up and configure, some performance limitations, file rather than object or block oriented.
I'm referring to the FS primitives. GPFS presents a POSIX FS, but it's primitive is blocks. Ceph is an object primitive (RADOS) and can present it a number of ways. And Gluster is based around files as primitives, which gives some interesting strengths and weaknesses.
Lovely idea that won't be possible. All that brilliance and inspiring leadership from Red Hat will be overwhelmed by the tsunami if indifference that is IBM corporate culture. On the plus side, if you're looking to hire real OSS talent for your team, I suspect a bunch of Red Hat folks will be on the market as soon as their contractual lockups expire.
Ugh I hate their sales. There was a day they decided to spam my cell phone number constantly while I was on lunch. Not even sure how they got it, but I finally answered and got super angry with the other end. I didn’t even know it was Red Hat because they didn’t even bother leaving messages. Just back to back to back times 4 calls. Even if it were my work number, if you didn’t get through the first time, spamming my line isn’t going to get you there either.
Given that IBM are after the tech and will probably reject the culture (as also happened when Oracle ate Sun), I suggest an appropriate name would be...
...promising everything and delivering half of that at best...
I work for a company driven by sales people. It sucks. They keep promising things we don't have and complaining that engineering can't deliver. IMHO a good sales person should be able to sell what we have. Any jackass can make empty promises.
Sales people typically do exactly what they're paid to do - no more, no less. You can shout at them 'til you're blue in the face about overpromising, but, if you've got their pay structure set up such that they can earn more commission by making wild promises, then they're going to keep on making wild promises.
Make them do proper accounting, an empty promise costs more engineering dollars than a believable one, and the difference should not be determined by sales.
The sales process needs both rewards (commission) as well as punishments (commission loss based on unmet delivery). The idea, "As soon as the contract is signed I should get my money." is a broken one as it reinforces the type of behavior that leads to unrealistic promises being made. The 50% at signing and 50% at delivery model is better for this reason. Yes, there would need to be additional language surrounding what an "unmet delivery" would be and how it would be gauged with relation to promises made during the sales process.
That's a positive scenario but I don't see Ginni Rometty relinquishing control voluntarily. The IBM board has given no signs of dissatisfaction with her performance.
IBM is sliding into irrelevance in the mass market for sure, but they've still got a sizeable slice of the HPC/supercomputing market and their research in quantum computing is hard to overlook.
I work in HPC, and, well, it's VERY hard to make a good profit there.
- Customers are stingy (think academic labs, supercomputer centers etc.), are not typically married to your solution architecture so for every purchase they will put out a tender that you have to bid for and win.
- Performance is king, which means very expensive R&D, and customers don't spend much on all these "enterprise value-adds" that enterprise focused businesses use to pad their bottom lines.
> If IBM has one brain cell left, they'll pull a NeXT/Apple merger and let Red Hat executives start running the combined company.
Honestly, I could see that happening and working out great .. for legacy IBM customers. But if you aren't an existing IBM mainframe/midrange shop, there will be only tangental benefits for you.
To go with your Jobs analogy, the original iMac was all about preserving legacy Mac users. The new customers had to come in from a different angle. Does either RedHat or IBM have the angle?
IBM is, as far a I can tell, the best example of a "mixed bag" in tech. I have heard both great and terrible things about IBM from customers, employees, developers on Open Source projects, etc. They are a huge organization, and one that seems more divided than many.
It may be more useful to view IBM as a collection of fiefdoms rather than a single, focused, entity. Yes, the money all goes into one pot at the end of the day, but there's large variance across organizations within IBM.
That said, from what I can tell OSS that goes into the IBM machine doesn't usually come out the other side improved. I worry for the health of CentOS/RHEL/Fedora under IBM's leadership. My desktop and server OS of choice, with a few brief forays into other territories along the way, has been from Red Hat for 23 years. I'd hate to lose Fedora or CentOS, or see them stagnate. Red Hat has been among the most steadfast in their support of Open Source software, as well...so, there's a real risk of the kernel, Gnome, and other OSS core infrastructure suffering, because Red Hat is a major contributor to those projects.
I don't think it'll be sudden. It usually takes years for projects to become clearly worse for having come under IBM's purview. Red Hat is large itself, and will probably take years to be fully assimilated and homogenized into IBM's lukewarm culture of mere competence with regard to their Open Source contributions.
On acquisitions, I can offer the anecdote of a friend working at a startup IBM purchased.
Things started with "IBM loves you, and pledges to stay hands off and help you do what you're already doing", continued to "We're going to replace a few management positions with folks from IBM" and "We're changing some benefits, titles, and procedures to better align with The IBM Way", and finally ended up with "You aren't meeting your sales targets, so we're going to overhaul your leadership."
Admittedly, this was a much smaller company than Red Hat. But they were profitable before being bought and had a respected product and growth.
That sounds about right. And, I suspect it'll happen to Red Hat, too, despite the fact that Red Hat is a money printing machine. They've been literally unbelievably effective at turning open source into profit (as someone who's tried to make money on building Open Source software for roughly 20 years, I find it difficult to comprehend how much money Red Hat makes). I've even occasionally considered applying at Red Hat a few times over the years (and have on a couple of occasions been encouraged to do so by people within Red Hat), just to get a direct view of how they do it.
But, IBM is a different beast. They make a lot of money on Open Source, too, but they're not a software company. It's ancillary to their core competency, and so when software goes in, it seems to eventually become a meandering bloated and bulbous creature without a clear purpose or direction, and most of the really smart people seem to leave within a year or two.
The old saying, and who knows whether or not it's true, is that this was basically the deciding factor in Sun deciding to sell out to Oracle v. IBM.
Supposedly both companies had bids out on Sun, with Sun's leadership believing Oracle's tighter business operations would result in fewer layoffs and ultimately less harm to the staff then at Sun. If true, that seems like it mostly turned out to be extremely naive, since Oracle immediately locked down whatever they thought they could sell and cut off everything else.
To be honest the only way Red Hat selling out would've been more disheartening would've been if it was Oracle making the rounds again. I think I'd be happier about an MS acquisition than IBM. Weird, sad stuff.
Was it naive? Seems Oracle boosted investment in Java after the acquisition, at least. The stuff they cut were all dead projects walking anyway, eventually those projects were going to go no matter what Sun's fate was.
Aww.. I would have loved MS buying them. That'd actually make a ton of sense, and we would probably give them autonomy, like we've done for LinkedIn and GitHub.
Isn't it how pretty much any acquisition goes? That's my experience from the inside anyway. All hell breaks loose once the golden handcuffs have expired (3 years mark usually?) and people including management can quit with a full payout.
That lines up very closely with the experience of some friends who sold their (growing rapidly, highly profitable) startup to IBM.
It took a few months for them to realise their startup was going to languish completely within IBM, and their destiny for the 2 years after acquisition was to sit by quietly and wait for their payout, while looking for the next thing to do.
Any time & effort they put into trying to grow their startup product's future within IBM was going to be a waste of everyone's time. This was a hard lesson for them to learn post-acquisition, but I think the money in their bank accounts 2 years down the track will help them get over it
I really don't understand the point of this anecdote.
This is standard practice for almost every acquisition. If the startup didn't want to be part of the IBM way of doing things they shouldn't have agreed to be acquired by IBM.
In fact the rare situation was the Facebook "acquire but treat more like an independent subsidiary" model. And even that didn't last all that long.
> If the startup didn't want to be part of the IBM way of doing things they shouldn't have agreed to be acquired by IBM.
In this situation, I don't think it makes sense to think of an organization as a single, monolithic entity. In this context, the only sane way to think about Red Hat is as over 12,000 employees, plus I-don't-know-how-many shareholders.
Only a very small number of those "agreed to be acquired by IBM". Probably less than 0.1% of them. They are probably also going to be the ones who are going to be the least affected by how IBM operates internally. They've now got FU money, so, as soon as whatever retention agreements they may or may not have signed expire, they'll be prancing out the door.
Everyone else probably knows very little about it - the linked press release indicates that this is probably a surprise for about 12,000 Red Hat employees, most of whom won't be getting any additional details until tomorrow's all hands meeting.
management and the board
agreed to the deal. Companies are not democracies , while it is nice to have grassroots approval , it is a top down process. the very nature of these transactions make it impossible to disclose until it is done.
Ultimately in a decision like this the board has only one entity to consider -shareholders , if they believe the deal will create more value to shareholders they should consider it
Value maybe subjective Of course shareholders could be against for ideological reasons and prefer not take the money, that doesn't seem to be the case here.
While I agree with you that decisions of this nature are made top-down, the value in RedHat is its employees (as RedHat sells support for Open Source software). If a mass exodus occurs because of this acquisition, RedHat will no longer be providing value to the shareholders and will become a long running debt with no future in the black on IBM's books. It is quite possible that IBM will fail at properly handling RedHat after the acquisition due to entrenched business culture that is incapable of grasping the cultural change required to support a business model such as the one that RedHat employs. Business often appears as a bedfellow with economics with regards to ignoring the "human factor".
Re: "Importantly, Red Hat is still Red Hat. When the transaction closes, as I noted above, we will be a distinct unit within IBM and I will report directly to Ginni. [...] They understand and value how and why we are different and they are committed to allowing us to remain Red Hat while scaling and accelerating all that makes us great with their resources."
Yeah, we moved out of SoftLayer soon after that acquisition, as well. They just weren't as interested in the kind of (small) money we spend and it showed.
We were a Softlayer customer for dedicated servers before the acquisition. Afterwards, we needed to add additional servers, and IBM wanted 50% more for the same config, already quite high (twice as much as we pay elsewhere). When we needed to increase the RAM from 16GB to 32GB, they wanted $50/month for a stick of RAM that costs about $100.
It's like they are using cloud pricing as a reference for dedicated servers. We run dozens of dedicated servers, and using the cloud would be 10x the cost. Amazon at least has a culture of passing on cost savings to customers.
There was a problem with a server, and I needed to connect to the console. That involved using a VPN, then downloading a Java applet with a very specific (obsolete) version of Java. The applet didn't support copy and paste, and frequently repeated keys. Try typing in a 16 digit randomly generated root password by hand with your keyboard duplicating keypresses. Linode can offer a console over SSH, why not IBM?
"then downloading a Java applet with a very specific (obsolete) version of Java. The applet didn't support copy and paste, and frequently repeated keys"
Ah, yes, Lantronix Spider. My current colo still uses that old bastard. It's the only reason I still have Java on one of my laptops. And, now that our colocated servers are getting old and crotchety, I'm beginning to think it's not worth it and considering moving out to some cloud-based thing (but to keep costs down we'd need to reimplement a lot of stuff, because "big box with a bunch of services running" is outrageously expensive on the major cloud-based virtual machines, compared to ~$100/month to stick a fat server in a rack and get a gigabit pipe plugged into it).
In their latest quarter https://www.ibm.com/investor/att/pdf/IBM-3Q18-Earnings-Chart... $4.1b of revenue came from Cognitive Solutions (mostly solutions software) at a 76% gross profit while their global business services with the same revenue had a gross profit of only 29.8%.
By the way, they spend $1.3b on RD&E while their net income is $2.7b.
Is "Cognitive Solutions" mainly their AI efforts? [1]
If that's the case, and given the terrible feedback they've received from many of their Watson customers (and anecdotes from people working on it)... I am tempted to say that the future is bleak for IBM, and that people will ultimately discover that they were paying a fortune for something that does not match what's advertised (they've put millions into advertising Watson with nonsensical ads)...
...but then again, many enterprise solutions that are incredibly over-engineered, slow and costly are still alive and kicking, so who knows.
Cognitive Solutions is nominally their AI solutions but actually includes a lot of legacy enterprise stuff put in that basket to make the numbers look better. Wall Street analysts don't dig enough to publicize any of this fiddling.
Their iSeries service isn’t bad as soon as you get by the screening person whose grasp of English leaves a lot to be desired. Talking to one of their actual techs has solved everything I’ve asked. It does probably help that machine phones home when it needs parts replaced.
I don't have any contacts with IBM business-wise, so my question might sound naive: Why 90% services revenue would be a problem? They have to fund these R&D and open source contributions somehow.
Because literally every conversation turns into a services upsell.
I've migrated a site from WAS to JBoss. The support experience is night and day. WAS on IBM OS on IBM hardware not working? Pay a four-figure-per-day consult to be told that's just how WAS works on that platform, buy more hardware.
Same application on JBoss, problems with performance, RH dropped experts in as part of the support contract.
This is not a one-off in my experience. RH, Microsoft, other vendors I deal with treat a lot of these things as covered by your enterprise support contracts. IBM treat it as a chance to upsell a services engagement, and maybe pitch that the work should be outsourced, too.
Maybe for hardware. There are pretty good about hardware support. At two companies I worked at we got people sent to us for on-site repair.
Their software support is something else. I haven't had to use IBM tooling in a while, but back when I did, everything they sold was absolutely fucking terrible (DB2, RAD, WebSphere, Clear Case, Tivoli) compared to many open source equivalents.
The only reason people buy this rubbish is because they're in an old company (bank, insurance, etc.) that has relied on it for ages and don't care about the inefficiency or cost.
> Their software support is something else. I haven't had to use IBM tooling in a while, but back when I did, everything they sold was absolutely fucking terrible (DB2, RAD, WebSphere, Clear Case, Tivoli) compared to many open source equivalents.
Over 20 years in contracting that's been my experience too, utterly lazy, awful software - awful UI, continuous license issues, buggy, juggernauts of bloat. WSAD (Eclipse + Websphere plugins) was easily my worst experience with an IDE, ClearCase easily my worst experience with a SCCS etc. I pity people that have to work with any of it 9-5.
The banks and insurance companies I've worked at had support contracts, but they were useless - you more often than not just had to suck it up.
To be fair, there are AAA teams even in global services. I believe I worked with some guys from the Hong Kong team that were !@#$ing amazing? But they were supporting a major bank.
IBM in general seems fairly aware of who their best teams are, and you're probably not going to get one of those teams. (Unless you're a huge account and/or the project is in dire straits)
In my opinion: Either invest in developing hacker news support for updated news comment threads better (my recommendation is to split each thread by the original article/time in a megathread and use the newest title for the base merged thread and sort the sub-threads by time or stop merging these threads because it makes it so freaking confusing as the comments are based on totally different contexts and yet they are all intermingled.
Prime other example being the tesla going private thread which I think is this one but I'm not sure because the threads are so hacked together or duped I cannot find a hacker news link to the original tweet [0].
This happens whenever a story is changing rapidly. It doesn't have to do with merging the threads—it has to do with different comments dating from when different information was available. In this case the initial story was "might acquire" and then turned into "has acquired". The threads weren't neatly partitioned before we merged them; people just post to whichever discussion they happen to see.
When a story has been changing while the comments have been accumulating, HN readers are smart enough to figure it out, and I'm not sure adding new software would help much.
The threads were neatly partitioned because they were all based on an initial source of information (the source article), but it was then merged into one mega-thread contained conflicting sources and thus it makes it confusing since all the comments which were based on different sources are now intermingled.
Also, auto-hiding my original comment? All I am trying to do is give some personal feedback in how you guys can improve your website and your response is to try and censor me? Let the other hacker news readers decide by voting considering that that is literally one of your companies essential startup advice: "For any company, software or otherwise, this means that in order to make something people want: you must launch something, talk to your users to see if it serves their needs, and then take their feedback and iterate" [0].
Not to disagree with you, because I understand your point of view, but for me the hiding doesn't come across as censoring so much as marking as "off topic, meta discussion".
People who care about that kind of thing click through and read it, otherwise it lets people skip over to read comments about the article.
I think it's reasonable to expect HN readers to realise that threads have been merged, but it can be difficult to track down the article in question all the same.
Whilst complex threading might seem to counter the simplicty of HN, might it be reasonable to include a link to the original article when merging?
Ay ay ay... if this is true then everything from RH is gonna get fatter, slower and more expensive.
Add a bit of WebSphere here, a bit of Domino there and voila. It'll then be ready for 'resource action' (aka layoffs).
Jokes aside, RH is an engineer-focussed business - IBM is an accountant-focussed business. There's just NO way these two cultures are going to work well together.
It's like Vader asked Luke to join him in defeating the Emperor (Microsoft) and ruling the galaxy as father and son - and instead of the audience hearing "I'll never join you!!", we hear "sure, let's team up."
The cognitive dissonance is so strong here. WTF just happened? If you asked me a month ago to put down serious money in Vegas on this never happening, I'd have happily done so. What on Earth were they thinking?
IBM is basically taking it's failing Kubernetes distribution, saying "why lose when we can just buy the winners?", and went ahead and bought Red Hat and OpenShift instead. A year from now, we'll start to see heavy IBM integrations into OpenShift, radically increased licensing fees for RHEL to squeeze every penny out of enterprises which bought RHEL specifically because they need the support guarantees because they can't migrate away quickly, and every other Red Hat project - Ansible, Cockpit, Fedora, CentOS, etc., will get torn to pieces by IBM bean counters.
Ditto, I can almost guarantee I'll be in a meeting in the week or two where my directors will want to discuss the possibility of moving off of Redhat, at least as a contingency plan.
"Do not fall into the trap... of anthropomorphizing Larry Ellison... If you put your hand inside a lawnmower, it will get chopped off. The lawnmower doesn't care... The lawnmower doesn't want to kill open source. The lawnmower just can't think about open source. The lawnmower can't have empathy."
The boilerplate and vague statement of Red Hat remaining a distinct unit doesn't really tell us anything. More relevant is what the CentOS and Fedora communities think of this acquisition, because no matter what they are community driven projects.
There are two coins to toss: whether IBM reaches into Red Hat in a way that kills off either project; and whether enough of the community steps out.
I'm curious what openSUSE folks think of SUSE having been acquired by Novel, then Attachmate, and then the Micro Focus merger. They've been through a lot, and openSUSE is still here.
Conversely, I wonder what this does to the Linux ecosystem. It looks like at this point, Debian and Arch are the only major self-sufficient distros (i.e. not built on top of another distro) that are still community-owned and community-driven; and of the two, Debian is clearly more broadly popular. So, will this result in Debian becoming the de facto standard of "open Linux"? This could make things interesting when it comes to packaging etc.
well, that’s basically already happened. with its strict adherence to GNU, and with the truly phenomenal number of distros based on debian (especially if you include ubuntu derived distros, but ubuntu is so different these days that idk if it’s really the same any more?)
Is it really so different though? It feels like it's been converging if anything, what with Ubuntu on systemd these days, and moving from Unity to Gnome Shell. What are the substantial differences at this point?
None of these qualify as "mainstream" compared to RedHat/CentOS/Fedora and Debian/Ubuntu. Even SUSE, which used to be in the big league, is a shadow of its former glory.
If you look at what runs on production servers, it's virtually always RHEL/CentOS, or Debian/Ubuntu. Everybody else isn't even above 5%, and most of those you've listed are in fractional digits.
For another data point, if you look at websites, Debian+Ubuntu is already >50%. At this point, I think it's well on its way to becoming the Linux distro, with everything else being relegated to the hacker/boutique niche. And I think that this announcement, and what IBM is likely to do with RHEL afterwards, will accelerate that trend substantially.
Shame. As far as I can tell OpenSUSE & Fedora are on the same level. I often struggle deciding which one to install on new servers because I love them both so much.
Regarding openSUSE (I work for SUSE so obviously don't speak for the wider openSUSE community, just my 2¢ as a contributor):
While people do have a reasonable level of hostility over the Novell acquisition (which has left some deep cultural scar tissue within SUSE), they did give us openSUSE.
Overall there is often worry when we have an acquisition (since a very large portion of openSUSE maintainers are employed by SUSE). With EQT quite a few folks were worried about how separated the finances were between openSUSE and SUSE and I believe Richard Brown commented on how exactly he's pushing for better financial and trademark separation (the only two things that they really share anymore).
So while people do get worried every one in a while, I get the impression that overall things are going okay despite the series of acquisitions in recent years.
However, Fedora/RedHat have a different structure and relationship and I wouldn't use the openSUSE/SUSE model to predict how things will work out.
I wonder if the Fedora community could immediately fork off their own and essentially "leave" IBM/RH hanging? Not even sure if that is legally possible now, as the terms of the sale could have potentially included looming/upcoming license changes that might prevent that. I'd say they'd have to act quick and with their general feeling on whether they'd want to go that route (the Fedora community), and I'm sure their would still be legal challenges from IBM in any case if they attempted something like that.
There are no legal challenges and there is no hurry. You wouldn't be able to call the fork Fedora but other than that it's absolutely impossible for any shady backroom deal to affect your future ability of forking Fedora. The licensing of the collection as well as the individual components grants you that right and there is no way to take it back retroactively.
With the current state of things, forking Fedora seems unlikely to be a wise decision. RedHat is the major contributor, paying the salaries of many Fedora developers.
So far, nothing has changed here with that acquisition.
> I'm curious what openSUSE folks think of SUSE having been acquired by Novel, then Attachmate, and then the Micro Focus merger. They've been through a lot, and openSUSE is still here.
OpenSuSE has been more like Fedora over their years; they historically never had a CentOS equivalent (although the newer OpenSuSE is moving there).
Where’s the history of IBM buying and sun setting companies? I don’t have the same prejudice towards IBM that I do for Oracle. But I’m not in a position to know.
I’m thinking RHEL’s support contracts will keep IBM from shuttering RHEL. An IBM branded RHEL would represent plenty of income.
This is 100% true. They abandoned so many good parts of WU and, today, it seems to continue to operate as data collection (mobile apps / home weather stations) and ad revenue generation.
>Any bets on whether Fedora and CentOS will exist in November 2019?
I would say that Fedora and CentOS aren't going away anywhere. Not because of this anyway. There were similar concerns around RH's acquisition (if that's what you call it) of CentOS a couple of years ago, but things have largely been the same. And it's mostly for selfish reasons. The overall dev mindshare of RH based systems has shrunk compared to Ubuntu. So anything that moves people away from Ubuntu to the RH ecosystem is net win because eventually some corp will write a check when they need support. It's the same idea as MS not going after pirates just to increase MS's overall market share.
OpenSolaris came after regular Solaris. It was a retroactive opening of code, and wasn't as essential to regular Solaris. In contrast, Fedora is quite instrumental to RHEL's existence. CentOS is not that instrumental, but it's not a major cost sink either. It used to be community driven earlier and can become so again. i.e., Unless they go out of their way to do something malicious, which would have little payoff anyway.
CentOS is the main competition to RHEL licenses. I have been in many meetings where the "use CentOS so if we have to buy RHEL its an easy conversion " was made
I assumed Redhat was going to capture lost revenue by somehow making CentOS less viable.
IBMs business nature makes me think its even more likely now.
From my perspective, it always seemed that RHEL's big problem was that CentOS was easier to use. Whenever I set up a machine, I always reached for CentOS because to me it was the same thing, except I didn't have to ask for a license, I didn't have to securely store the license, I didn't have to enter the license, and I didn't have to document my strategies for handling those things.
It's generally also more reliable. In any sort of an org like setup, RHEL will be managed through Satellite. The new Satellite seems like a massive pain. The old one also had issues. Running centos compared to registering clients to satellite is a breadth of fresh air. Sometimes I wonder if RH creates complexity, and sells these overly complicated solutions to problems they create.
I can't find the reference, but Red Hat recently hugged CentOS after sort of passively ignoring it for a while. Now, as I understand it, Red Hat has committed to actively supporting CentOS.
They're different products for different customers. Folks who want to work cheap and hack their own stuff together will use CentOS and would never have bought a RHEL license anyway.
Meanwhile, folks who need a "we've got support" answer for every question will use RHEL and wouldn't be tempted by CentOS anyway; the cost savings is not worth the risk.
That's the thing with an acquisition like this: what did IBM buy exactly? The code is open source, the people can leave and form a new company. The thing IBM really owns are Red Hat's contracts. But when those expire, the other party could sign their new contract with a company of former Red Hatters, if they want.
Buying an open source company only makes sense if you give the employees of that company exactly what they want. They are the real value.
Theoretically, it seems all Red Hatters could quit simultaneously and form a new company according to the same structure they had before.
Of course in practice that requires a lot of coordination, there's a ton of legal hoops to jump through and you end up with a big company built around customers it doesn't currently have.
RedHat is a public company, in what fantasy land do you exist where this isn't expected?
Furthermore, the deal is still subject to shareholder approval:
> The acquisition has been approved by the boards of directors of both IBM and Red Hat. It is subject to Red Hat shareholder approval. It also is subject to regulatory approvals and other customary closing conditions. It is expected to close in the latter half of 2019.
So you really should be complaining that RedHat's board of directors just sold out, and that's their fiduciary duty.
The Red Hat board were offered a massive premium on an already generously-priced stock. If they hadn't sold there probably would've been lawsuits left and right.
The deal is subject to shareholder approval. I think based on that approval, you'll be able to estimate how right or wrong you are about lawsuits had the board rejected the offer.
RHT is $20 billion in market cap as of Friday, and the offer is $34 billion.
SUSE has been acquired many times in the past several years (Novell, Attachmate, MicroFocus). In theory, EQT will help us "get back on our feet" in terms of self-sufficiency but how things will actually pan out is obviously still unclear.
Ubuntu (Canonical) just stared looking more attractive as they were trying to be an independent commercially-supported Linux offering.
Or, if you don’t like Canonical (and to be fair they do a lot less than Red Hat do), encouraging corporate users to sponsor Debian directly would be amazing.
It does make me wonder though if it would ever be possible for a bunch of business savy open source developers could ever get around to creating an open source co-op. Something like the commercial version of the FSF. Build open source products with solid support contracts, and build/contribute to open source that way.
The organization would be owned by the very people building and contributing the code.
RedHat is the only company that I can see that really did everything in the open.
I'm not sure which one I feel worse about, Oracle buying Sun, or IBM buying RedHat? I feel that Oracle did some major missteps in their acquisition (for this I look squarely at OpenOffice, and their misshandling of it, although, the OOo community hated the Oracle acquisition from day one, which I guess might have made it a little like poison berries - no one would want to go near it).
Oracle completely ruined MySQL during the acquisition too.
Corporate users can barely get around to patching windows desktops and are happy with Redhat being so slow moving, they're not going to jump on the arch constant upgrade cycle anytime soon.
Taking on the big ones on their own turf isn't going to work, I think. By that turf I mean supporting years old versions running in dusty custom data centers.
I'd suggest building an auto-upgrade system on top of Arch (or Alpine), and go for immutable infrastructure as the selling point. That's stepping on CoreOS's toes a bit, but I haven't seen any progress from that crowd ever since Red Hat bought them, so it'll probably get even worse now.
That way you can target AWS/Azure/$OTHER_MODERN_STUFF in a more focused way, and you won't be stuck on supporting months/years old versions of the OS.
> I'd suggest building an auto-upgrade system on top of Arch (or Alpine), and go for immutable infrastructure as the selling point. That's stepping on CoreOS's toes a bit, but I haven't seen any progress from that crowd ever since Red Hat bought them, so it'll probably get even worse now.
In that case, why not go all the way over to NixOS? They already have a more or less complete cloud stack with NixOps, the only problem is hardly anyone knows how to use it.
I agree that it's a nontrivial problem to learn a piece of complex software from scratch to the point that you can offer comprehensive enterprise support for it, but how is that show-stopping?
No, I mean NixOS/NixOPS being incomprehensible to a large amount of us even after several years of existing. That's a huge problem, and it's their problem.
I'm not sure what the cause is. If it's a fundamental technological problem, then it's insurmountable, but if it's just a documentation problem, then it might be fixable. It doesn't look good though, since, like I said, the whole stack has existed for a long time. You would think that something would've been done about it.
All that said, perhaps I'm just dumb. I'll be happy to see someone prove me wrong and succeed with that combo. The underlying technology is certainly interesting and powerful. But I won't be trying it.
Google develops Android. It's in their best interest that their changes to the kernel get mainlined... The internal APIs of the kernel tend to change a lot, and Linus doesn't really care about out of tree breakage.
This is sad, Fedora has been my favourite distribution for a little while. Red Hat have been a good community player and it is a big loss for them to be gobbled up by IBM. What is the best alternative to Fedora and CentOS?
The obvious alternative would be Ubuntu. The LTS releases are alternatives to RHEL/CentOS. The others are Fedora alternatives.
However, Red Hat is _far_ more than RHEL. They actually build a ton of OSS that's used in RHEL and elsewhere. Ubuntu does little more than repackage Debian. That's not a criticism. They package well, and they know how to polish. But there's no replacement for Red Hat as a company.
Try vanilla Debian. I really don't get the fascination with Ubuntu - modern Debian does all the same things, and in many cases it does it better (saner defaults, less opinionated).
And if one really needs a "one click out of the box" desktop distro, then Mint.
LMDE has been around for several years now. IMO, it's "experimental" in the same way many Google services are "beta". Which is to say, in practice, it works just fine.
But Red Hat/Fedora has been a huge contributor to very basic Linux ecosystem things which everyone benefits from, like the freedesktop standard stuff and more.
I wonder how this change will pan out across the entire Linux-sphere. I’m wondering and I’m trying not to be pessimistic.
Sure they can, but most public companies (absent places like Facebook, which IIRC has a setup which favours Zuckerberg heavily) are more susceptible to being forced to sell whether they want to or not.
Private companies (especially one's who aren't beholden to VCs or similar) have the option to say no, regardless of how much money they're offered.
I always find this language kind of interesting. Companies are inanimate entities, they can't want or not want something. When you say "they want to" or "have the option to" who do you really mean?
IBM's had the Linux Technology Center (LTC) for a long time and has been contributing to the community. All the platforms Z, POWER etc... support Linux as a first class citizen and plenty of other ecosystems are also supported (i.e GCC, OpenJDK, etc...)
Maybe its time to re-evaluate the old biases? The old incumbents like Microsoft have warmed up to OSS, not sure why Big-Blue is getting this much flak.
Microsoft has been doing a lot to rebuild itself as a cloud provider.
IBM has been doing a lot to go out of business.
Microsoft's first CEO is still chairman and helping lead the company even from the sidelines.
IBM is a floating raft of failed leadership.
Microsoft isn't trusted fully by the community but they are making inroads under their new CEO.
IBM has been firing its most senior people in an effort to slow its cash burn and to hire younger folks. IBM also claims it's also to bring on folks with more relevant skills to emerging technologies. I think there is a lawsuit about this.
Anyway, IBM has done nothing in recent years to show they are a true contender.
If the Redhat team is able to pull a Next here and assume leadership roles inside of IBM this could be stellar. Big Blue's formidable sales team and reputation with a great product line overseen by passionate people would be powerful.
If the IBM existing leadership team emerges as the winners here it will likely continue to fade into irrelevance.
"Microsoft's first CEO is still chairman and helping lead the company even from the sidelines." this is not true? maybe you meant he's a technical adviser
Thing is, IBM does not have a great reputation for how it manages its staff as it tends to favour moving positions to low cost locations and redundancies that provide the minimum possible payouts
I've followed POWER for a while now, and it seems to be mostly marketing hype. The POWER8 was not much better than the Xeons out, and had almost no availability. POWER9 excels at a lot of IO-bound tasks, but again, it's nearly impossible to find. It doesn't help that there are very few systems you can buy out there. On paper, the POWER9 looks awesome. Then you look closer at the actual architecture and realize that a lot of pieces of the design are weird and/or seem somewhat useless. It also doesn't help that they're extremely expensive, especially since there are so few options.
So while I'd like IBM to compete with Intel, they need to pony up more money if they really want to push the industry. Don't make it so hard to buy one, and publish benchmarks/comparisons with Intel.
Based on your subcomment about evaluation, I'm very interested to hear your opinions about Talos' offerings - up to now I've only heard anecdotes from individuals drinking the security+ownership kool-aid.
What IBM offers is probably a lot more coherent and takes better advantage of what the POWER architecture has to offer, such as larger quantities of RAM, the per-node interconnect fabric, faster I/O (not just PCIe), etc (admittedly totally naive here). Plus of course there's z/OS, which I know enough about to respect (and want to play with someday :) ).
Talos basically offers only Linux and a mildly DIY standing-up experience (https://tenfourfox.blogspot.com/2018/05/a-semi-review-of-rap...), although this is likely to be reasonably painless for non-desktop configurations (and perhaps volume orders can come preconfigured).
As a bit of a pet idea I kind of want to colocate one of the 2U or 4U systems for generic web serving and similar duties, but I fear that running a blog/discussion system on such a machine may result in a constant effort (on my part) at keeping discussion focused on the "it's a different architecture, what comp-sci interesting things can we do with it" aspect instead of getting distracted by shallow OCD-meta-security bikeshedding.
(It's kind of sad that the collective consensus about new/different architectures has to always be about security nowadays, and not about unbiased exploration, which is what we're best at)
My impression is that POWER is more suitable for certain types of scientific computation that require high degrees of precision rather than for general purpose enterprise use. POWER9 is the only CPU architecture out there that has support for quad-precision floats. Alas, no CPU exists with support for octuple floats, since only astrophysicists need that level of precision.
Right, and that's what we were evaluating it for. It's also the only one with pcie4, 8 memory channels, and CAPI. Nonetheless, it needs software and libraries to be updated to use some of these, and in many cases, they're not.
sir, you make a good point. the world always changes. microsoft has changed, perhaps IBM has also. one who believes in sin and redemption perhaps should give IBM a chance.
To add some substance to my comment. I’ve interacted with IBM in different scenarios. I’ve had to manage a team of IBM consultants at work, very frustrating experience. I still shed tears every time I think the hourly rate paid vs the value they provided. When Watson was being hipped the company I was working for was approached to use the tech and come up with some PoCs, the dissonance between the biz dev pitch and the actual “solution” was abismal. Currently I’m at a different company and we have IBM as one of our customers, the image that comes to mind is a headless chicken running around.
That is to say, not a very impressive impression. I’ve to say that I’ve seen some interesting stuff as well. But I’m still very sad about the buyout
IBM has been historically a Linux contributor. Eclipse, their open source IDE, opened the other to Java and other programming languages in the OS. And Power processors supported Linux early on. From that perspective to purchase Red Hat makes sense.
It makes even more sense as the announcement states that they are trying to create a bigger cloud provider to compete with Amazon Web Services, Google Cloud, and Microsoft Azure.
My main concern is the reduction on variety. All big businesses are buying layer after layer of different markets reducing the number of options that one can choose.
According to their 10Q and 10K filings, IBM is over seventy percent a consultation business with less than ten percent of revenue being made from hardware.
So with RedHat and the remains of IBMs hardware division, they make a push into the cloud with their own RISC-V servers with chips fabbed on an advanced node and with a full software stack driven by both IBM and RedHat developers. They'd be vertical in their cloud offerings.
You don't need to tell me I'm hallucinating - I know. But it's fun to imagine something good coming from this rather than the simple destruction of RedHat.
IBM is member of the RISC-V foundation. If they could make a similar high performance server chip with RISC-V ISA I'd take that over OpenPOWER any day due to the much wider acceptance of it. They could also support both and see which goes further.
"We expect OpenShift to become the dominant brand for Kubernetes."
That seems like a strong statement that I didn't see any backing for in the blog post. Care to expand? I haven't seen much settling in the k8s space. In fact it looks like things are still heating up with many companies pivoting in that direction.
You do realise that a lot of Linux kernel development is being done by for profit enterprises, don't you? None of these companies are doing this out of the goodness of their hearts, but because they have a vested interest. Linux is at the heart of possibly the majority of modern IT infrastructure.
Besides,IBM/RH are by not even the largest contributors. Intel does more than both of them combined, and then you have other heavyweights like Google who have an interest (notably through Android) in keeping the project going. Even if IBM were to pull out for some reason, there are more than enough others who could pick up the slack.
Not just "a lot." Over 90% of contributions come from developers who are hired by companies to contribute to the Linux kernel: https://thenewstack.io/contributes-linux-kernel. Intel and Redhat each contribute more than all the individual contributors put together.
I see way too many good open source projects relying on donations, and they are not doing well. Nothing wrong with making money, or rather, it's an essential part of life (for better or worse).
It's worse, IMHO. IBM treats their customers as prey just like Oracle plus they treat their own people worse. I know people who've had the IBM licensing ninja squad show up at their door for surprise validation with a big bill as a result.
Oracle are actually malicious. IBM are just incompetent.
If you can find a good account manager inside IBM for your needs, then there is a chance that you'll be able to get on well. Otherwise you'll have to do what I did which is say publicly shame the head of department on a public platform, with their superiors listening in.
I seriously wonder who is still left at oracle who actually cares about technology and pushing it forward, instead of using it as a tool to squeeze money.
Most competent Sun people have left oracle and are onto greener pastures.
However nice their open source work is, RH licensing is already every bit as scummy as the others, at least if my coworkers in the department I used to work for are to be believed. Bait and switch freebies, "we need to run this sketchy shell script on your production system to determine how much money you owe us" nonsense, coming back with a ludicrously inaccurate bill that has to be argued over point-by-point with lawyers, the works.
When IBM bought Informix they replaced competent database support with aggressive DB2 marketing droids and presented us with an annual bill sixty times more than Informix had charged.
The alienate and destroy part is likely. Very different situations otherwise.
Sun was essentially a dead shell that still held a few valuable pieces when Oracle purchased them. Overall the business was in terminal decline.
Red Hat, while wildly overvalued (as many things are/were in this bubble market), has a consistently growing business that is on good footing overall.
Their prior four fiscal year sales figures: $1.7b, $2b, $2.4b, $2.9b
They look like they could do $3.4b in sales for fiscal 2019.
Their profitability is mildly lacking and combined with their modest growth doesn't come close to supporting their extreme valuation (much less when the stock was 50% higher). It's not surprising the board might sell the company here, the stock market bubble is likely nearing an end, with interest rates rising or a recession coming up next (either of which guarantee it's over). Red Hat may not see much higher than this market cap for another decade - assuming continued modest growth - if they were valued at a more sane level.
Red Hat is riding relatively high. Sun was on its last legs as an independent entity. Red Hat very clearly does not need to sell here, if they do it's simply the board taking what is an extraordinary price (would have to guess the deal will value them at 60 to 80 times idealized 2018 earnings).
There is also the big difference that Sun was in the middle of transitioning to open source company (almost begrudgingly I think after everything else had failed), they weren't the great friend of open source they now are remembered as at their peak of their success. Sun still held significant amount of proprietary IP when they were acquired. In comparison RH has been open source from the get go, and pretty much everything they have is open source.
RH strategy was mostly focused around OpenShift lately, which makes complete sense. Kubernetes is the next datacenter OS, just as ESX (and virtualization in general) was in the past 15 years and it's going to drive a radical shift in the enterprise IT world in the coming years. IBM (as an active member of the kubernetes community) see that huge opportunity and are doubling down on their efforts.
Any bets on the next player in this space to be acquired by an IT behemoth? Docker and Rancher both come to mind.
Docker just took more funding, so it'll likely be a while, but yeah I'd say they're very likely to get acquired in the medium - long term.
Rancher haven't raised in a couple of years, so might be more prone to acquisition in the short term.
In general it lseems likely that as containerization has taken off over the last couple of years , larger players who missed the boat will be looking to make acquisitions to become more relevant in that space.
Docker seems to be determined to strike it out on their own. The implications of Kubernetes takes time to materialize, and they might well sell too late.
New IBM hire, software developer. So far; I've taken part of 3 separate events where I was essentially sat through a presentation on why I should file patents (so they could farm IP off of me and my peers). IBM is a pathological company, and definitely not good news for open source.
”sat through a presentation on why I should file patents”
Some years ago, I worked for Red Hat. I remember them saying the same thing about patents. There was even some kind of reward scheme if you filed one with your name on it.
(in hindsight, I guess I should have held on to those employee stock options!)
I've seen RedHat (via JBoss) knowingly patent work they read in a research paper without referencing or funding them. I was positive it was for a reward, as there was no additionally novel ideas in their descriptions and similar work was already open sourced. I knew it wouldn't hold up so it didn't bother me as impacting my projects, but I was disappointed over the ethics of them doing that. I do wonder how many patent rewards are given for someone else's work by farming from the research community.
It's been my experience that engineers are quite poor at judging the "patentability" of ideas. I'm not saying that you're wrong, just that the patent field is quite opaque and difficult to understand, which is why patent lawyers do quite well.
It's been my experience that non-engineers are really poor at judging novelty. Plenty of patents are the equivalent of making a new widget and holding it together with screws. It's not a screw patent or a widget patent, the novelty is in holding the widget together with screws. Someone invents a new fastener and suddenly every product in existence can get a patent by redesigning what they have using the new fastener. Substitute "algorithm" or "data structure" for screw and you have a large slice of the world of software patents.
I've seen plenty of seemingly dumb patents myself, but most of them are legal because an application of a known technique to a new field is considered novel in patent law. So if you design an amazing new zipper for jackets, I can probably copy that, put it on a backpack, and get a patent on that and there would be nothing wrong with that legally.
Well, there's legal and there's right. They are not not always the same.
Your backpack example is a perfect illustration of my point. Thanks for that. It is a matter of degree of course, but the bar for patentability is really low IMHO. The new zipper may have been worthy of a patent, but every new instance of its use where another zipper was previously used should not be.
Based on the above phrase you could almost be forgiven for thinking somethings "patentability" would actually be defined by how engineers typically judged it, rather than how specialist lawyers judge it.
This is rather normal, not pathological. Most companies like to file patents, definitely including startups. Where do you think their patents come from, if not from work their employees do? It's work that's worth paying for.
Having some proprietary code doesn't prevent companies from also making substantial contributions to open source in other areas.
Having some proprietary code doesn't prevent companies from also making substantial contributions to open source in other areas.
... yes, but patents are not "proprietary code", in which case granting copyright is enough. If a private company contributes code I think it could even grant the copyright to an open organization, but still decide later to sue if the method/feature/function/etc is patented by them.
Not that I'd foresee IBM or any of the real players in the IT space attempting that anymore, I think most realize that alienating the F/OSS community isn't a viable strategy for a software services company in the long term.
Many companies will license patents to an open organisation as well as indemnify them against patent threats from other companies.
Patents are by and large warfare between large companies. They almost never used against open source contributors or small companies unless by patent trolls.
actually, the normal advice for startups these days is to not file patents. They're expensive and pretty much useless. They used to be worthwhile because investors liked them, but investors aren't so hot on them any more (because expensive and usually indefensible).
Have you been enjoying the morale nothings-on-fire-we-swear propoganda all-hands meetings? I was in IBM, software dev, for a year - just left around July. God help your soul.
The joy of working in a large corp. One day it's: boss's boss cares a lot about the work of this team. The next day the whole project gets cancelled. All hands propaganda meetings are so much fun ;-)
Hi there! Fellow IBMer :) sorry to hear about your experience so far, just wanted to chime in and say that you're definitely not alone with this perspective. Patents at IBM are so highly valued that they often act as a blinder towards open source.
However, there are definitely groups inside of IBM that choose to open source their work instead of filing for patents. For example, the team that I'm currently on works on the Carbon Design System [0], which is entirely open source. All the work our team does is out in the open too [1][2], which is great!
I would say that for teams like this, the tendency is to open source software and patent processes that are unique to IBM or a particular domain. That way we can try and contribute back as much useful technology as we can!
Obviously there are others at the company who might have a different perspective, but thankfully we're also trying to spread our own take on alternatives to the traditional processes at IBM.
Hope this info can help make your time at IBM a little bit better!
I used to write software for print manufacturing. Where the ink meets the paper for books, newspapers, packaging. Our biggest customer was granted multiple patents for our product's core functionality. A full decade after they started using our wares. We had no idea until I was idly researching patents in our field.
It's not entirely true that in Europe that software patents don't exist.
From: https://fsfe.org/campaigns/swpat/swpat.en.html
"The European Patent Convention states that software is not patentable. But laws are always interpreted by courts, and in this case interpretations of the law differ. So the European Patents Office (EPO) grants software patents by declaring them as "computer implemented inventions". "
Thanks for clarifying. While I kinda expected SAP to have some software patents, I didn't know that software patents or 'computer implemented inventions' were still a thing in Europe.
What that quoted sentence means is that you can file for a software patent with EPO and it will usually be granted. Implication by omission from that is that resulting patent is essentially unenforceable in the EU.
> "OK," he said, "maybe you don't infringe these seven patents. But we have 10,000 U.S. patents. Do you really want us to go back to Armonk [IBM headquarters in New York] and find seven patents you do infringe? Or do you want to make this easy and just pay us $20 million?"
Unfortunately, that's going to be the situation at virtually every large tech company these days. To their credit, IBM has been a longtime contributor to Linux so if Red Hat was going to be acquired, IBM is far from a worst-case scenario. It just would have been nice if they could have remained a stand-alone company (I know, wishful thinking)
Maybe you are new to the software industry but at every company I've seen e.g. Apple, Google, Microsoft they strongly encourage you to be filing patents.
And calling it farming is a bit strange considering you're paid by the company to generate the IP in the first place. Plus they typically compensate you extra for it.
IBM pushed what I call reckless patenting. They explicitly said, in multiple situations, that even if you think that it's a trivial idea you should attempt to patent it as it will probably get through. Personally, that sentiment goes against my philosophy. I wouldn't regard the monetary benefit to filing a patent through IBM worth the guilt I would accrue.
Note that I haven't worked for other giant tech conglomerates, but I haven't experienced it in the other medium - large but not ridiculously large companies which I've worked for.
I am familiar with patent reward systems, but only IBM pushed what I call reckless patenting. They explicitly said, in multiple situations, that even if you think that it's a trivial idea you should attempt to patent it as it will probably get through.
The only reason for this is to up their patent arsenal.
Some companies are better then others. I am confused about why you would ask a question that is intellectually equivalent of "... have you stopped beating your wife.." /S
Did you expect this beforehand? I can imagine they try to show themselves as being innovative and stuff, and only after you join you get the company policy details on stuff like what you just mentioned.
As a Red Hat employee (opinions my own, not Red Hat's, etc) and though not involved in any discussions like this, I can see some potential for it being a good move. There's a lot of work being done to a) move things from mainframe to distributed and b) help people squeeze the last bits of utility out of their mainframes. That requires knowledge on both sides of the house.
The world is going to open-source distributed systems built on commodity hardware, which Red Hat has done a great job of building a business model around. For old established companies, though, the migration is a lot of work, and there are _definitely_ still plenty of large companies who have purchased/leased mainframes for long periods of time, and would like to modernize, but also can't afford to throw everything away and rebuild from scratch. There's a lot of work being done already between the two companies to run Go, Docker, Kubernetes, etc, on mainframe, and for companies with mainframe resources, being able to get a little more utility out of those sunk costs is very attractive, and something Red Hat's expertise has (and would continue to, presumably) help accomplish.
That being said, I'm pretty surprised at the news, and I'll be watching closely to see how things go.
This is the most positive comment I've seen in this thread. To the extent that the ensuing development effort finds bugs in container orchestration systems, creates new features, creates new abilities to manage services on "hybrid" private-cloud-plus-mainframe systems, helps to modernize old-school businesses that run infrastructure the global economy relies upon... this could actually be a very good thing for open source and future investment therein. Skepticism is healthy and warranted, but this could be a good match.
It's also worth pointing out that Red Hat (and Big Banks) have been desperately trying to train new mainframe operators with limited success due to the shift to distributed, to the extent that they've even been giving money to select colleges specifically to develop mainframe-centric curriculum.
I have some hopes that Red Hat has a strong-enough future value for IBM that we end up redefining IBM rather than the other way round. There are precedents, notably the Apple/NeXT merger. Today's Apple is 95% NeXT and 5% old Apple. Can this happen here? Time will tell.
An an IBM employee, I definitely hope that some of the RH culture rubs off on us, but I also hope that RH retains its own distinctive identity and isn't altered very much by the deal aside from having access to IBM's resources such as the scale of the sales organisation.
RedHat can be replicated. Not cheap, and it will take a few years. What do I mean? Well, IBM will slaughter this goose very quickly. Customers will experience vendor hate to a high degree. But, RH is based on open source. A replacement, open source friendly, can fork RHEL at any time.
Ubuntu looked like it was taking over last time I paid attention. Every new cloud thing touted its pre-configured Ubuntu images, for example. Even Microsoft started with Ubuntu with WSL.
Maybe that's why a still multi-billion dollar company decided to cash out even as Linux seems to be making inroads. People used Red Hat for the same reason they used IBM: it was corporate, understood corporate needs, and knew how to serve them. Now it seems like corporations are offloading IT to AWS and friends with Ubuntu.
Everyone talks about what Canonical did for the desktop while missing what they did for friendly apt-based Linux on the server with SLAs and LTSes and support contracts from a company that speaks corporation.
And if all the paying customers switch to Debian-based distributions...
RH back in the day made a lot of hay by being the go-to option for enterprises migrating proprietary UNIX workloads to x86+Linux. But I guess that market is mostly saturated by now.
What I worry about is not the fate of RHEL per se, in the end it's just a distro among others. What I worry about, as a huge FOSS fan, is the fate of RH engineering which is certainly one of the biggest individual upstream FOSS contributors on a lot of places in the stack. By comparison, the Canonical engineering team is absolutely puny. If the work that RH does disappears, we're going to see a lot slower progress in the FOSS ecosystem.
You'll see a lot of preconfigured CentOS images, not RHEL because of the licensing. Red Hat's recent (and sensible) play has been on-prem Kubernetes with OpenShift.
Ubuntu has its own orchestration toolsets, and I wonder if RHAT only had the upper hand with being the incumbent in the US and buying things like Ansible and OpenShift and CoreOS.
Ubuntu runs Systemd, it's a modern distro - if someone wants to take Openshift core and other components and run it on Ubuntu, it will happen.
Well yeah, there's CentOS, so a company just needs to step up and provide the level of support RHEL customers expect.
I think this is going to be great for SUSE. They already have comparable service and they already have a solid customer base in Europe. If RHEL alienates its customers through a slow death at IBM, SUSE can come in.
RHEL is just a small piece of the Red Hat puzzle that is sold to enterprises. In some way Red Hat is an exception -- there have been no multi-billion dollar businesses built purely on open source except them. (Or maybe I have missed something.)
Well, fuck. I spent the last couple of years completely revamping my UNIX support group. I got rid of all the weak SAs and used a mix of in person and online vendor training plus internal challenges to elevate everyone's skills. We were able to completely repurpose the "Level 3" UNIX engineering group because all the "Level 2" guys no longer needed to escalate to Level 3 for anything.
Critical to that was buying RedHat Learning Subscription and pushing my top guys through RedHat's Certified Architect program. But I'm skeptical but we'd have the same leverage to obtain similar learning discounts from IBM.
Honestly as my org gets more comfortable with pure open source solutions it may be time to just consider Fedora instead, particularly as our workloads are moving from bare metal to VMs to containers it arguably means less and less where the app is hosted anyway.
In the end it may mean RHEL going the way of Solaris as ever dearer license fees combined with a drop in support quality undermines their value proposition.
But I guess that's a problem for the next guy; my org transformation is done so I took a job doing provisioning using Terraform.
This was to be expected. Red Hat had no future as an independent company. Their flagship product RHEL still dominates their revenue 20 years later... But they have already saturated the enterprise Linux server market, and that market is in decline. All attempts to diversify have failed. Openshift and Ansible have potential, but compared to the decline of their core business, it’s too little too late. The current CEO is a peacetime CEO: he managed a successful business competently in fair wheather, but is not fit to navigate the rough seas ahead. This allows him to leave on a victory (“the largest software acquisition ever!”) and go on a book tour or something. Meanwhile IBM can delude themselves a few more years until they’ve finished milking Red Hat’s products for easy growth. Then they will have to face the reality of their situation: they have no real answer to Big Cloud eating their lunch. For now, though, they can pretend this is it.
I think the implication is that Canonical are in the same, shrinking market. Whilst I assume Ubuntu Server has a smaller market share (though I have no figured to back this up), are they not going to end up in the same spot where they can't really progress?
Well, Canonical was never a successful business in the first place. Red Hat on the other hand has revenue in the billions... which is huge! It’s just not growing fast enough to keep up with the competition from cloud providers and others. Canonical hasn’t even graduated to that sort of first-class problem (and I doubt they ever will).
This is a massive cash expenditure. IBM's biggest bet to be back into the cloud game. Given the amount of cash involved this might be IBM's last card, at least from an M&A perspective, so this deal needs to work.
RedHat is much smaller than IBM, however far better managed with a clear product roadmap, lean sales and customer support. In a good scenario a reverse takeover will take place and RedHat management will take control and lead new IBM to a better future, however this is very unlikely.
IMO: This is great for RedHat shareholders, terrible for the new IBM co...
I'm a fan of Red Hat. I am a Red Hat Certified Engineer and contemplating working towards the architect certification. When I heard they aquired the company behind Ansible a few years ago I was excited.
If this deal goes through I'll be super disappointed.
At a former employer, we were heavily invested in Purify, Quantify et al. When taken over by IBM, the license management cost at our side increased an order of magnitude -- not for the products per se but by the administration of the licenses.
Even though we loved the products, we found it was increasingly not worth it. 'Killed by license management', has a nice ring to it :)
Thanks to CoreOS and all the other teams under RedHat who have done amazing work up until now. To be fair I've used (and enjoyed/been impressed by) your software for free so obviously I'm not owed anything but I'm gonna be looking for alternatives.
I'm suuuuuuuuuper glad I jumped off of CoreOS Container Linux earlier after the acquisition by RedHat and subsequent bundling into Project Atomic. I avoided OpenShift all together for other reasons, mostly complexity. Now I can watch from a relatively relaxed standpoint and start figuring out how to make sure no IBM sneaks into my stack, if they start tanking products. As others have noted, this is more than RHEL. Keep in mind:
- Ansible is GPLv3
- CephFS is GPLv2 w/ some mix of BSD and others
I assume licenses will serve as a canary for when things start shifting. I might even be so bold as to predict some variation of the LICENSE + PATENTS.md clause.
Red Hat does not have CLAs, not does it own all the copyright, on either Ansible or Ceph. It cannot change their licenses unilaterally, that can only happen with permissive (non-copyleft) terms.
Yes, this is true right now, but does not mean it will be true in the future -- I meant to imply that Ansible was the safest, due to it's GPLv3 licensing (from what I understand GPLv2 is more permissive).
My second point was that I expect those terms to change depending on how IBM moves forward, and movement on that front (from the current state of things) should act as a canary.
_Anything_ that does not have a CLA and is copyleft is safe. That's pretty much the definition of copyleft; IBM cannot do anything about it, and they know.
Hoping this is false! IBM is the worst of acquirers and they treat their people like utter garbage, especially the more experienced ones.
If there's any truth to this, it means those in charge have basically given up - assuming growth is capped and/or that the big return of a buyout premium would counter recent stock pricing setbacks.
My perception is that IBM (and HP, Oracle, etc) will buy a product company, and then IBM-ify it, and then just sit on that product for years with minimal improvements.
That is my fear for Red Hat. Successful product companies are hungry - IBM is not.
Well no, but no law needed here. You see, this is part of the deal with Jim Whitehurst and rest of Red Hat management, otherwise, Jim would not pitch this to shareholders as a good deal. It would be a hostile takeover, which can fail, or lead at the end of IBM buying just a shell of the company.
So to back up their intentions, IBM probably had to give golden parachutes to Jim, Paul, and rest of Red Hat top execs, and probably huge golden parachutes ones at that. Jim is becoming part of IBM uper management and keeps leading the Red Hat business unit. If Gini starts some crazy moves to endanger Red Hat's well being as an entity inside IBM (as in IBM-fying the company), she will get at odds with Jim and RH upper management. So she can fire them all and pay up bilions in golden parachutes, at which point they will probably found a Green Hat company and hire away all Red Hat employees... or Gini can keep her word in the deal and leave Red Hat a separate business unit within IBM, one that grows revenues and profits, unlike most IBM business units. And IBM is a meritocracy, if Red Hat continues good performance, expect Red Hat execs taking top position, including next CEO role. In other words, I expect IBM to be Redhatized, and not other way around.
They didn't fire theirs - they ordered them to move to an arbitrary office, most commonly not the closest geographically either, without relocation money. If you didn't move, it was considered a voluntary departure. There was often no room at these offices even for the minority who accepted the moves.
It was/is a deliberate attempt to dispose of senior, less portable people without having to pay layoff charges.
Who needs fusion power when you can run off the Watsons spinning in their graves at relativistic velocity?
The second link, which details how the reporting for the story happened, explains how older workers were often given 90 days to move thousands of miles to "an office" or else lose their jobs.
--
The results are stunning and should shock and scare all of us, whether we're in our 20s, 30s, or beyond. Because we all age -- this is a fact. And if the IBMs of the world can get off scott free, other companies may do this too.
I've really got to wonder at the people who would stay at a company that treated them like utter garbage ... especially if they're experienced ... and especially in this job market.
Red Hat tends to employ people through offices in low/moderate COL areas or as fully remote. It would have been my #1 prospect after leaving the Bay Area. People who've already established lives in places like Raleigh may not find a comparable job so easily.
Yes but which company's leadership has given up? If this is the ordinary acquisition model, where the buying company (IBM) leadership stays in charge, then I say it's Red Hat's leadership that's given up. If it's the 'buy a company to get an entirely new leadership team' then it means those in charge of IBM might actually understand their dire situation. But I have no idea if they have that awareness.
Actually Red Hat is exactly like IBM. Huge and slow.
I know the contribution to FOSS from Red Hat is great and all, but their product, RHEL, was a cancer for a modern software development.
Just easier to maintain for sysadmins doesn't make enough excuse for really long release cycle and the worst of all is they keep supporting the old products.
The result is a nightmare development environment for all the programmers who has to workaround the old bugs that was fixed years ago in the upstream but not fixed in the RHEL packages, but they have to use the RHEL packaged software for stupid sysadmin reasons.
What's the alternative? All of the places I've worked that used Red Hat never explicitly looked at the Red Hat support timeline. They looked at their business, the software they used, the features they needed, and based their upgrade cycles around that. They'd only upgrade the major versions of their primary software when a project would benefit and skipped major updates that were problematic. At my current job they're only now upgrading from a 2016 piece of software to 2018, they're also straddling Cent 6.7 and Cent 7.2 and only making moderate progress.
Usually the reason for updating the OS is because new software doesn't run, there's a major feature needed, or supporting the old OS is too much trouble.
But it's not like it's any different on the Windows side. XP stuck around forever. At my previous job they had Win7 on workstations with little to no intention of updating to Win10. On the server side it was all over the place including Windows Server 2003.
The problem isn't that RedHat's release cycle was too long, it's that companies want support for 5 year release cycles. Most places I've been don't even look at testing a major version of a new OS for at least year. There are just too many variables between hardware, drivers, and software and little to no benefit in staying bleeding edge.
Let's say there was a new feature. It might be an improvement in almost every regard, but how it behaves at the limits or when left unattended might not play well with every other piece in the system. Part of it might be changing user/business expectations, or changing the pieces around, but that can literally take years.
A few wrinkles I've heard about, but haven't directly dealt with is that RHEL7/systemd is too polite about unmounting disks on shutdown which means it will just hang. This is a huge problem for remote workstations that don't have IPMI. Another issue I've heard about is issues with a bunch of our diskless servers don't play well with it. Having to migrate and troubleshoot core issues like these every 2 years is just unfeasible.
As you point out, just working at a place where everything is 10 years old is frustrating, too. Last week I was trying to build VLC, which requires C++11 and had issues. At previous jobs I pushed really hard for a new enough kernel to evaluate Docker and have spent a lot of time selling people on Git.
By using the obsolete software versions, it cause instability and inconsistency and a lot of effort will be wasted to workaround the issue rather than solving the real problem.
You’re fundamentally wrong here. Red Hat providing a long-term and stable operating system and software target provides stability to users of RHEL. Upgrading your operating system, system libraries and toolchain are valuable changes, and should be done periodically, but these changes, like any other, introduce instability across the change. Those risks can be mitigated, but they are risks nonetheless.
Totally agree. RHEL's support windows are FAR too long and result in more problems than they solve. Large businesses wait till the last minute to upgrade then realize that working through a minimum of 5 years (often 10) of changes is extremely hard. This means that you often run unsupported while everyone scrambles to fix all the changes introduced by the upgrade. Cannonical's 5 year support window is much more sensible.
For individuals and small businesses, sure it makes no sense. But large enterprise customers will pay a lot of money for support windows that are far too long. That's why Red Hat (and every other large company) offers them. Even when the publicly available support ends, they still often have hangers-on who will pay even more money to get a few more years support out of them.
Having been a linux user for 20 years now, I'm not worried.
Mostly because in the OS market there is enough competition that didn't exist back in the 1990's when RedHat was founded around the Linux kernel. And we continue to have valid choices in the Linux market.
And as we move forward into Kubernetes, we're looking at lightweight OS's to host a single purpose microservice. Most companies don't really need the full features that a full-service Linux OS offers anymore.
Another example of this trend is the declining use of Sendmail and it's alternatives. There are much better ways of handling email now than using Sendmail. Yes, it too was popular in the 1990's, and while people still use it, it's more likely for startups to use something like gmail for employee email, because it's just painless.
Agreed. There has been a massive amount of tech consolidation happening lately. I assume as a result of all that overseas cash that got repatriated with the tax changes.
At the same time, K8S team has been rapidly standardizing everything and turning it into a very modular system. etcd is pretty much a "done" project, but if it ever goes bad, it can easily be replaced.
Red hat has been owned by corporate execs, it's not owned by developers. Made 2.9 billion in 2017. Once that kind of money flows the big offers come from the oligarchs. There is no integrity in corporate business. If they get a big offer, they're going to sell. IBM in a proper world of business shouldn't exist, but patents keep them alive. We will need a new replacement to red hat, but I'm afraid the hyper reliance and patenting IBM will enforce will make this impossible.
Am I the only one cautiously optimistic about this merger? RH has dominated Linux development for too long anyway, pushing systemd, namespaces, procfs and other crap, and making RHEL an overcomplicated jack-of-all-trades O/S which would only run with the specific gcc, glibc, and RH-specific kernel patches and build tools anyway (which is kind of the point of RHEL, and of IBM as well - PTF466735 anyone?). RH now being IBM will make people turn to Debian and derivatives such as Ubuntu and Devuan. The press release on redhat.com talks almost exclusively about "the cloud", but "the cloud" is, and always has been, antithetical to Unix (Unix being about site autonomy and simple tools working together). Why would indie devs and idealists want to contribute their efforts to enslaving people in "the cloud" anyway? "Cloud" stuff is also at odds with user freedom, and only seeks to make software runnable over shitty web frontends for undue profit and privacy invasion, when F/OSS software has been out there in abundance for over a decade. I hope we'll also see some love for the BSDs, and a renewed shared understanding that only POSIX and other standards guarantee long-term autonomy to both individuals and corporations alike.
> "the cloud" is, and always has been, antithetical to Unix (Unix being about site autonomy and simple tools working together)
Does the physical hardware being on the actual premises or not really have anything to do with "site autonomy" or the granularity of the toolchains?
In fact, can you even buy any viable physical hardware to run on your site that's not already a virtualised "cloud" with the real host OS firmly in the control of your corporate overlords, e.g. Intel ME and AMD PSP?
I said, "I thought, IBM support Open Source right?" his response, "Yes, but that's another team"
I decided to call-off the interview after that.