* "Subscription and support" revenue is about $150M, with "professional services" about $30M. This is a software company with a services side, not the other way around. That's good as software companies tend to be valued around ~10x revenue and services companies only around 3x revenue.
* The company made $180M revenue in 2016, growing at ~70% / year, so it's probably on a ~$250M run rate right now.
* Last round of funding was raised at a $1.5B valuation. I imagine they'll try for 10-12x revenue, or $1.8B - $2.2B. Twilio is currently trading at around ~10x revenue.
* Sales & marketing spend is very heavy -- $122M of their $240M expenses, so about half, were due to sales and marketing. Engineering aka "research and development" only costs them 1/4 of that, or $30M / year. That's...okay I guess? It means growth is pretty expensive, but if they ever want to dial back that growth, they can rake in the $.
* Ownership: Big VCs own 68% of the firm, the original founder owns 6%, the current CEO owns 3%, other execs own another couple percent. Ownership of the other ~20% isn't clear, prob split between smaller VCs and employees.
Their main product is an Enterprise Service Bus, a piece of technology that is supposed to help make it easy for software developers to integrate with multiple disparate third party solutions (and potentially internal solutions). So you can get a "Connector" for SAP, and another for Salesforce and consolidate, transfer or do practically whatever with the data in both systems, without having a bunch of developers working on an in-house solution to consume the requisite APIs.
My one criticism of them would be they focus very heavily on cloud, and their on-premises offering is woefully anaemic, lacking fundamental functionality, such as messaging.
Catchy, but no. Mule ESB is more like a framework for declaratively creating (and executing these) flows that run through a series of components that react to events, in a sort of universal design pattern; these flows then execute in in a runtime that uses SEDA [1]. They give you some built-in components that help in creating APIs, and this design is a good fit for APIs and data munging, but it can be used as "just" a runtime for event-driven code. For a clearer example, see my other post here [2]. Their other products include an API proxy and a client-facing API gateway.
> Mule ESB is more like a framework for declaratively creating (and executing these) flows that run through a series of components that react to events, in a sort of universal design pattern
I hope I don't sound too snarky here, but from bird's-eye view, this description sounds like business-speak for:
"It could have been normal programming with external services, with all perils and pitfalls. But in addition to the common pitfalls, you get a badly designed domain-specific language (DSL), using XML syntax to make it even harder to understand, with the promise that you can hand it over to non-programmers, except that you need programmers to extend the DSL with custom components anyway, to make it actually work for you."
Hoping this superficial judgement is wrong: How does the real product deviate from that snarky description?
Apart from the non-programmers bit, you're not wrong.
I've been using the open source version on a project between 2013 and 2015 and it was exactly as you described: it essentially was a very convoluted and un-debuggable way of attacking a class of trivial problems, on which it failed miserably.
Basic functionality (watch a directory for incoming files, apply some processing, move the files to a second directory) would fail without any useful error message. You could "program" it by writing XML files with an Eclipse plugin, but anything non-trivial would involve hundreds of lines of "magic" XML.
Worked with the on-premise version, and I'd avoid it like the plague. Badly designed mix of XML and old-school Java, if it wasn't for political reasons we would have kicked it out.
XML/Java is very much it's ancestry. Back in the day, it competed eye-to-eye with ServiceMix and Camel. Both of those have remained firm Apache products. Mule ESB was heavily commercialised, for better or worse.
I applaud Mulesoft for going public. Too often today large (well past series C) tech companies (I won't name any names) refuse to go public and instead continue to take private equity and foreign investment and prop themselves up on absurd valuations with no-checks and balances. Some of these companies are absolute dog shit, yet they continue to receive unlimited funding and insane valuations in a vacuum with no market to short them.
Wall Street calls bullshit when they see it, and smart people short bad companies when they find them. Silicon Valley doesn't provide a way to short these propped-up companies, they just continue to self-promote themselves on private equity and foreign investment.
There are rumors of Dodd-Frank getting repealed [1].
Afaik Dodd Frank had increased the reporting burden of companies to the point where it was much more difficult to IPO at a .com era revenue stage. So maybe its repeal will have the side benefit of allowing young but operationally strong companies to use IPO as a viable fundraising avenue again.
I thought Sarbanes-Oxley, which added a lot of reporting/disclosure requirements for public companies and was passed in the wake of Enron and Worldcom scandals in the early 2000s was the primary driver behind the drop in IPOs? What provisions in Dodd frank are there that effect this?
Dodd Frank was intended to make the derivatives markets more transparent and prevent banks from taking excessive risk. I don't think it has had any effect on the IPO market or tech companies at all.
Love it. Mulesoft was a customer at my previous company and I always enjoyed working with them. Good luck for their IPO - it's a good thing for the ecosystem to see more tech companies going public this year.
The old terminology was ESB, or enterprise service bus. It's Java based, and basically feels something like Tomcat, but with a bunch of add ons. Things like api management, various protocol connectors, data translation, pre-built integrations, and so forth. Like a hub that can run your code, plus talk to most of what you already have.
They make a couple products that work well together. Mule ESB acts as a container for flows, which are declaratively-written processes of canned components that do a specific thing (like make an SQL query, make API calls, or call your custom code), or EIP components [1] that manipulate the execution flow. They give you a visual editor to drag-and-drop build these flows, or you can write them by hand in XML. You deploy them in Mule ESB and they run indefinitely, accepting messages, say, on HTTP ports, or firing at set times like cron-jobs, or the like; the runtime detects most crashes and restarts the particular flow if something goes weird. If this kinda sounds like Erlang/OTP you're not entirely wrong, but, let's not go there...
(okay, so the canned components are sometimes quite nice, whereas in vanilla Erlang you're on your own. The value something like Mule brings is more the abstractions and the ecosystem, even if the Java runtime is of no intrinsic help. Also, see RabbitMQ's slides on Erlang [2]. Mule isn't an outward-facing message middleware like RabbitMQ, but behaves a lot like one on the inside. It also gives canned components to interact with them.)
A Mule flow is often basically mid-level business logic plumbing; you don't want to put these flows on the public internet without rate limiting, authentication and authorization -- you want to use some API gateway or proxy in front. Mule has one, called Mule API Gateway, and the front-facing portal API Manager. Then the rest of the 'Anypoint' branded stuff is value-add: metrics, more connectors, SaaS stuff, etc. Overall, it's a pretty solid offering for when you need to do either lots of data munging or you gotta write APIs for a legacy backend; needs common in big orgs.
It looks like the acquisition price per share ($17.40) was right around their IPO price of $17, so options wouldn't be underwater.
But before that the stock traded as low as $6. So during this time the employees' stock was underwater, whereas C level will have been able to sell a portion of their shares at IPO (vs employees waiting for their 6 month lockup to expire).
But the stock had recovered to $16+ before the acquisition so... I mean it's a public company. "Up and to the right" isn't always the case
Ouch. What is the justification for the lock up period? Is the idea that employees are somehow going to flood the market? Is the volume of vested options for the average worker bee really that high at the time of IPOs? Its seems like the plebes get burned a fair amount.
Yea, it's to keep the price somewhat stable after the IPO. It's a very standard thing to do and the share price of a company usually drops permanently when the lock up period expires.
Maybe a good rule of thumb is 10-20% of the company could be owned by employees at the time of IPO which could materially change the share price.
* "Subscription and support" revenue is about $150M, with "professional services" about $30M. This is a software company with a services side, not the other way around. That's good as software companies tend to be valued around ~10x revenue and services companies only around 3x revenue.
* The company made $180M revenue in 2016, growing at ~70% / year, so it's probably on a ~$250M run rate right now.
* Last round of funding was raised at a $1.5B valuation. I imagine they'll try for 10-12x revenue, or $1.8B - $2.2B. Twilio is currently trading at around ~10x revenue.
* Sales & marketing spend is very heavy -- $122M of their $240M expenses, so about half, were due to sales and marketing. Engineering aka "research and development" only costs them 1/4 of that, or $30M / year. That's...okay I guess? It means growth is pretty expensive, but if they ever want to dial back that growth, they can rake in the $.
* Ownership: Big VCs own 68% of the firm, the original founder owns 6%, the current CEO owns 3%, other execs own another couple percent. Ownership of the other ~20% isn't clear, prob split between smaller VCs and employees.