The whole Dell related ownership structure is just ... odd.
Under the terms of the transaction, Pivotal's Class A common
stockholders will receive $15.00 per share cash for each
share held, and Pivotal's Class B common stockholder, Dell
Technologies, will receive approximately 7.2 million shares
of VMware Class B common stock, at an exchange ratio of
0.0550 shares of VMware Class B common stock for each share
of Pivotal Class B common stock. This transaction, in
aggregate, results in an expected net cash payout for VMware
of $0.8 billion. The impact of equity issued to Dell
Technologies would increase its ownership stake in VMware by
approximately 0.34 percentage points to 81.09% based on the
shares currently outstanding. VMware currently holds 15
percent of fully-diluted outstanding shares of Pivotal. The
transaction is expected to be funded through cash on the
balance sheet, accessing short-term borrowing capacity, and
approximately 7.2 million shares of VMware Class B common
stock to Dell.
> Under the terms of the transaction, Pivotal's Class A common stockholders will receive $15.00 per share cash for each share held, and Pivotal's Class B common stockholder, Dell Technologies, will receive approximately 7.2 million shares of VMware Class B common stock, at an exchange ratio of 0.0550 shares of VMware Class B common stock for each share of Pivotal Class B common stock. This transaction, in aggregate, results in an expected net cash payout for VMware of $0.8 billion. The impact of equity issued to Dell Technologies would increase its ownership stake in VMware by approximately 0.34 percentage points to 81.09% based on the shares currently outstanding. VMware currently holds 15 percent of fully-diluted outstanding shares of Pivotal. The transaction is expected to be funded through cash on the balance sheet, accessing short-term borrowing capacity, and approximately 7.2 million shares of VMware Class B common stock to Dell.
Ultimately, this transfers shares to Dell that, most likely, provides liquidity that could be used to pay a little bit of their massive debt ($56B) that is choking them. Dell is in financial trouble. See https://seekingalpha.com/article/4278101-dell-technologies-m...
"Pivotal trades at a loss but revenue is growing. Having said that, in its report to investors last month, after the release of its first quarter results for FY 2020, the company issued revenue projections that were lower than expected. Shares immediately suffered a more than 40 per cent fall and have not yet recovered. They're currently cruising along at about $10 apiece, five bucks below its 2018 IPO opening price of $15."
Aside from the wall of english words I have a rather limited understanding of what it actually says. Looks like a lot of weird dealings to me. And if it's described in that way I wonder if it's a good idea at all.
People that own one type of share of Pivotal are getting $15 per share for them. Dell, which owns a different type of share, is exchanging the Pivotal shares for VMWare shares. Because the shares of Pivotal and VMWare have different values, it isn't a 1:1 exchange, the VMWare shares are treated as being ~20 times more valuable.
I would say the transaction is mostly boring accounting, not anything weird. Who knows if Pivotal should operate as part of VMWare instead of independently, but once you decide to do that, you have to consolidate the ownership somehow.
An aside, the difference in the shares is so that Dell could keep control of the company while selling some of it on the stock market. I wonder if there is a good analysis of how companies with closely held control do over time.
Context: Dell has large stakes in both Pivotal and VMware
VMware buys Pivotal. Pivotal's regular shareholders get paid in cash per share ($15). Dell, which owns a separate class of shares, gets paid in VMware shares rather than cash. This is likely because Dell already has a large cash balance and they don't need any more cash.
They do make stuff. Idea is to make next generation software worse than previous generation. Make money by fiddling with those agile JIRA/Storyboards and endless bug fixing.
I don't know if this was financial engineering because Dell bought EMC/VMWare but it was the smaller company, so this is a way to just increase the ownership they have rather than take cash out of the company which they use to make purchases. I'm not a FA expert, only TA, but that's my thought here.
"Intel paid Dell in the form of rebates as part of an agreement to ensure that Dell would not use computer chips made by Advanced Micro Devices in its personal computers and computer servers, according to the civil charges."[1]
Dell paid the SEC $100 million in penalties, Intel $1.45 billion.
Isn't this more of a consolidation?
My understanding was that Pivotal was spun out of EMC and included some assets that were formerly under VMWare.
Also Dell Technologies owns a majority stake in both of them.
GemFire came from VMware. Spring purchased[1] GemStone (which owned gemfire) while they were a division of VMware. RabbitMQ also came from VMware by way of Spring[2].
EMC, then already a public company, acquired VMware in 2004.
EMC took VMware public in 2007 when it sold 15% of its stake in an IPO.
EMC acquired Pivotal Labs in 2012. Months later, VMware and EMC each spin out a division, which included Pivotal Labs from EMC, as a new private company called Pivotal Software.
Dell announced its acquisition of EMC in 2015 which completed about 11 months later, in 2016. EMC shareholders each receive fractional shares of a publicly trading tracking stock representing Dell-EMC's interest in VMware in addition to cash for the non-VMware parts of EMC.
In December 2018, Dell went public by buying back its interest in VMware from the shareholders of the tracking stock.
So what you said about VMware being the only public part of Dell computers was true, up until the end of last year. Dell as a whole has been a publicly traded company for nearly 8 months now.
Ah this makes sense. There was this vague references in my mind that SpringSource belonged to VMware and now Pivotal is parent company for Spring. So they are all kinda together.
Yeah, they're back to owing Spring again. I wonder about the future of developer-centric Pivotal products. VMWare already acquired Spring, RabbitMQ, and GemFire back in 2009/2010 and then spun them off into Pivotal. So now that they've gone and acquired them again, will they divest again and just hold on to the K8s bits? VMWare is totally geared toward selling into IT orgs and has never seemed interested in dealing with developers.
I maybe wrong and many will vehemently disagree here. But I feel this whole Spring Boot thing and other dozens of Spring products are going to collapse like Java EE business for many other vendors.
From what I am seeing at my workplace this whole meta framework/API things that they promote is leading to atrocious application development.
The Java ecosystem is in an interesting place at the moment because it seems to me the penny has finally dropped and they are starting to prioritize footprint and startup time - probably becuase it's clear that you can't run a huge honking app server in a lambda service or even a VM that isn't horrifically expensive to rent, but the whole industry is moving towards that.
So now you have things like Micronaut that start up in milliseconds and GraalVM suddenly getting taken seriously etc. And (for example) with Micronaut you pretty much have all the advantages of Spring Boot but about 6 lines of Groovy gets you a perfectly configured REST style API end point that starts up in hundreds of milliseconds.
So it's going to be very interesting whether this "pivot" of the Java ecosystem works, and where that lands all the traditional Java vendors ....
Spring-based software launches in hundreds or even tens of milliseconds if you've precompiled on Graal. The Spring team have been working closely with Graal folks to remove roadblocks.
Disclosure: I work for Pivotal, though not on Spring.
Can you elaborate? I work on a Spring Boot application and so far we're all pretty happy with it. Obviously I'm one data point, so I'd like to hear more about what you're seeing.
Kinda tricky to explain. It like 1 line expression becomes a method what could be method becomes a whole class. What could reasonably be a class is a whole package. So this whole application I am looking at is about 10 KLOC in 100 Java source files arranged in 15 or so packages along with 100s of jars buried somewhere in maven repo.
To compare other application which I wrote in straightforward manner is about 20 Java files in 2-3 packages in total 4 KLOC and 15 external jar files. And my application 4-5 functions from business POV as compared to 2 functions in Spring boot application.
So to me it is more about some cobbled app as opposed to engineered solution which I hope to deliver. Mind you this is all my opinion as management is doubling down on Spring boot and mandate from very top is to convert all Java app in Spring boot based services.
I don't want to sound like a Spring booster, since there are plenty of criticisms of enterprise Java development that I agree with, but there's nothing intrinsic to Spring that dictates whether your business logic is spread amongst 100 files or 20.
Dependency bloat can be a concern, but part of the reason for those dependencies is to reduce bloat in source code via auto-configuration.
No idea why that is. I've been actually amazed at how much code I DON'T have to write using Spring Boot. I can focus purely on features/business logic. its great.
Yeah and you can drive dangerously with or without traffic lights. That doesn't mean traffic lights turning green in both directions at once isn't a disaster.
Having built an app recently with Spring Boot, I admire them for trying to make Spring as simple to get up and going as, say, Rails. And it's certainly better than Spring was on its own.
But in my experience it's still an enterprise-grade Frankenstein's Monster, and the developer experience is pretty bad compared with other frameworks I've used. If I was doing something on the happy path, it mostly worked. But the moment I tried to do something slightly different than they expected, I was 20 frames deep into Spring stack traces trying to puzzle out poorly written Spring code. I've done a lot of Java, so I could eventually emerge triumphant. But it was a giant time suck. Looking back on the project, we estimated we could have done it in half the time using something like Rails or Flask.
I've heard two stories about the origins of Spring Boot, one of which included Ruby on Rails. I don't remember the other being Dropwizard, so I guess now I've heard three stories, only two of them from Spring contributors.
"Magic classpath scanning", also known as "classpath scanning", comes with leveled POMs, which is a massive sanity-preserver.
Could not agree more. I think , spring boot + spring cloud is extremely popular in the services (should i say microservices world).
Not to say , there is a changing world. Frameworks like Quarkus , Micronaut , Javalin are changing these status quos (Reactive + Cloud native + First class Kubernetes / FaaS support + Being lean).
What remains to be seen though is how is Spring able to adapt and change to these. I dont know how Webflux stands up to these , but sure is interesting times ahead!
Rails, from what I remember, has a strong my-way-or-the-highway attitude. It has many strengths, but deviating from the happy path isn't it's strength. It's creator claimed it was Omakase. [1]
I guess I mean the phrase a little differently here. Rails does have a particular envelope that they support, but it is also pretty open to extensions. More importantly, if you do something slightly different, you do not end up having to debug reams of dubious, poorly tested code just to figure out how to get your nominally reasonable change to work. I spent a huge amount of time trying to figure out whether the change I really needed to make was in some XML file, some class annotation, or some custom code.
Spring boot + jOOQ + modern java is probably one of the easiest ways to build java services right now. Spring has done a good job at mostly just getting out of the way. Nothing I've seen with spring boot would have lead someone to write bad code any more than using guice.
Are you surprised that insider trading is occurring or just that it is blatantly obvious in this specific instance? This kind of thing happens regularly by all sorts of players. That's part of the reason retail investors should just buy an index fund, they can't expect to win against professionals engaging in insider trading all the time. SEC enforcement of insider trading was 51 in all of 2018. 51, out of probably millions of instances.
> That's part of the reason retail investors should just buy an index fund, they can't expect to win against professionals engaging in insider trading all the time
Investing isn't zero-sum, there's no need to "win against" insider traders.
Alpha is the degree to which an investment outperforms "the market", where "the market" can be any benchmark you want to use. So yes, by definition, alpha is zero-sum in that not everyone can beat the benchmark, in the same way that not everyone can be above average.
But this tautology isn't particularly meaningful, because most people don't care about beating "the market"; they care about their financial health and solvency, and in many cases, slightly under-performing "the market" can still be perfectly acceptable for a lot of investors if the market is performing well enough and they've met their own expected targets.
(This is, in fact, the principle behind index funds: index funds will never beat the market, and are guaranteed to underperform the market after fees are taken into account, but yet many people still put their money in index funds).
Quick anecdote: I was in a bar in NYC and overheard an i-banker running his mouth about an M&A deal he was working on. The deal closed a month or two later.
So basically you're not allowed to trade with foreknowledge, it has to be a lottery?
Stocks always seemed like legal gambling to me. If you can't predict it and you can't use any edge that others don't know about, then doing anything but using index funds is gambling, or am I missing something?
Read Matt Lewis and his writings on insider trading. As he would say: Insider trading is about theft. If you pickup a dollar bill on the ground, could you be accused of theft? Probably not...
Regarding differentiating index funds, what are those? When ducking "differentiating index funds", I find results about index funds versus ETFs (afaik an ETF is just a stock) or index funds versus mutual funds (not sure what those are). Are ETFs and mutual funds what you mean by differentiating index funds, or am I looking at the wrong thing?
> Also insurance companies are basically bookies.
Hehe yes, it also occurred to me that being in a car accident is basically winning the insurance lottery that car owners pay into.
This is incorrect. If you trade on material non-public information, it is insider trading.
The only questions you have to ask yourself are:
- is the information material? (would an average investor learning of it impact the stock price or valuation)
- is the information non-public?
If the answer to both of the above is yes, you are insider trading, whether you heard about it from a friend, family member, or overheard someone in a bar. It's not only unethical to trade on such info, it's illegal.
To be clear, these were private companies, so I obviously didn't trade on that information, but I somehow doubt that this guy was really thinking about that when he was trying to impress his date.
When an independent investment firm conducts extensive research (including hiring private eyes to track exec movements) and manages to unearth valuable information on a target company, is that counted as insider trading?
If the valuable information could damage the company, I believe it would fall under corporate espionage. But, IANAL. Others may be able to provide a better response.
And when exactly did the news become public? In my experience it usually takes minutes/hours between the event and the mass media covering it. I can bet it isn't insider trading but algorithms reacting to news faster a human can.
If I was going to execute an acquisition, I would buy a bunch of shares, or maybe some kind of derivative, well before I let anybody know what I was doing. Would that be legal?
If you are trading only based on your intentions then it would not be considered insider trading in the US. Bill Ackman did something similar with Allergan. However, you need to disclose as soon as you breach certain ownership limits.
- no legal advice of course -
To clarify, I believe it would still be illegal as a member of Congress, unless the information you are trading on is gleaned from congressional meetings or based on legislation that will be enacted.
I have never heard of Carbon black... While researching this I also found that VMWare acquired heptio for 550m !? Wow. Isn't pivotal a massive company? It's value is just 4 times that of a 2 year startup?
I cannot emphasize this enough: the most amazing thing about carbon black is there are actually options that are worse in terms of performance impact (and much, much worse in terms of increased attack surface). There was a time I would not have thought that possible.
At a large video game company I worked for we installed Perforce on the D drive because C drive was constantly scanned by carbon black among other things.
My work computer currently locks up at a precise time once a week. It is either Carbon Black or Malwarebytes but I can't diagnose it as it requires a hard reboot. IT refuses to tinker with this sacred software.
It's CB. Google "Microsoft Driver Verifier" and use it, focusing on the memory tests. I'd wager a sandwich that doing so will cause a bluescreen within ~10 minutes or so, and that those bluescreens will stop if you remove CB.
Agreed! I've gathered that it's a powerful toolset "if" tuned to your environment. But as a new midsize customer of CbDefense we've encountered many performance issues (many of them network file access related) with sensor v3.4. So rolled back to v3.2 but then found out that only Win7 endpoints could use v3.2 and Win10 requires v3.4... SMH
The lawsuit was withdrawn; VMware is no longer using GPLed drivers.
No precedent was established as to whether their prior use actually was a derivative work - personally I've always shared the VMware take on it that this was a loophole, and that if the VMkernel was a derivative work of Linux by virtue of the vmklinux compatibility layer, then Windows becomes a derivative work of any open source driver, which doesn't make any sense...
The official VMware take, at least while we were there, was that the vmkernel itself was a binary only kernel module loaded by the Console OS's Linux kernel, and as such was no different than the binary-only Nvidia driver. This was a bit sketchy, since the vmkernel linked in a different version of the GPL'd drivers in question than the ones in the Console OS, but you know, close enough.
Of course, when ESXi shipped without a console OS, but with a vmklinux and GPL'd drivers, a new take was needed.
> the vmkernel linked in a different version of the GPL'd drivers in question than the ones in the Console OS, but you know, close enough.
It wasn't "close enough" - they released the drivers/patches/modifications of those drivers, per the terms of the GPL.
IIRC they also avoided at least one network driver (I believe Alan Cox's 3com driver?) because the author had strong personal objections, and 3com actually wrote an alternative.
They also open-sourced the vmklinux API/wrapper layer itself, so the full picture pre-ESXi was:
vmklinux module - GPL'ed module for a proprietary VMkernel
vmklinux-based drivers - GPL'ed forks of drivers from the Linux source tree
console OS - GPL/open-sourced light fork of RHEL
VMkernel - proprietary, closed source (later available under shared source w/ NDA)
Hellwig's lawsuit AIUI argued that there was significant implementation, covered by copyright, in vmklinux headers and elsewhere, such that the vmklinux<->VMkernel boundary was not sufficient to prevent the latter from being a derived work of the former.
I also think that beyond that there was a strong belief and assumption in the Linux community that other parts of the VMkernel "must have" been copied from OSS/Linux as there was simply no way a random/small/private company could have possibly created its own file system, scheduler, network and disk stack, etc.
But the reality was simply that VMware had a ton of really talented and highly productive operating system experts in the early days.
[I was an employee at VMware from 2002-2011, opinions my own]
Which is funny, because that doesn't match Nvidia's legal theory as to why they're allowed to ship binary drivers. The Nvidia blob doesn't import, export, or reimplement any Linux symbols (that's relegated to an open source, dual GPLv2/proprietary bridge). The Nvidia blob is also way older than their Linux port, being the same codebase as their Windows driver. They believe that a judge will look at those facts and rule that there's no way their blob is derived from the Linux kernel. It seems like neither of those applied to vmklinux.
I'm not surprised at the Pivotal acquisition. VMware is determined to succeed at Kubernetes. There is already a lot of integration with Pivotal's Kubernetes distribution both at a technical as well as a business level.
My team and i tried leveraging different pivotal products as part of a test deployment of our current esxi managed vm deployment imagined through the pivotal kubernetes deploy.
We found that Pivotal's kubernetes makes it easy to run kubernetes on top of existing vmware infrastructure, so our ops team could continue to manage their normal vmware stack, with an admin interface to manage kubernetes clusters that live within esxi. They could provision us devs with a cluster for a specific use, and hand us the keys to do the rest.
It was pretty cool, except for the fact that we discovered kernel incompatibility with the underlying esxi version/os that brought down the entire deployment repeatedly a few days before the event where we intended to stress test the product.
The use case is definitely there for larger orgs who want to share hardware, but you also get the "on prem cloud" quick wins. Our experiment obviously failed in a low risk way, but i think the idea is sound.
I think the terminology is a little silly but presenting your devs with an abstract view of the underlying physical/virtual infrastructure is good for the ops and dev teams in terms of flexibility.
It’s a framework that makes it hard for one side to accidentally depend on something they shouldn’t.
Here i am just referring to the ease of using iaas offerings like s3 buckets but through on prem hardware. Devs build against drop in blob storage apis as if we lived in aws, and my ops guys still manage the backing vms.
As someone pointed out to me recently, while waxing poetic about VMWare and K8s, Dell owns a big chunk of VMWare.
Private Cloud buildout plays into Dell's interests, but if their execution is worse than even one Public Cloud provider, then they risk this becoming an exit strategy.
You can make a lot of money off of being an exit strategy, and for quite some time. But when the evacuation is over you have nothing.
Honestly if Dell does this well enough I could see them using some of IBM's old tricks. One in particular I'm thinking of is that IBM would overprovision the customer (installs are more expensive than dormant hardware). Fast forward to your next crunch time and you're oversubscribed, you call up IBM and they send you a piece of code to unlock the rest of the servers. No scheduling, no deliveries.
If I'm running my own server room, it turns out having a bunch of hardware around I don't use is prohibitively expensive (in part because corporations use funny math and account for labor costs in weird ways). Which kinda bums me out because I used to get excited about ideas like running servers where it's cold to save huge amounts on electricity.
But if I'm leasing hardware from Dell, then the math is simpler. Labor and travel time are the same color of money as the hardware. Installing a whole rack of servers and only leasing you a half or quarter rack at a time (and using some of the extras for hardware failure) might be more cost effective. And I'm sure IBM knew what they were doing. The immediacy of picking up a phone and having 'more hardware' today versus scheduling it three weeks out (and having the team decide to prioritize optimization work) must be more lucrative. If a little bit like drug dealing...
PVTL's public shareholders will be getting a premium price per share at $15. Michael Dell holds the vast majority of shares and will instead be getting VMware stock for Pivotal stock.
Very tangential question that hit me while reading the comments:
Is the current scenario possible: company A owns 10% of company B, and company B owns 10% of company A.
Does that mean getting the valuation of both companies require solving algebra?
Or is this outright prevented by other methods, like the board of A owns most of A and 10% of B?
There’s no reason why such a structure shouldn’t exist. I believe this how a lot of Japanese conglomerates are structured: different companies structured around a central company bank with each company owning a piece of all the others.
The contracts often say that. In practice, it's never used and vendors generally behave pretty reasonably. I work for a company that has made numerous acquisitions over the past few years. Sometimes it's not an acquisition and the other company has dissolved and the key people have accepted positions with us without transferring any assets or liabilities. I've never had a vendor forbid us from transferring licenses in either case. In fact, they usually reach out pretty quickly to update the name, contact info, etc. With some of the niche enterprise stuff, it's good business for them because the alternative probably means losing a customer. They'd rather let us keep using the software and likely pay for at least one annual renewal than try to hit us up for new licenses and we tell them to take a hike. Even huge vendors will do it though. Microsoft has let me transfer licenses before.
That kind of language in the contract is basically to prevent you from selling/transferring the license to some other unrelated company.
I asked the same thing a few years back. A lawyer friend of mine (not legal advice) said the company with the license does not need to transfer it since it's still used within the same customer: the company. The only difference is the definition of the company changed to include far more branches of employees, IP, and more.
Think about name changes for humans. You don't have to re-sign all of your contracts and potentially pay penalties for breaking and re-entering contracts in doing so. It is understood that you're still the same person but going by another identifier. Same here. Same company, another identifier.
Thanks, but the text of the license also states "All Source Code provided with Software... must be protected"
Yet particular license type is dependent on size of organization. A+B entity is clearly not the same as just entity B so something needs to be done in regards of this, no?
I don't know of any resources for this, though I'm sure there are some good pages on this that are googlable. Here is my experience, having owned a few tiny positions in stocks that went through a merger.
- The moment the merger terms became public, your stock got the merger priced in by the market makers - minus a small discount representing the chance that the merger won't go through. Now it's going to trade mostly pegged to the parent stock, as if the merger had already happened (or flatline, if the buyout was all in cash). To keep shareholders happy, mergers usually happen at a 20-50% bonus over the purchased company's stock price, so this is a great event for you - the parent company just boosted your position.
- Your broker will automatically execute the merger transaction for you. The stock will disappear from your account, and a commensurate amount of cash and/or parent company stock will re-appear. This should show up under "Corporate actions" in your brokerage account or similar.
- I'm not aware of anything special that will happen otherwise. The merger closing (usually in 6 months or so) will represent the removal of uncertainty, which will give your position a bump, but that bump is usually tiny. So you can sell if you have reason to believe the deal won't go through (watch out for short term cap gains), or hold, if you like the parent company.
This was really helpful, thank you! As far as short term capital gains, the stock recently cut in half due to an awful quarter—-I think with the bump from this news I’m still down 20%. But it’s okay, glad to have recouped some losses.
It’ll be interesting to see how things pan out regarding k8 whether companies will host it on VMs or bare metal. I guess VMWare are hoping to still be in the mix else k8 has the potential to completely erode their vsphere business.
I've been seeing this mistake a lot. Just to clear up confusion for people: K8s is not plural. It's a shortening convention (similar to i18n) where you trim the middle letters out of a long word and replace it with the number of characters you've trimmed. K(ubernete)s = K8s because "ubernete" is 8 characters. K8 is never the correct word to refer to it.
K8s was written by a hopeful public cloud giant to cut off the dominant public cloud giant in the container orchestration space.
It shouldn't be surprising that it is very oriented around VMs hosted and manged by public cloud providers. Bare metal is at best an afterthought, and at worst explicitly disadvantaged.
Oracle and IBM are better known for killing things they acquire than enhancing them. The money doesn't outweigh the executive overhead.
And it's not that vmware is bad, it's that they're big, enterprise'y, and slow. They'll make their money selling VM management software to companies that can't adapt to the cloud. But that's what they do - they make their money selling software to companies that can't adapt.
