FOSS4G 2017 Keynote
16 Aug 2017
I did my keynote presentation at FOSS4G 2017 today. Here’s the PDF version of the slide deck and notes.
Why we code from FOSS4G Boston 2017 on Vimeo.
And there’s the video!
16 Aug 2017
I did my keynote presentation at FOSS4G 2017 today. Here’s the PDF version of the slide deck and notes.
Why we code from FOSS4G Boston 2017 on Vimeo.
And there’s the video!
08 Aug 2017
Because I was asked.
We can't wait to see all the other goodies on your list! #foss4g https://t.co/RkNhQR3wkW
— FOSS4G 2017 (@foss4g) August 8, 2017
Here’s my 2017 FOSS4G list:
One week and I’ll be in Boston, looking forward to it!
22 Jun 2017
Matt Asay asks a question about big data vendors, who are from a business model point-of-view mostly “open source support” companies: HortonWorks as a pure-play and others as open-core and enhanced-oss models.
Is the problem that orgs roll-their-own Spark/etc. (self-support on OSS)? Or maybe most orgs simply aren't doing much (yet) w/ big data? https://t.co/9RGZyEUaV4
— Matt Asay (@mjasay) June 22, 2017
My experience has been that open source support companies fall into a market trap. They are supporting good projects, that are popular and widely deployed. It seems like a good place, but the market keeps constantly screwing them.
Potential open source support customers are either:
Small customers lack the technical wherewithal to use the product unassisted, so they need the support, but they are both highly price sensitive while also being a large drain on support hours (because they really need a lot of help).
You can drop your prices to try and load up a lot of these (“how do we do it? volume!”) but there are rarely enough fish in the pool to actually run the size of business you need to achieve sustainability.
How large? Large enough that the recurring revenue is enough to support sales, marketing, cost of sales, and a handful of core developers who aren’t tied to support contracts. Not huge, but well beyond the scale of a dev-and-friend-in-basement.
If you do drop your prices to try and bring in the small customers you immediately run into a problem with big customers, who will want big customer questions answered at your small customer price point.
Big customers are frequently drawn to the scaling aspects of open source: deploy 1 instance, deploy 100, the capital cost remains the same.
In theory, there should be room in there for a “one throat to choak” support opportunity for big customers with big deployments, and with competent sales work up front, a good support deal will monetize at least some of the complexity inherent in a large deployment.
In practice, instead of being long term recurring revenue, the big customers end up being short term consulting gigs. A deal is signed, the customer’s team learns the ropes, with lots of support hours from top level devs on your team, and the deployment goes live. Then things settle down and there is a quick scaling back of support payments: year one is great, year two is OK, year three they’re backing away, year four they’re gone.
While there is room to grow a business on this terrain, particularly if the customers are Really Really Big, the constant fade-out of recurring revenue means that the business model is that of a high-end consultancy, not a recurring-revenue support company.
20 Jun 2017
I’ve been adding support for arbitrary CURL options to http-pgsql, and have bumped up against the classic problem with linking external libraries: different functionality in different versions.
CURL has a huge collection of options, and different versions have different support, but for any given options, what versions support it? This turns out to be a fiddly question to answer in general. Each option has availability in the documentation page, but finding availability for every option is a pain.
So, I’ve scraped the documentation and put the answers in a CSV file, along with the hex-encoded version number that CURL exposes in #define LIBCURL_VERSION_NUM.
If you need to re-run the table as new versions come out, the Python script is also in the Gist.
09 Jun 2017
There are several nuggets in this webinar by David Eaves, but the one that really tickled my brain was the distinction between two almost identically named roles: project manager and product manager.
The lexical difference is, of course, very small:
# SELECT levenshtein('project manager', 'product manager');
levenshtein
-------------
2
(1 row)
The functional difference is extremely large:
The BC government has a project management office and in some respects it shows: big projects like ICM, MyEdBC and the iHealth systems have been delivered within their (very long) schedules and (incredibly huge) budget envelopes (plus or minus a bit).
On the other hand the projects above have also been catastrophically bad for users, rolling out with big performance failures and lots of of user push-back. In the case of the Nanaimo iHealth project, doctors have actually been suspended for refusing to use the system. Now there’s a system that needs some user acceptance testing!
The “product manager” role is one that’s very common in the private sector IT world, certainly at the big Silicon valley firms and the last two start-ups I’ve worked with. It’s not one I’ve seen much in the government space, with the exception of “digital transformation” carve-outs like GDS or USDS.
Delivering junk on time and on budget isn’t success, and neither is delivering a great system 2 years late and 100% over budget. Some kind of co-equal arrangement seems like a good idea:
Product and project managers see the same work through different lenses. And that’s a good thing when you are trying to achieve something special like bringing a new product to market as I was. But they both work for the same team. And when they join forces to collaborate, everyone benefits and the company wins.
- Ron Yang