VMware Acquires Carbon Black for $2.1B and Pivotal for $2.7B
techcrunch.com
techcrunch.com
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.
personally i enjoy it because of insightful comments
"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."
Interesting that the IPO price was also $15.
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.
Potentially.
"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.
Famously, Apple has always refused.
From EMC came Pivotal Labs, Greenplum and I think GemFire. From VMware came Spring and Cloud Foundry. Not sure which one RabbitMQ came from.
Disclosure: I work for Pivotal.
[1] https://spring.io/blog/2010/05/06/springsource-to-acquire-ge...
[2] https://web.archive.org/web/20100418132113/http://www.rabbit...
ANY thoughts on the strategic value if PVTL under the VMware umbrella? Already close partners will the acquisition really make any difference?
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.
From what I am seeing at my workplace this whole meta framework/API things that they promote is leading to atrocious application development.
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 ....
Disclosure: I work for Pivotal, though not on Spring.
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.
Dependency bloat can be a concern, but part of the reason for those dependencies is to reduce bloat in source code via auto-configuration.
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.
https://www.dropwizard.io/1.3.14/docs/getting-started.html#g...
"Magic classpath scanning", also known as "classpath scanning", comes with leveled POMs, which is a massive sanity-preserver.
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!
https://www.cov.com/en/news-and-insights/insights/2018/11/se...
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).
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?
Also: https://en.wikipedia.org/wiki/Mosaic_theory_(investments). So you can get an edge by sourcing information from various places and piecing it together better than anyone else... that's fine as well.
> If you pickup a dollar bill on the ground, could you be accused of theft? Probably not...
Depends on the country - in some countries, yes, that is actually considered theft.
> 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.
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.
Edit: by "I" I mean the company, not the CEO.
"Forcing a System Crash from the Keyboard":
https://docs.microsoft.com/en-us/windows-hardware/drivers/de...
But it's probably cheaper still to buy that off with a juicy "Platinum Member" seat at the Linux Foundation.
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...
Of course, when ESXi shipped without a console OS, but with a vmklinux and GPL'd drivers, a new take was needed.
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]
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.
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.
"Like a cloud but closer to you" :)
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...
https://en.m.wikipedia.org/wiki/Renault–Nissan–Mitsubishi_Al...
If company A owns/purchased license for a product issued by company C.
The license clearly states:
"Licensee may not resell, rent, lease … the Source Code or any part of it … "
And now company A gets sold to company B.
What should happen in this case with the License? Whom the License belongs now? Shall it be revoked or what?
How to deal with such situations in practice?
That kind of language in the contract is basically to prevent you from selling/transferring the license to some other unrelated company.
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.
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?
- 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.
https://www.theregister.co.uk/2019/07/29/pivotal_ceo_intervi...
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.
Even moderately modern applications still need a lot of work to be ported to a "container native" platform to run properly following best practices.
The sea of legacy out there will keep VMware's virtualization business afloat for a long time.
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.
Even if it was Oracle or IBM, big money solves some problems.
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.