Pivotal was spun out of EMC and VMware.

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.

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].

[1] https://spring.io/blog/2010/05/06/springsource-to-acquire-ge...

[2] https://web.archive.org/web/20100418132113/http://www.rabbit...

I didn't know that! An interesting history.

RabbitMQ was its own startup for a number of years (I think called "Rabbit Technologies") before it got the attention of the SpringSource/VMWare crew.

How disruptive have the ownership changes been over the last few years? From going public now back to private?

ANY thoughts on the strategic value if PVTL under the VMware umbrella? Already close partners will the acquisition really make any difference?

Dell owns VMWare, and it could be seen as the only public part of Dell computers, so that's why they are using it to backdoor into the market.

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.

Would you classify this as a new version of a reverse merger?

Yeah, Redhat with their openshift vs VMware with heptio/pcf.

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.

Its possible to write bad code with or without any framework.

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.

Been a happy user of dropwizard, what spring boot was "inspired" by, hookup guice and no spring magic classpath scanning to be seen

https://www.dropwizard.io/1.3.14/docs/getting-started.html#g...

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]

[1] https://dhh.dk/2012/rails-is-omakase.html

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.