
Pivotal Software S-1 - brendino
https://www.sec.gov/Archives/edgar/data/1574135/000104746918002061/a2234898zs-1.htm
======
stickfigure
I consulted at Pivotal on and off over the last several years and got an up-
close look at the process. This a _heroic_ feat.

In a short matter of years, they took a consulting services company, adopted
some poorly designed abandonware from VMWare, and rebuilt it into a product
that now serves some of the biggest companies in the world. Pretty much
everything has been rewritten and almost all of it is available in github.

CloudFoundry is not sexy software. It's basically Heroku that big stodgy
companies can run in-house. Startups will never use it; they can use actual-
Heroku. The crazy thing is that Pivotal supports these huge enterprise
software installations inside other people's data centers, often without
direct access. It's really, really hard work.

I really hope this makes a bunch of my friends rich - they deserve it.

~~~
chubot
Interesting... I was watching a bunch of Cloud Foundry talks on YouTube around
the 2010-2012 era (my memory is hazy).

What happened to it? Why did VMWare abandon it? As far as I remember it was
written in Ruby / Event Machine. As I understand it, Heroku also has large
parts in Ruby, so that isn't a problem by itself.

How did Pivotal get involved? Were they hired by VMWare, and then they took it
over?

Why / how did they rewrite it?

I had some ex co-workers who consulted for Pivotal around 2005-2006, and I
have seen their name pop up from time to time. Pivotal tracker seems somewhat
popular, and then I remember their name popping up again around Cloud Foundry.

It's nice to see that they turned it into something. It does seem like a nice
success story for "open source cloud". This was around the same time that
OpenStack was getting going too, but it seems like the success of OpenStack
has been more mixed.

~~~
stickfigure
Let me see if I can get the cronology right:

    
    
        * EMC bought VMWare
        * EMC bought Pivotal
        * EMC moved all the enterprisey software to Pivotal (including CF & Spring)
        * Dell bought EMC
        * Dell/EMC spun off Pivotal
    

I arrived shortly after CF moved to Pivotal, so much of this is lore: VMWare
had been working on CF for years; they started a 2.0 rewrite which went out of
control (with a huge expensive team of primadonnas); EMC basically pulled the
plug and gave the software to Pivotal, who built a new team more-or-less from
scratch (the only remnants of the original team were ops people). When I was
there we were still doing a lot of "forensic programming" or as they say at
Pivotal, building context.

When I say "pretty much everything has been rewritten" I mean it has evolved
like that; they didn't sit down to rewrite CloudFoundry (Pivotal does not do
rewrites as a cultural axiom). I mean that piecemeal pretty much every bit of
code has been altered in significant ways. A lot of the Ruby has been swapped
out for Go for performance and maintainability reasons. It was pretty funny to
watch a large body of die-hard Rubyists get excited about static types (come
to the light!).

As a consultant I was really a fringe player; I'm sure there are people
reading this who are/were much more involved and could tell the story better.

The thing I found most interesting is that this project _should have failed_.
A HUGE incredibly complicated body of enterprise software with near-100% team
turnover? I would have bet against it ever working. But all that pair
programming and rotation and writing stories and backfilling tests etc just
eventually ground the problem down. It was expensive as hell and it took years
but it looks like a success story now. I don't know of any other big takeover
project like this that worked. It's a huge credit to the people working on it,
and yes - to the "Pivotal process" that seems to irk so many people in this
thread.

~~~
chubot
Wow didn't realize it was so tangled. Considering all that turnover, it's even
more of a miracle! Thanks for the recap.

I agree with the philosophy of "grinding it down". Writing quality software is
largely about doing the straightforward thing, and not regressing, for years
on end... At a certain size, it's too big for any heroics to make a
difference, and you have to rely on plain old "engineering" (tests,
prioritization, etc.)

------
abuckenheimer
_We do not control and may be unable to predict the future course of open-
source technologies, including those used in our offering, which could reduce
the market appeal of our offering and damage our reputation._

This is a really cool risk factor that I've never seen before in an S-1,
exciting that more big public companies are willing to accept the risk reward
that comes with contributing to open source:

 _If open-source software programmers, many of whom we do not employ, or our
own internal programmers do not continue to use, contribute to and enhance the
open-source technologies that we rely on, the market appeal of our offering
may be reduced, which could harm our reputation, diminish our brand and result
in decreased revenue. We also cannot predict whether further developments and
enhancements to these open-source technologies will be available from reliable
alternative sources. If the open-source technologies that we rely on become
unavailable, we may need to invest in researching and developing alternative
technologies._

~~~
volume
I wonder if Red Hat's S-1 said anything similar.

~~~
nemo44x
Their quarterly reports always have similar wording, to wit:

 _" If open source software programmers, most of whom we do not employ, do not
continue to develop and enhance open source technologies, we may be unable to
develop new technologies, adequately enhance our existing technologies or meet
customer requirements for innovation, quality and price.

We rely to a significant degree on a number of largely informal communities of
independent open source software programmers to develop and enhance our
enterprise technologies. For example, Linus Torvalds, a prominent open source
software developer, and a relatively small group of software engineers, many
of whom are not employed by us, are primarily responsible for the development
and evolution of the Linux kernel, which is the heart of the Red Hat
Enterprise Linux operating system. If these groups of programmers fail to
adequately further develop and enhance open source technologies, we would have
to rely on other parties to develop and enhance our offerings or we would need
to develop and enhance our offerings with our own resources. We cannot predict
whether further developments and enhancements to these technologies would be
available from reliable alternative sources. In either event, our development
expenses could be increased and our technology release and upgrade schedules
could be delayed. Moreover, if third-party software programmers fail to
adequately further develop and enhance open source technologies, the
development and adoption of these technologies could be stifled and our
offerings could become less competitive. Delays in developing, completing or
delivering new or enhanced offerings could result in delayed or reduced
revenue for those offerings and could also adversely affect customer
acceptance of those offerings."_

~~~
volume
I love google - add Nutanix to the list: [https://content.edgar-
online.com/ExternalLink/EDGAR/00016282...](https://content.edgar-
online.com/ExternalLink/EDGAR/0001628280-16-021886.html?hash=cdc34100084c5c75f511282107969b4862bb55b823cd56f569bc6f97c91f95f4&dest=EX31-10312016X10Q_HTM#EX31-10312016X10Q_HTM)

"If open source software programmers, most of whom we do not employ, do not
continue to develop and enhance open source technologies, our development
expenses could be increased and our product release and upgrade schedules
could be delayed."

------
nathanaldensr
A few months ago, I was working a contract at Idaho National Laboratory as a
senior DevOps engineer. I recommended they try Cloud Foundry since they were
doing a lot of things manually and had a pretty immature CI/CD pipeline;
additionally, I was involved in a PCF project at General Motors. INL runs
VMware vSphere, which is _the_ platform to run PCF on in-house. I got approval
to bring in Pivotal and, through mostly my teammate's and my hard work, we
managed to get it running. Props to the helpful sales guy and architect we
were assigned. They were available to answer some very detailed questions and
did not disappoint with their knowledge and enthusiasm.

PCF is very solid. The only issues we ran into were some confusing
configuration settings and your basic federal government bureaucracy nonsense.
Once we got all the IaaS boxes ticked, it installed without issue and worked
beautifully.

I'd never want to install or maintain open-source Cloud Foundry as it's a
nightmare of complexity; however, PCF is a different animal because of its
streamlined installer. I definitely recommend giving it a go if you're looking
for on-premises PaaS and you've got the IaaS layer to support it. You can also
demo PCF within a single VirtualBox VM.

------
theossuary
It's interesting how much the filing seems to revolve around PCF. I played
with PCF a few years ago and was really unimpressed. More recently I've been
consulting with firms using PCF and the devops guys there seem to really like
it and Bosh, so it may have gotten better at least.

That said, I just can't understand why you'd ever pick PCF over Kubernetes.
Sure, I get one deploys application code, and the other deploys containers.
But after using the buildpack system for a while, I really think containers
are the better solution (assuming you have the CI/CD to keep your custom
containers up-to-date with new base images).

So it'll be interesting to see what Pivotal does there, and how they position
PCF, especially now that they have their own branded version of Kubernetes[1].

[1]. [https://content.pivotal.io/announcements/introducing-
pivotal...](https://content.pivotal.io/announcements/introducing-pivotal-
container-service-pks-the-simple-way-to-bring-kubernetes-to-enterprise-
customers)

~~~
Tossrock
They also happen to sponsor the development of Concourse CI, which is a great
CI/CD tool.

------
raywu
> We are focused on subscription sales of our platform. Since announcing PCF
> in November 2013, our subscription customer count has grown rapidly to 319
> as of the end of fiscal 2018. Our subscription revenue was $95.0 million,
> $150.0 million and $259.0 million for fiscal 2016, fiscal 2017 and fiscal
> 2018, respectively, representing year-over-year growth of 58% and 73% for
> our two most recent fiscal years.

~~~
tschellenbach
How does PCF pricing work and what do those revenue numbers mean in terms of
margins?

~~~
sk1ppy
Their pricing was based on application instances and the list price was
ludicrous (several hundred dollars) but most companies got good discounts.

The thing that bothered me with the model was it disincentives modern
microservice architectures. One big monolith cost less than lots of smaller
components.

It may have changed since I last saw the details.

~~~
zapita
This is still the case. Even after enterprise discounts, the pricing is
outrageously high. I know of at least one well-known enterprise customer where
IT has mandated a company-wide "get off Pivotal" policy because TCO is just
too damn high.

I hope for Pivotal's sake that the eye-popping price is not crucial to their
growth forecast. If it is, I think 2019-20 will be difficult for them. They
just don't have the market share to force these prices down customer's
throats.

~~~
bigiain
They tell us there that 319 customers paid $259 million between them in fiscal
2018 - so on average each customer pays $800k/year. They'll have outliers in
both directions from that average - But my gut feel is they probably don't
have many customers spending less that $80k/year. (Same as I'll bet there's
not too many $8mill+/year ones).

~~~
zapita
Account size and pricing are two different things.

The question is: are the $800k customers getting good value for that
subscription, or are they looking at projected costs and thinking "we better
switch to a competitor before this gets out of hand".

~~~
bigiain
The YoY growth rates suggest they're at least capable of convincing new
business that it's good value.

(Though in enterprise sales, even amazingly poor vendors often get to re-bill
for several years, until the exec who signed off on the subscription moves on
and it becomes politically possible for people internally to admit to each
other it was a stupid decision to sign up in the first place... So perhaps 2
years growth here is only telling the "sales capability" side of the story,
not the "ongoing value provided" side...)

~~~
zapita
Right, that's what I've witnessed anecdotally: strong ability to sell, usually
as part of a top-down "digital transformation" project with tons of agile
development consulting and multi-year sales cycle; then a few years of abysmal
results, covered up by the project sponsors, then eventually a purge once the
sponsoring exec is replaced.

~~~
bigiain
Heh - exactly.

And the other similar version: tightly fought procurement between two opposing
vendors with different internal "sponsors". Winning vendor's ability to
deliver is stymied at every opportunity by losing sponsor or their internal
supporters. Then the few years of abysmal results happens in spite of winning
vendors capability and efforts - same outcome plays out.

------
flerchin
I interviewed with Pivotal Labs this week. It went well and they wanted to
move forward until I asked for my current compensation. They balked like I was
asking for the moon. I coincidentally had an offer from another firm for a 15%
raise, so I know I wasn't asking for too much. Pivotal declined when I
wouldn't budge, and I took my 15% raise. I start in 3 weeks.

~~~
yesiamyourdad
I had a similar experience a couple years ago. The interview was pretty hard,
6 hours of pair programming in Go, a language that I have only passing
familiarity with. The interviewer seemed impressed that I completed the entire
task with time to spare. Then it got to talking about salary and that's when
things seemed to go sideways. I make top of market for my area, because I've
been doing this a long time and I have a history of success so past employers
have rewarded me for it.

I think the thing is that in consulting, the equation is "margin = billable
rate - salary". The higher the salary, the less profitable you are. Feels to
me like Pivotal mostly hires mid-level people to hit the sweet spot of
experience/skill/salary.

It's a bummer because I went on to work with a company that engaged Pivotal
Labs and I loved working with the Pivots.

------
vbsteven
If I’m not mistaken they are also the driving force behind the Spring and
Spring Boot frameworks. Probably the biggest Java framework out there.

~~~
wlindner
That is correct [https://pivotal.io/spring-app-
framework](https://pivotal.io/spring-app-framework)

------
sinkholes
This series of posts from a former Pivotal employee provides interesting
context:

[https://matt.sh/anatomy-of-a-fraud](https://matt.sh/anatomy-of-a-fraud)

[https://matt.sh/commit-this](https://matt.sh/commit-this)

[https://matt.sh/dumb-pivotal-2018](https://matt.sh/dumb-pivotal-2018)

~~~
zbentley
That person sounds really poorly-adjusted, agenda'd, and borderline-hateful.

Not only are many of his claims dubious, unwarranted, or hyperbolic, but there
are a few gems like this:

> Remember when the CEO globally emailed a picture of his ugly newborn and
> drugged up post-birth wife to the entire company because he thinks we all
> submit to his cult of personality?

It's not uncommon for that to happen. People share pictures of their new kids
to their departments and whole companies all the time. Usually it's because
new kids are a joyful experience, for, y'know, humans in general. CEOs do it
too--for cynical reasons or not--and raging against that, to say nothing of
the criticism of the "drugged-up" mother (epidural anesthesia is incredibly
helpful and medically essential in tons of births), displays a somewhat
shocking failure to grasp typical corporate-people behavior in America _at
best_ , and an axe-to-grind willingness to engage in ad-hominem slander of
people's families at worst.

Even if any of his claims have merit, I have a ton of trouble believing
anything from someone who talks like that.

------
mephitix
The only two experiences I had with Pivotal were with RabbitMQ (a very well
designed product) and with Pivotal Tracker - I tried it about a year ago. I
felt like I was fighting the software; they were extremely stubborn about
adhering to Scrum 'best practices' that may not work in practice.

~~~
brobinson
I got to work with some Pivots at their office about a decade ago and learned
to use Tracker from them. It's the only system I've ever seen that works well
and gives predictable results over time.

Almost every company I've been at has used abhorrent alternatives like Asana,
Jira, etc. and they've been consistently awful experiences.

~~~
mephitix
I tried and eventually got tired of Jira, Trello, Team Foundation Server, and
Pivotal Tracker.

The one tool that I've been loving for the past year is
[http://clubhouse.io](http://clubhouse.io). Such a well-designed product and
extremely flexible (I think it could fit most teams' requirements around
Agile/Kanban/etc.)

~~~
brobinson
I will check it out. Thanks!

------
kertis
Ok, I was working some time with Cloud Foundry as sysadmin/devops. It's big
fucking enterprise piece of software which nobody know exactly how to install
it and maintain. Their guide on site is obsolete, it's almost unrealistic to
understand in nutshell how it works (compared with Kubernetes/Mesos-Marathon).
Only info on Github pages were useful.

CF even can't even survive unplanned reboot of DC, after such incidents you
literally will get parted cluster and no one know what to do.

Thank you Pivotal for such experience.

------
m0meni
This is the first I'm hearing of Pivotal. Are they a cloud provider or
something? I'm having a hard time figuring out exactly what they do from their
website.

~~~
Pixeleen
They are a super trendy development and cloud consultancy firm based in San
Francisco and New York. They have all the right words and everything.
Pretentious start time of 9:06 am, signalled by a gong. All pair programming
on iMacs. I visited their very shiny office for a tech talk. Two employees
(they call themselves Pivots) used the exact same language to describe how
good the strict schedule is. I struck up a conversation with a gentleman
wearing their logo. He seemed visibly taken aback when I asked what his role
is. Turned out to be C-level and giving the presentation.

~~~
stickfigure
This is unnecessarily cynical.

I did a couple consulting stints at Pivotal, working on the CF team. They have
a very particular methodology that evolved from the earliest days of agile
(Rob Mee was a friend of Kent Beck back when XP was being worked out). I
walked in there as a _very_ experienced engineer and a healthy amount of
skepticism... and it turned out to be a fantastic learning experience. I've
since taken the Pivotal process (yeah, even the weird stuff like pair
programming) and used it effectively to manage subsequent companies.

I don't love everything about Pivotal (neither Ruby nor Go make my favorite-
languages list) but then, not everyone at Pivotal does either. But overall
they do agile right, and they have a lot to show for it. You can mock 9:06 but
also note that people _go home_ at 6pm and have lives. The schedule has its
upsides.

~~~
sheepmullet
> This is unnecessarily cynical.

I think it's pretty clear that these strict agile processes work well for some
and poorly for others - some people do better in a highly structured
environment and others do worse - it's a bit like remote work on the other end
of the spectrum.

The criticism and pushback comes from the negative experiences devs have had
when management pushes a one-size-fits-all approach.

I've been involved in more than 5 failed agile methodology process improvement
initiatives. I've seen great engineers reduced to a tiny fraction of their
former productivity and seen other "hopeless" engineers get a lot better.

~~~
cbryan
It's a great process for reigning in "great" engineers that produce a ton of
technical debt. It's a fantastic approach for making your engineering team
more stable and product delivery more predictable.

~~~
sheepmullet
> It's a great process for reigning in "great" engineers that produce a ton of
> technical debt

So any positives can safely be attributed to the new process and any negatives
are clearly just the new process shining a light on existing problems.

Gotcha.

And the parent poster was wondering why people were so cynical.

> making your engineering team more stable

Can you expand upon what you mean by more stable?

One of the main selling points to management is it becomes much easier to
switch developers between teams.

> product delivery more predictable.

In what sense? And through what mechanism?

It does reduce risk on short term deliverables but that's a very narrow
interpretation of predictable.

It's certainly not the case as an external customer - trying to nail down an
xp team to a fixed deadline more than a few weeks away is an exercise in
frustration.

------
exelius
Ironically, this ends up being pretty much a spin-off since the companies
which founded and own Pivotal are working on a merger themselves.

We’re back to this model of “innovation” I guess.

------
jedberg
Interesting. I wonder if it is coincidence, or if they timed this to ride on
the Dropbox IPO.

~~~
brendino
It's related to the Dell - VMWare reverse merger. They have to raise cash to
fund the merger.

~~~
jedberg
That makes sense. I didn't put that together.

------
bgentry
The ownership breakdown is so unusual compared to typical VC-backed startup
IPOs. Pivotal has had an interesting run with their history of acquisition and
spinoff. Also the Pivotal (cloud infrastructure software) vs Pivotal Labs
(consulting) split.

[https://www.sec.gov/Archives/edgar/data/1574135/000104746918...](https://www.sec.gov/Archives/edgar/data/1574135/000104746918002061/a2234898zs-1.htm#ea42701_principal_stockholders)

------
nicodjimenez
Wow 270 million dollars a year I had no idea they made that much money.

~~~
jyriand
Are you talking about Gross profit? I'm not an accountant, but by the looks of
their financial data, Pivotal is consistently losing money. I'm talking about
Net loss 163 million.

------
cavisne
Does netflix use a lot of pivotal stuff? I always thought of that as a plus as
netflix is a pretty strong engineering org.

~~~
delias_
Spring is probably the only thing. All the rest of the stuff on the tech blog
and Netflix OSS is heavily AWS centric, even the container platform Titus.

Spring Cloud includes a lot of the Netflix OSS stuff though like Zuul and
Archaius.

------
0003
This is like proposing to the maid of honor.

------
josephjacks
I tweeted an analysis of the S-1:

[https://tinysubversions.com/spooler/?url=https://twitter.com...](https://tinysubversions.com/spooler/?url=https://twitter.com/asynchio/status/977255923172352000)

~~~
austenallred
It wants me to log in to see your tweets?

