Cloudinary is an API-first image and video manipulation service. It takes images and videos and resizes or crops them, for portrait or landscape say, or makes AI-based edits. While not perhaps as well known a name as an API-driven business as Stripe or Twilio, it has built a successful business at scale by appealing to developers. The customer list is shiny – enterprise companies like Puma, FC Bayern Munich, Guess, Levi’s, Paul Smith, Puma and Rapha. But it also has more than 10,000 self-service developer customers.

Cloudinary took 9 years to reach 1M developers, another 3 years to double that, and now plans to reach 5M active developers within the next few years. Given there are – by most estimates – fewer than 30M developers in the world that’s a big target. But with a global strategy, and global growth in developer populations, not unreasonable.

I recently talked to Sanjay Sarathy, who runs both developer engagement and product led growth at Cloudinary, and one of the aspects of the company’s community building strategy that struck me was that it relies primarily on video – in particular on YouTube tutorials – to drive devs to its properties.

Before settling on YouTube as a primary target it set out a model to measure the value of all developer interactions. Dev Rel worked with the finance department, considering the lifetime value of a registration, with the understanding that while the majority of users wouldn’t become paying customers, that didn’t mean they weren’t valuable. From there Cloudinary built a model attributing a particular value to all activities that involved developer touch – articles, events, blog posts, YouTube, etc, in order to map out a lifetime value of a registration. It quickly became apparent that YouTube was delivering the most engaged traffic. In a Cloudinary survey this summer YouTube came out a clear winner in terms of how people had first heard of the company.

And now it’s driving 45,000 new registrations per month.

Cloudinary was founded by three developers, and so their ethos was, how, how can we build a company that focused on people like ourselves? How would we want to engage with a company like Cloudinary? And so the focus was very much around creating content, creating code, creating samples that would allow developers to understand the power of our image and video platform, and we did this in the early days through a variety of channels. We had our own blog channel on our website. We participated in hackathons, we spoke at conferences. They’re all the usual, nothing hugely surprising, but I think one of the things that we’ve noticed over the years is sort of the secular trend towards YouTube as an incredible search engine in and of itself, and I think how developers like to learn by finding other developers who are building in public and showing how you can build in very specific ecosystems that map to their interests, and we started to get inbound interest from people that said, yeah, it would be great if you could show us how to do XYZ, and it wasn’t one of those things where they were going to come to our site and read a blog post. They wanted something that was a little more interactive and a little more engaging, so they could see the code being built in real-time.

A couple of strategy points are worth calling out.

Firstly, while the original intention was to create short two to three minute tutorials, it turns out that longer videos, some even lasting two or three hours, were also popular. This is counter-intuitive, do people really watch three hour videos? But of course people will watch Twitch streamers coding for hours, if they’re engaging and building something interesting. So the idea that shorter is always better isn’t always the case with in-depth tutorials.Also – video can of course be asynchronous.

What we what we learned is that if the conversation is around how to do X, and it’s in steps, and you don’t have to do everything at once, and you can come back and you show the code in real time, and you give people access to the GitHub repo, so even if they don’t watch the full video, They can clone it and start working playing on their own, and come back to see the steps… that can be quite engaging.”

Secondly, Cloudinary quickly realised that it wasn’t going to be able to do everything in house. Certainly not with the required technical depth, given the range of languages and frameworks it wanted to support. So while it has some excellent inhouse video creators it also works with third party developers on sponsored video tutorials, to create interesting, on point content for developers in specific ecosystems. JavaScript is of course the key front end language, but more specifically frameworks such as Next, Nuxt, Vue, and React. Python is the main back end target, on the server side, although Java and C# are also targets.

A good example of third party sponsored content is Paul Charlton of WPTuts demonstrating how to use Cloudinary with WordPress.

The company has a free tier and self-service subscriptions, but also does direct enterprise sales. A significant percentage of them originally signed up for self-service subs.

Finally a note on going global. At the most of Cloudinary’s sponsored content is in English, but that’s going to change. There are huge developer populations in India, Brazil, China, and so on, which is going to mean local language support, for example in Hindi, which is just coming onstream.

If you’d like to know more about Cloudinary and how its building its business you should check out this video I recorded with Sanjay. There are a lot of useful nuggets in there.

Cloudinary, Stripe and Twilio are not RedMonk clients. This RedMonk video and blog post were not sponsored.

We’ve also had a long era of sprawl, where developers and organisations and engineering teams have had a lot of autonomy in the decisions they make, which has enabled productivity in some dimensions, but also major challenges in terms of complexity and lack of standardisation in databases, runtimes, monitoring tools, programming languages and so on. The cognitive overheads have become far harder to manage, for individuals, teams and organisations. Managing and monitoring these applications and services with all this complexity happening in multiple dimensions has required a new set of disciplines and tools, which we now generally call Observability. Although apparently, the definition is still in play – Observability 2.0 anyone?

One of the most critical aspects of the Observability revolution is the understanding that people managing the applications are often the people building them. Observability is a developer experience revolution as much as anything else. The last generation of monitoring, tracing and logging tools are no longer cutting it in terms of providing context, useful querying, meeting the user where they are. Observability is now something that happens across the entire software development lifecycle. With apologies to Robert M. Pirsig, author of Zen and The Art of Motorcycle Maintenance:

Observability is not something that can be added to applications and systems like tinsel on a Christmas tree. Real Observability must be the source of the applications and systems, the cone from which the tree must start.

Observability then must be a Day Zero concern.

We’re now seeing organisations seek to establish standard platforms, with platform engineering teams tasked with reducing some of the cognitive loads on developers and some of the organizational burdens on engineering teams. They’re also tasked with choosing Observability platforms as part of their efforts to build guardrails, controls and governance into their systems, but ones that developers aren’t going to hate. Into this market context come both new, and legacy vendors remaking themselves for all these new realities. One such is Dynatrace.

I recently discussed these issues with Adrian Phillips and Angela Kelly of Dynatrace to get their perspective on what’s needed for effective observability in this RedMonk Conversation.

Dynatrace is a client, and sponsored the video.

In the era of the open source rug pull, the role of open source foundations is more important than ever. The “rug pull” here refers to companies that have used open source as a distribution mechanism, building a community and user base, before changing the license to be restricted, rather than truly open source. “This is capitalism, yo. We’ve got shareholders to satisfy. It’s time to relicense that software, move to a Business Source license.”.

Why does open source even matter? My colleague has covered this question in some depth here.

The answer is that instead of the embarrassment of riches of open source projects we have today that developers may take up and use for whatever they choose without reference or restriction, we’d have a world dominated by projects carrying varying, conflicting usage restrictions that would render the licenses incompatible with one another and not usable by some.

Where open source used to be a sustainable commitment, today too often it feels like a short term tactic. Commercial open source isn’t what it used to be. Which means that open source foundations, which provide ongoing governance and intellectual property management for open source projects, are in an interesting position, in some cases becoming more adversarial than they historically have been with vendors.

The Linux Foundation (LF) and Cloud Native Computing Foundation (CNCF) are predicated on trust. Linux is of course one the most important pieces of infrastructure in tech history, so it’s no surprise the LF plays a key industry role as its steward, but latterly container-based infrastructure has taken a similarly important role, thus emphasizing the importance of the CNCF. Meanwhile the Apache Software Foundation (ASF) has done a great job of fostering sustainable, commercial, open source for decades now, most notably in the data infrastructure space – think Hadoop, Spark, Kafka, Flink etc.

One premise behind the CNCF is that user organisations can within reason trust it to stand behind the projects it incubates and manages. While not an explicit commitment, adopters generally, and enterprises specifically, have seen the CNCF imprimatur as one that they can rely on. In the era of the open source rug pull this kind of promise becomes even more important.

In this post we’ll look at some projects to get a lie of the land for the foundation in 2024 – Flux CD, OpenTofu (a fork of Terraform) and Valkey (a fork of Redis). One thing is clear – the LF and CNCF are taking a somewhat more interventionist approach than in the past. The CNCF was born in the era of the zero interest rate phenomenon (ZIRP), and it seems like we’re finding out how it, and other foundations, functions in the new era, where money is harder to come by. So what protections are available to adopters?

Sid Sijbrandij, CEO of GitLab has argued that open source companies should commit to an Open Charter as a mechanism to protect users from open source rug pulls.

Open source software isn’t useful if people can’t rely on the project remaining open source. Adopting Open Charter offers open source users predictability amidst the growing licensing switch trend.

With a CNCF project, though, the need for this kind of charter becomes less important, because the code is by design not single source, but has a diverse set of contributors. Which is to say that open source foundations can make rug pulls a lot less likely than adoption of open source technology built by a single company. Relying on benevolent dictators is generally pretty risky. And recently the benevolent dictators have seemed… less benevolent.

In theory then foundations play a critical role in trusted open source infrastructure. And yet they are far from universally appreciated.

Every once in a while someone writes a piece that complains that such and such foundation isn’t working the way they think it should. The piece gets picked up on Hacker News, goes viral, and everyone jumps in with their own complaints and opinions. A classic of the genre was a post from a few years back, now deleted, by Mikael Rogers – Apache Software Considered Harmful (now deleted) – in which he complained about the ASF and its hesitance in adopting Git, at the time a new way of working with source code.

Over the years the Linux Foundation, the Apache Software Foundation and the Eclipse Foundation have all received their fair share of brickbats. Depending on who you speak to these organisations are either too commercial, or not commercial enough. Too consensus oriented, or too top down. Too opinionated, or not enough. Or both. Captured by major vendors, and not responsive enough to community needs. But here is the thing – commercial open source would almost certainly never have achieved critical mass and continued success without foundations in the mix. The ASF was founded in 1999, and underpinned the adoption of open source middleware in the enterprise.

The LF is a non-profit organisation, which is not to say it’s uncommercial. It runs profitable conferences, including Kubecon. It sells corporate sponsorships to vendors and enterprise organisations to fund its operations. It also runs certification programs.

The CNCF acts as a subsidiary of the LF. It hosts projects including Kubernetes, Open Telemetry, Prometheus, Backstage, Envoy, and ContainerD. It also encourages end users to contribute to these projects. It also offers certification through the Certified Kubernetes Administrator (CKA) exam, a 2 hour online exam costing $395.

Open source foundations provide governance but they don’t provide direct revenue models for vendor contributions – which can be frustrating for commercial companies operating in their ecosystems.

On the “not being commercial enough” side of the ledger, earlier this year the CNCF said it would need to reassess Linkerd as a graduated project, when Buoyant, the commercial company behind it, announced it would now charge for stable releases.

There is a paradox here that mirrors that of open source. While open source is a phenomenal distribution and community model, it is not in itself a business model. While open source foundations are a fantastic way to encourage the growth of a community around a project, they do not in themselves drive revenue to the commercial companies building those projects.

The ASF, while also a non-profit, is somewhat less commercial in terms of its culture and operations. The Eclipse Foundation, now based in Brussels, is also a non-profit organisation and functions somewhat more like a traditional standards body. The Eclipse Foundation, now based in Brussels, is also a non-profit organisation and has leaned into a role where standardisation is all important – such as automotive, supply chain security, and regulatory compliance. The organisation has perfected the art of standardisation through implementation rather than just specification.

A new entrant on the foundation scene is Commonhaus, founded with the idea it could offer fewer restrictions than other foundations – claiming “minimum viable governance”:

Adhering to a “community-first” model, we offer support that respects project autonomy, ensuring governance is effective without being restrictive.

It has attracted some widely used projects such as Hibernate and the up and coming OpenRewrite.

But now let’s move on to those case studies for how governance and IP management can be helpful.

Sustaining Flux CD

A few weeks before Kubecon Europe 2024 in Paris a company called Weaveworks unfortunately went out of business. Weaveworks was a leading Kubernetes contributor, and it was also the commercial company behind the widely adopted Flux CD project. At Kubecon North America 2023 it had won an award for making an outsize contribution to CNCF projects relative to its size.

Flux CD is a deployment tool, designed to work with Kubernetes, used in production at big banks, telcos, and a number of cloud companies. So what would happen to Flux when Weaveworks shut down?

Sustainability doesn’t happen without a lot of hard work. Weaveworks CEO Alexis Richardson immediately began hustling and making calls, talking to the CNCF and other companies using the software about what would happen next. The ecosystem rallied round. A number of companies stepped up to announce ongoing support for Flux including Aenix, Aviator, Microsoft Azure, Cisco, Edgecell, Fairwinds, Giant Swarm, Gimlet, GitLab, Nearform, Opsmx, Opsworks, OSO, Teracloud, and TNG. With names like Cisco, GitLab and Microsoft in the mix the future of the project looks reasonably solid. A UK services company called Controlplane hired one maintainer, Stefan Prodan, with a view to providing enterprise support for Flux.

The CNCF was a vehicle for Richardson’s hustle. It stepped quickly into the breach, and arguably for the first time really proved its longtime value proposition of project sustainability. When interest rates are zero, and VC money is cheap, it’s pretty easy for everybody to feel comfortable and confident that everything will get funded. In the current environment, where VCs are tightening their belts, everything is a lot harder. The CNCF in this case was able to show that Cloud Native software wasn’t a zero interest rate phenomenon. There’s still plenty of work to be done but the most important thing is that Flux got a soft landing.

Helpful yes, but Richardson would have definitely preferred the CNCF to be active in helping Weaveworks actually sell the product as part of its charter. This is what he had to say about the Linkerd situation in February, and the same would apply to Flux.

People and companies work on projects for economic and intrinsic motivations.

eg Economics of CNCF needs to be justified to vendors.

Intrinsic motivations include belief that the project will flourish and be sustainable, popular, cool.

End users often are a mix of both. They will need support over time (in 3-10 year horizon) and in short term want to mitigate new tech risk

CNCF needs to take this a lot more seriously or it will be the home of poorly staffed second tier projects.

TOC+GB+EUC needs to engage at the level of product, marketing and long term business support, or find people who can.

The Relicensing Era

Of course there are going to be some issues around open source that are contentious in this post zero interest rate era. There is a lot more friction, in and around open source, as companies have been pressured by investors, shareholders, and so on to deliver greater returns. An increasing number of companies have therefore relicensed in favour of restricted licenses that are no longer open source, notably in the data management space. Company executives and investors have felt that returns needed to increase, and that open source was preventing this increase. They have also been driven by the idea that cloud companies – notably AWS – are taking advantage of the open source contributions of these companies to build businesses without needing to invest accordingly.

RedMonk has a clear position here – we don’t believe it’s necessary in order to build successful businesses. My colleague Rachel Stephens recently examined Software Licensing Changes and Their Impact on Financial Outcomes, by considering the cases of MongoDB, Elastic, Confluent and Hashicorp. We don’t see a clear relationship between license changes and revenue growth or share price increase, or, to be fair, decrease for that matter.

Any company is within its rights to relicense its software, but it can certainly be problematic from a community and project health perspective. Which is exactly why open source foundations are more important than ever.

Redis and The Post-Valkey World

On March 20th 2024 Redis announced it was moving to a source available model

Future Redis releases will continue to offer free and permissive use of the source code under dual RSALv2 and SSPLv1 licenses; these releases will combine advanced data types and processing engines previously only available in Redis Stack.

Beginning today, all future versions of Redis will be released with source-available licenses. Starting with Redis 7.4, Redis will be dual-licensed under the Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1). Consequently, Redis will no longer be distributed under the three-clause Berkeley Software Distribution (BSD).

What was surprising in this case was the rapidity of the community response – by March 28th the Linux Foundation had announced Valkey, an “open source alternative” to Redis, which would allow for continued use and distribution under the Berkeley Software Distribution (BSD) 3-clause license. The announcement came with support from Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc, which all committed to making contributions to the new project.

Getting AWS, Google and Oracle lawyers to commit to fork of Redis is under a week? That is… impressive.

One could argue that AWS would of course commit to a fork – after all, one of the main rationales behind Redis Labs decision to relicense was the complaint that AWS was gaining too much advantage from the code it was writing. But it’s important to also note the community aspects here. Madelyn Olson, an AWS employee and long time Redis committer led the community charge.

“I worked on open source Redis for six years, including four years as one of the core team members that drove Redis open source until 7.2. I care deeply about open source software, and want to keep contributing. By forming Valkey, contributors can pick up where we left off and continue to contribute to a vibrant open source community,” said Madelyn Olson, former Redis maintainer, co-creator of Valkey, and a principal engineer at AWS.

It was notable that Salvatore Sanfilippo, the original creator of the Redis project, said on Hacker News, that freedom to fork was why he’d chosen to use a permissive license for the project.

When I chose BSD for Redis, I did it exactly for these reasons. Before Redis, I mostly used the GPL license. Then my beliefs about licensing changed, so I picked the BSD, since it’s an “open field” license, everything can happen. One of the things I absolutely wanted, when I started Redis, was: to avoid that I needed some piece of paper from every contributor to give me the copyright and, at the same time, the ability, if needed, to take my fork for my products, create a commercial Redis PRO, or alike. At the same time the BSD allows for many branches to compete, with different licensing and development ideas.

When authors pick a license, it’s a serious act. It’s not a joke like hey I pick BSD but mind you, I don’t really want you to follow the terms! Make sure to don’t fork or change license. LOL. A couple of years ago somebody forked Redis and then sold it during some kind of acquisition. The license makes it possible, and nobody complained. Now Redis Inc. changes license, and other parties fork the code to develop it in a different context. Both things are OK with the license, so both things can be done.

The concerns of a business and a project founder may diverge over time. Redis is perfectly within its rights to move forward and close the license. But others are within their rights to fork it

So that’s a chunk of the community, big vendors, and the LF all in alignment – which adds up to a significant challenge for Redis. The vendor is putting its best foot forward by shipping new functionality, in critical areas such as graph database and vectors for AI, and most enterprise customers are fairly sanguine about the relicensing. But for community members and indie developers there is a feeling a social compact has been broken. Valkey therefore feels like a landmark for the Linux Foundation but also the industry as a whole. Relicensing doesn’t look nearly as attractive or indeed, worry free, as it did just a couple of months ago. Vendors are going to have to give such moves a bit more thought – the idea that relicensing concerns will simply blow over isn’t quite so clear. My colleague Stephen calls this the Post-Valkey World.

Valkey represents – whatever the project’s ultimate fate might be – the first real, major pushback from a market standpoint against the prevailing relicensing trend.

To be clear, no one should get carried away and expect Valkeys to begin popping up everywhere. It’s important to note that there are many variables that impact the friction involved in forking a project and the viability of sustaining it long term. Some projects are easier to fork than others, unquestionably, and Redis – if only because it was a project with many external contributors – was lower friction than some.

Not every project that is re-licensed can or will be forked. But investors, boards and leadership that are pushing for re-licensing as a core strategy will, moving forward, have to seriously consider the possibility of a fork as a potentially more meaningful cost. Where would be re-licensors previously expected no major project consequences from their actions, the prospect of a Valkey-like response is a new consideration.

So what about Terraform?

A bowl of Open Tofu

Terraform, the widely adopted automation engine from HashiCorp, was also relicensed in 2023 and a number of vendors, including systems integrators and cloud companies, were unhappy about the situation. The Open Tofu fork didn’t get the kind of immediate traction that Valkey did though. Contributors are mostly smaller companies – including Gruntwork, Spacelift, Harness, Env0, Scalr. Without a hyperscaler on board it’s harder to see the fork achieving true breakout status, although it continues to make progress, for example recently launching a registry of providers, modules and resources.

HashiCorp is still in the process of being acquired by IBM so we’ll see what happens going forwards. A rapprochement between Hashicorp and Open Tofu may yet be possible, although it seems unlikely.

But again, from the perspective of companies being able to be fairly confident that the bets they’re making are sustainable, a foundation’s support is a very good hedge. Companies relicensing usually claim they need to do so for sustainability reasons, so that they can keep investing in a product – providing all the good stuff like bug fixes, security patches, documentation and new features. But open source offers its own sustainability value, which is amplified with a well funded foundation in the mix. Foundations aren’t perfect – some of the complaints about them of course contain some truth. But it’s hard to see a model where they could effectively act as a reseller of specific projects and companies. That’s not the value they provide. Open source is a model proven over decades and foundations have been a big part of it.

A final point worth considering in terms of the value of foundations is project diversity. The CNCF has done a frankly stellar job of improving and sustaining diversity in the Kubernetes ecosystem – for example with dedicated programs to bring in new committers and contributors from a diverse set of backgrounds. The Kubernetes ecosystem is constantly being refreshed with new faces from diverse backgrounds, one of the biggest challenges of any open source project.

A word of caution about sustainability – while the CNCF has some huge backers with very deep pockets – Google, AWS, Microsoft and so on, it also needs a healthy ecosystem of smaller companies around it. It can’t just be a playground for trillion dollar companies. Many of the companies with those expensive booths at Kubecon are currently struggling to raise new funding rounds in a tough economic climate. VCs only want to invest in AI right now, and new funding rounds for cloud native infrastructure are a lot harder to come by. Vendors need to be able to illustrate better fundamentals.

But on balance yes – Open source foundations considered helpful.

Disclosure: Amazon Web Services, IBM, Elastic, Hashicorp, GitLab, Google, Microsoft, MongoDB, Oracle, Redis Labs are clients. While Weaveworks was not a client at the time of its shuttering, Richardson is a good friend of mine, which is worth disclosing.

It’s always difficult, if not impossible, to sum up a conference that you’ve recently run. But it’s important to write the post, because there are some important jobs to be done – most notably thanking a bunch of people.

The main thing I want to say is that it was really, really, good to be back in 2024. Monki Gras is a labour of love, but the hard work is always worth it. The event is unique in the community we sustain, and the approach we take to things. It feels important – being an expression of so many of the things Redmonk holds dear – most notably inclusion, kindness, and great story-telling. Like its sister conference Monktoberfest, at Monki Gras we want people to feel inspired, and, hopefully, to remember just why it is that they do what they do. We’re not about the hustle, the hockey stick, and the PLG, but rather the craft, the learning, and the teaching. We’re about highlighting the positive social aspects of this industry we’re so privileged to work in.

With all that in mind it might seem counterintuitive that I should have made prompt engineering and generative AI as my theme this year – Prompting Craft. After all, while AI is exciting in the possibilities it opens up, it’s also a little scary. A lot of the intellectual property used to train large language models (LLMs) has been used without any consideration of copyright. What is more, many creatives, including software developers, feel threatened by the rise of the machines. I definitely don’t want to minimise people’s fears or concerns. It’s going be very very uncomfortable. But it feels like the wave will break whether we like it or not. Also Chat-GPT is really really bad at generating vector graphics.

One answer to the tension about AI fears came from one of my speakers at the event – Dr. Cat Hicks, founder of the Developer Success Lab. In its research into the factors driving developer productivity, personal, and organisational enablement the Lab examined AI as a potential threat to people. The research found that the organisations and individuals most threatened by AI had an adversarial culture – a culture of “brilliance”, where individuals constantly feel they have to prove themselves, where coding is competition. Organisations that are ready to embrace the possibilities of generative AI on the other hand, have already fostered a culture of collaboration and shared learning, mutual support and teamwork. For these organisations AI is just another way to work effectively together.

I don’t plan to summarise all of the talks here but did want to mention Cat’s talk because of the reasons outlined above. The talk was very human, and yet it was about AI.

The human machine interface was a meta theme of the conference – prompting is just another user interface, and it’s inherently social. We prompt each other to get what we want and need. We prompt our children. We prompt our friends and colleagues. We have to build trust with LLMs before we are comfortable making more use of them. We can trick machines, just as they can trick us – security specialists are not going to be out of a job any time soon…

So about those thank yous.

Firstly a shout to our speakers on day one – Richmond Alake, Alex Chan, Patrick Debois, Cat Hicks, Zack Akil, Mathis Lucka, Luke Marsden, Farrah Campbell & Brooke Jamieson, Rafe Colburn, Afsha Hossain and Matt Webb.

Day two was also excellent – thanks to Dormain Drewitz & Rachel Stephens, Ian Miell, Julia Ferraioli, Jim Boulton, Kristen Foster-Marks, Paul Molin, Jessica West, Kyle Roche, Emil Eifrem and Paige Bailey.

So much respect to attendees went into the prep and hard work by these speakers.

While I may not have summarised the days’ talks, my colleague Rachel Stephens did a bang up job doing exactly that. Here are writeups of day one and day two.

Our Monki Gras sponsors were also critical in making the event a success. My humble thanks to AWS, Civo, Deepset, CNCF, Neo4j, MongoDB, Akamai, Griptape, PagerDuty, Screenly and Betty Junod for supporting us. A special thanks to Mark Boost, CEO of Civo, for all his sterling efforts helping out with our venue – Civo Tech Junction, a new space hosting free meetups and events in Shoreditch.

Last, and certainly not least, I need to thank the Monki Gras team – namely Jessica West, Dan McGeady, and Rob Lowe. I couldn’t have done it without their sterling efforts.

Other great write-ups include these by Sinead Doyle and François Hoehl and Simon Haslam.

I will sign off with a quote from Patrick Debois which made me very happy.

“I have not felt this energised after a conference in at least years. I’ll be back Monki Gras next time for sure!”

This week it’s The State of Open Conference 2024 at The Brewery, London. It was great last year. I heartily recommend you attend. As I said on twitter at the time:

The UK now has its own OSCON. the event will happen again and will go from strength to strength.

Attendees and speakers were a who’s who of open source, open hardware and open culture people generally. The open data track was particularly lively. There were so many of my friends there, it really felt like my people had all congregated in London for the day. The event also felt very inclusive, in terms of both speakers, but also attendees. It reflected London’s rich diversity.

The speaker list is extremely impressive again this year.

But the real reason I think SOOCon24 is so important is the focus on policy, governance and open source sustainability. Open source is under a great deal of pressure right now. VCs are encouraging their portfolio companies to adopt “business source” licenses, which are not actually open source. Why does this matter? As my colleague Stephen O’Grady argues:

A world in which non-compete licensing grows at the expense of open source is problematic enough. A world in which vendors blur the definition of open source such that regular users can no longer differentiate between the two is much, much worse.

Pedantic as it may seem, then, the question of whether something is actually open source really does matter, as those who would redefine the term will find out if they get their way.

This movement has also bled into the current AI explosion. What is “Open” AI? That’s something we need to work out – and major market players are casually calling things open source, which frankly aren’t. Another area of governance and policy under scrutiny is regulation of AI – we can’t just leave this as the era of “You Only Live Once.” Controls will be necessary, and governments are scrambling to put them in place. At SOOCon24 the organisation behind the conference Open UK will be capturing opinions and data to feed back the UK government about regulation going forward. I believe we’re going to see AI Bill of Materials requirements regulated at national level.

It’s a pivotal time, and these discussions are vitally important – that’s why they need a home. We’re literally talking about the economic foundations of the digital economy, the means of production which have served us pretty well these past couple of decades, and the opportunities for making and learning which have made tech such a transformative success. Authors and creators need stable foundations to work on. Copyright and licensing matters. Back to Stephen:

Instead of the embarrassment of riches of open source projects we have today that developers may take up and use for whatever they choose without reference or restriction, we’d have a world dominated by projects carrying varying, conflicting usage restrictions that would render the licenses incompatible with one another and not usable by some.

I am glad Amanda Brock and team are pulling this event together, for all of the reasons outlined above, and I look forward to seeing you there. I believe there are a few tickets available.

If you’re interested in AI and prompt engineering, and all of the craft, sustainability and social angles, you should also check out my conference Monki Gras 2024: Prompting Craft. March 14th and 15th, Shoreditch London. Tix here.

RedMonk beers are going to be a blast at Kubecon this year. We’ve found just the place, which reflects what we’re all about. The venue is called Maria’s Packaged Goods and Community Bar – described as a “Hybrid liquor store & neighborhood tavern supplying a large rotating menu of rare craft beers.” It has plenty of outdoor space.

Rare craft beers, community and outdoor seating? Definitely on brand. Definitely our vibe.

One reason our team was excited when the CNCF announced Kubecon would be in Chicago this year is that Morgan Harris, our account and engagement manager, lives in the city. So it felt like we could mix Cloud Native and Chicago Native. Naturally we asked Morgan to scout a venue for us, and of course she came up trumps.

The story behind the venue is lovely.

Maria is a South Korean, who moved to Chicago after marrying her husband, an American serviceman called James back in the 1970s. Sadly he passed away at a young age. Maria though found her feet in a tough neighborhood and community in Bridgeport, Chicago. Today she is a local icon – and has a beer in her name – The Duchess of Bridgeport – a sour red ale we can’t wait to try. Locals call her “mom” or the Peggy Guggenheim of Bridgeport because of the way she supports local artists. If you’d like to know more about this history of the place this is a great article to check out.

The food is Korean Polish, which sounds amazing (think Polish Sausage, Pierogis and Korean chicken wings), with some nods to Italian. We look forward to hosting our own community in this community institution. Join us at Maria’s Community Bar on Wednesday, November 8th. Don’t forget your ID, because Maria herself may be checking them at the door.

We’ve booked a few tables and look forward to seeing old friends there and meeting some new ones.

Date: November 8

Time: 7:30-9:30pm CT

Location: Maria’s Packaged Goods & Community Bar; 960 W 31st St
Chicago IL 60608

Bonus post material – be sure to read this great thread about Chicago before you travel.

So you're looking to attend #KubeCon in Chicago? Welcome! Chicago is an incredible city and I hope you have a blast while here. I've put some thoughts together here for anyone coming to the city for the conference. I've only lived here for just over a year but really like it. 1/

— Kai @kaipmdh@hachyderm.io (@KaiPMDH) October 28, 2023

Jan Claeyssens, DevSecOps Principal Engineer at Dunelm, explained that his role is to enable and engage with developers and engineering teams:

The development teams are my customers. Security needs to stop saying no but lean in, listen to what they want and try and help them. No one wants more checks after they have finished. Security scanners should not impact the APIs too much.

Claeyssens also pointed out how important education is. You can’t expect developers to use security features if they don’t know they’re there. Platform engineering and security teams need to do a better job of developer education in order to get the results they want. The whole tone from Claeyssens was refreshing from a security perspective.

Serve the user where they live and show them what the features are. Security at Dunelm has to help the business become better.

Amen Jan.

Talking of amen, I was really pleased to hear the company has adopted Progressive Delivery as an approach. Given I coined the term, it was great to hear concepts read out from an enterprise company. To be fair GitLab has used Progressive Delivery in its marketing so it should not surprise me that a customer would be using the language. But it was still pleasing.

Paul Kerrison, Director of Engineering and Architecture at Dunelm said:

Our engineering work is becoming more experiment driven, we are moving towards progressive delivery, the new kid on the block.”

You get to try more risky things but safely. We can put something in production, test it with one one cohort, then roll it out more broadly.

Cohorts, phased rollouts, reduced risk with more experimentation, testing in production. This is the way.

disclosure: GitLab is a client.

What’s in the black box? As we go forward we will need a model and machine readable bill of materials.

It’s becoming increasingly clear that we’re going to need an AI bill of Materials (AIBOM). Just as with a Software Bill of Materials (SBOM), there are a set of potentially important questions when we take advantage of an AI model, which we’re just not set up to meaningfully answer at the moment. The You Only Live Once (YOLO) approach that OpenAI took when launching ChatGPT is not going to provide end users with the confidence they need to adopt AI models in strategic initiatives. Sure we’ll see shadow AI adoption (like shadow IT adoption, but for AI tools), by marketing departments and sales and so on. The lines of business won’t allow governance to get in the way of productivity. But as ever bottom up needs to meet top down, which is where governance comes in. From an enterprise perspective we will need to get a much better understanding of the models we’re using, and what went into them. Which is to say, a bill of materials. Trust and safety are not the enemy. We need to better understand the AI supply chain.

The AIBOM will need to consider and clarify transparency, reproducibility, accountability and Ethical AI considerations. After introducing the idea of an AIBOM to Jase Bell he began to work on a schema, which you can find on GitHub here. It’s a useful starting point for discussion so please check it out.

Transparency: Providing clarity on the tools, hardware, data sources, and methodologies used in the development of AI systems.

Reproducibility: Offering enough information for researchers and developers to reproduce the models and results.

Accountability: Ensuring creators and users of AI systems are aware of their origins, components, and performance metrics.

Ethical and Responsible AI: Encouraging the documentation of training data sources, including any synthetic data used, to ensure there’s knowledge about potential biases, limitations, or ethical considerations.

Weighting, and decisions behind it, become ever more important. Also – origins are not the only important issue. Sometimes the intended use case is where the higher duty of care is required. We may want to read the ingredients on a cereal box, but it’s not a matter of life or death. Taking medicine on the other hand, you definitely want to know exactly what the ingredients are. So what are we predicting or generating? The EU regulatory framework for AI discussed below establishes a hierarchy of low or high risk AI use cases. We’ll see more of that.

One part of the industry already groping towards the need for an AIBOM as a business critical issue is commercial open source.There was an interesting post recently by Matt Asay about AI and open source licensing a few days ago – Making sure open source doesn’t fail AI. The argument is that open source licensing had failed in the age of the cloud, and we needed to avoid making the same mistakes. What jumped out at me however was a quote from Stefano Maffulli, executive director of the Open Source Initiative (OSI), which certifies what is, and what is not, open source from a licensing perspective. He said you’d need

“A very detailed description of what went into creating the artifact.”

As Asay writes

“In this world, you’d need to publish all the scripts that went into assembling the data set, the weights that govern the LLM, the biases you bring to the model, etc. This, in my view, is a much more interesting and useful way to think about open source AI, but it’s also far more complicated to deliver in practice.”

Complicated? Absolutely. But increasingly important.

In a really smart tweet Jordan Hamel makes the case that OpenAI is the Napster of the LLM revolution.

OpenAI in some ways is the Napster of AI who learned from its mistakes by getting MSFT on board since they’ve traveled through the legal journey of the underworld and back and have the $$$ to make it legal. A machine learning model that can generate copyright derivative material in a variety of modalities does conflict with existing copyright law and one way or another it’s going to come to a breaking point. Imagine DMCA for your generated content? Napster blew people’s minds in the 90’s for good reason and it took well over a decade for the legal products to exceed its quality and content distribution.

This is spot on. We’ve been shown something incredible, and we want to use it, obviously. The great softening up has begun. And we need an AIBOM from a business perspective. Why? The answer is, as ever, found in governance, risk, and compliance.

Large Language Models (LLMs) could take a wrecking ball to regulated industries. Any regulation that concerns itself with user privacy, for example, is not going to survive first contact with LLMs. The HL7 patient data interoperability standard wasn’t designed with the cloud in mind, let alone AI. Or think about HIPAA, or GDPR even. So enterprises are justifiably concerned about feeding LLMs with user data. In areas such as manufacturing, engineering or polluting industries regulations abhor a black box, but that’s exactly what LLMs are. Copyright infringement is another potential concern – the first class action lawsuits have been lodged by authors against OpenAI.Then of course there is the fear that using public LLMs might lead to security breaches and leakage of trade secrets. Data residency continues to be a thing, and public LLMs are not set up to support that either – if German data needs to be held in a German data center how does that chime with a model running in a US Cloud. And how about prompt injection as an emerging vector for security threats?

So far tech vendors have been remarkably relaxed about these fears, while enterprises have been somewhat less confident. Google and Microsoft have promised to indemnify users if they are challenged on copyright grounds, for example. Their highly paid corporate lawyers are evidently pretty confident that a fair use argument will prevail in court, for outputs from AI models. As ever this is a question about tolerance for risk.

And sometimes the promises about trust don’t stand up to scrutiny. Thus for example Adobe said it’s Firefly image generation model was “commercially safe” because artists had signed up for it – this was [apparently a surprise to some content creators. Adobe, however, has continued pushing its trust credentials with the introduction of a “made by” symbol for digital images, establishing provenance, including, for example, if it was made with AI tools.

The EU is moving towards some far-reaching (some might argue over-reaching) requirements around model-training with its coming EU AI Act

Some notable statements in the positioning document. Considerations of “high risk” (All high-risk AI systems will be assessed before being put on the market and also throughout their lifecycle.)

include:

AI systems that are used in products falling under the EU’s product safety legislation. This includes toys, aviation, cars, medical devices and lifts (elevators).

Meanwhile, here is the copyright kicker.

Publishing summaries of copyrighted data used for training

Perhaps we can just ignore EU law. A lot of folks consider the GDPR to be more of an annoyance than anything else. Facebook can easily afford to pay its $1.3bn fine – that’s just a cost of doing business, right? The US has replied with sabre rattling that regulation will only serve to entrench the major players.

Some companies might feel confident in ignoring EU law – YOLO – but if they want to do business in China, that’s not really an option that’s open. This thread from Matthew Sheehan is essential reading for anyone interested in AI regulation, or the lack of it. Also this post. The TDLR – China is literally years ahead on AI regulation. In China at least:

The draft standard says if you’re building on top of a foundation model, that model must be registered w/ gov. So no building public-facing genAI applications using unregistered foundation models.

So that’s certainly a potential future. China has an AIBOM-like requirement and policies and procedures and corporate responsibilities that go with it. We’re all going to have to think through this stuff – Norway just announced a Minister for Digitalisation and Governance with Responsibility for Artificial Intelligence, Karianna Tung.

According to Norwegian Prime Minister Jonas Gahr Støre:

Artificial intelligence offers enormous opportunities, but requires knowledge, management and regulation. Because it must still be the people who determine the development of technology, not the technology that controls the people.

Sentiments that I agree with. And regulation – that’s going to need an AIBOM. Major vendors are talking a lot about trust and AI, and jostling for market positioning accordingly – again, this is where an AIBOM is going to come into play.

disclosure : Adobe is a RedMonk client. OpenAI is not.

PostgreSQL isn’t getting any younger. Which is fine – after all, databases generally improve with age. The platform is going from strength, and is a default choice for a big chunk of modern software development. But Postgres has been around for a while – it launched in 1986 – which has an implication for the folks actually building the database. Just how long will they want to do the heavy lifting of maintaining a high profile codebase that so many folks rely on? Postgres is a close knit group and project. Robert Haas, Postgres committer and chief database scientist at EnterpriseDB writes a regular contribution post and the latest numbers are salutary – Who Contributed to PostgreSQL Development in 2022?

I calculate that, in 2022, there were 192 people who were the principal author of at least one PostgreSQL commit. 66% of the new lines of code were contributed by one of 14 people, and 90% of the new lines of code were contributed by one of 40 people.

The core development community is aging somewhat – the average age is probably around 50. Which is totally fine. 50 year olds are more than capable of doing a shitload of work – don’t ask me how I know. Tom Lane, who works at Crunchy Data, is 68 and he’s still the Postgres project’s fulcrum. Long may that continue.

The Postgres community is amazing. Open Postgres governance is something we can and do rely on, which is refreshing in the current era of commercial open source licensing rugpulls. But as an axis to consider in terms of open source sustainability let’s assume that Postgres is still going strong in say, 20 years. Who is going to be doing the work in 2043? I had a fascinating conversation with Nikita Shamgunov, CEO of Neon recently and one of the subjects we discussed was aging in tech projects and its relationship to project sustainability. Neon is a fully managed Postgres database optimised for serverless apps, separating storage from compute – the database is just a URL. That’s the design principle. It allows for branching, with preview deployments – thus Neon’s partnership with Vercel. Make it easy, make it modern, make it a zero config API. Neon has 62 employees and has raised $108m so far. It competes with the likes of Supabase. But back to the subject at hand.

According to Shamgunov:

If you look at the Postgres committer crowd they’re in their 50s, 60s, 40s and maybe a few in their 30s. It takes a lot of effort to become a committer but very little to be a contributor – you just need to write good code.

I think we’re doing good to the world by hiring more junior people and training them to become committers and hopefully maintainers. It’s very important that the Postgres engine continues to evolve.

Neon is being intentional about investing in the next generation of contributors, committers and maintainers. The natural move for a lot of companies is to try and hire the existing top talent, rather than fostering new blood.

We debated whether to just find more Postgres committers and hire them. But it’s not clear that would be spending our money in the best way. If we train new ones it’s better, and that’s how we can keep ramping the Postgres team.

There are some interesting questions here. For example – consider Neon’s IP, which is currently permissively licensed, but Shamgunov is not an open source zealot. What happens if in a few years the company decides to relicense, as other database companies have – see for example Redis, MongoDB and Elastic. Neon would be perfectly within its rights to relicense under more restrictive terms, potential community blowback aside. But any code they had contributed to Postgres? That’s not going to be affected. Having core Postgres maintainers on staff is a pretty good example of enlightened self interest and should serve to keep the company honest. Whatever decisions Neon makes in future, assuming they have employees dedicated to making Postgres better, then the community and core codebase still wins.

Cohort aging is certainly not a problem that’s unique to Postgres. Anyone remember the year 2000 bug? Communities and ecosystems do get older, which can be an issue when it comes to skills and staffing and rejuvenation. IBM has done a great job of bringing younger developers into the mainframe fold, for example with vocational education programs at universities – here is a post I wrote about that a while back.

There are plenty of projects with literally millions of users that are run by one or two people and don’t have the level of corporate sponsorship with see with projects such as Postgres or even Kubernetes. Postgres isn’t in any sense struggling to attract new users – there are plenty of 22 year olds defaulting to it today. It’s a hugely popular platform. But yes, ensuring the ongoing maintenance of the project will require some intentionality, funding, and enlightened self interest.

Disclosure: Neon is not a RedMonk client. Crunchy Data, IBM and Vercel are all RedMonk clients. This piece is published independently of any client relationships.

The illustration above was created with Midjourney.

About deepset

Milos Rusic, Malte Pietsch, and Timo Möller founded deepset in 2018 in Berlin. Inspired by the launch of Google’s seminal natural language (NLP) processing model – Bidirectional Encoder Representations from Transformers (BERT) – the trio trained a BERT model in German, and soon after created an enterprise services company to address semantic search opportunities at European industrial giants such as Airbus, Siemens and BaFIN, the financial regulatory authority for Germany.

As companies needed help and hand-holding in addressing the opportunities of AI, deepset led with consulting, training and solution engineering. The company became a more product-focused concern when it created and open sourced the Haystack Python framework, but now it’s moving to a clearer focus on selling product rather than services with its deepset Cloud platform – in order to take advantage of the cloud/AI flywheel.

Today, while startups and tech giants alike are scrambling to address the large language model (LLM) opportunity, deepset can credibly claim 5 years of experience building tools to address the opportunities of AI-driven natural language processing.

deepset’s vision statement

We help enterprise product teams successfully build and launch NLP-powered applications. There’s still a huge disconnect — when implementing NLP — between the data science and the application development teams, not mentioning the challenges of the enterprise product owners. The NLP product lifecycle often resembles a long-cycle ‘waterfall’ approach, doesn’t align with the modern application development, and is still very far from being an ‘agile’ NLP. We’ve put years of our field expertise and know-how’s into deepset Cloud so that the product teams can define their application architecture, start building, and show results quickly to the business users — minimizing the risks of failure, greatly improving time-to-results, and optimizing the costs of implementation.

Size

• 50 employees
• double digit customers
• $43M raised to date (excluding pre-seed and seed rounds):
• Series A – April 2022: $14M led by GV with Harpoon Ventures, Acequia Capital.
• Series B – August 2023: $30M led by Balderton Capital with participation from GV and Harpoon Ventures
• Initial sales focus in EMEA, now targeting sales in the USA and growing headcount accordingly

Product Information

deepset Cloud is an enterprise-featured SaaS for building custom NLP-powered applications. The managed platform supports enterprise features for search, content summarisation and generation, and Retrieval-Augmented Generation (RAG), a reinforcement learning technique designed to reduce LLM’s AI “hallucinations” – that is, wrong answers confidently stated by an LLM-based system.

RAG is all the rage in the fast-moving LLM world right now, potentially offering the means to reduce the risks of “hallucinations”, one of LLM’s biggest drawbacks. It allows you to blend both generative and retrieval-based approaches. Information retrieval is about fetching information from datasets in order to provide relevant responses, while generative models–such as Generative Pre-trained Transformer (GPT) models–generate text from the model itself – creative perhaps but sometimes deeply wrong. RAG then is likely to be a critically important approach in safer, more trusted AI; deepset is working with customers using RAG to improve the NLP products they’re building. Enterprises want to use their own datasets to augment LLM models.

deepset Cloud also offers the ability to extract named entities or recurring information from unstructured text data, a compelling use case for enterprises with large document corpuses. Aimed at developers creating AI-driven pipelines and applications, the pitch is all about simplicity. The story according to deepset:

You’ll have your first prototype at breakfast, feedback by lunch, and an integrated NLP service before dinner. The deepset Cloud platform solves problems like infrastructure, evaluation, demo UI, and feedback mechanisms so that you can focus on what truly drives your business forward.

deepset Cloud helps customers that want to adopt a multi-model approach rather than relying solely on, say, OpenAI. The platform can be used to compare different models such as GPT-4, Llama-v2 or Claude, allowing enterprises to experiment with different models and compare results.

With deepset Cloud customers can manage access with multi factor authentication and single sign on, with proprietary company data resident in your virtual private cloud (VPC).

Competitive Landscape

The AI market has frankly become hot to the point of absurdity in 2023. Every tech pitch is an LLM pitch. As such it can be hard to be heard among the noise. OpenAI, Hugging Face and LangChain have all gained a great deal of attention, but there is room for enterprise class, trusted LLM plays. As such, deepset sees its primary competition in hyperscale cloud providers such as Amazon Web Services, Google Cloud, and Microsoft Azure.

The enterprise market for LLM technology is itself becoming increasingly crowded, as vendors strive to address concerns about data privacy, the risk of hallucinations, automated bias and so on. Microsoft, for example, offers a combination of Microsoft Azure OpenAI and Azure Cognitive Search to allow customers to “safely” train their own OpenAI models based on their own data. Meanwhile OpenAI in August launched ChatGPT Enterprise, which claims to offer “enterprise-grade security and privacy”. From a customer perspective, however, there is a lot of fear, concern and uncertainty around sharing data or information or text archives with OpenAI.

That’s one reason Microsoft has committed that inputs, outputs, embedding etc, are not available to other customers and are not used to improve OpenAI models, or any Microsoft or 3rd party products or services. Similarly, Salesforce launched what it calls the Einstein GPT Trust Layer to help prevent large-language models (LLMs) from retaining sensitive customer data.

Go to Market

deepset has always worked directly with large enterprise customers. It already has significant experience working with the largest enterprises and public sector organisations to deliver natural language processing apps, and as such is in a decent position to allay concerns about leaks, hallucinations and so on. While deepset offers a cloud platform, it’s happy to work with enterprises that want to host and/or run their own platforms.

Per the list of enterprise features denoted in the “Product Information” section above, deepset Cloud is not just “hosted Haystack.” However, deepset leverages interest in its Haystack open source project to drive product sales, and it’s worth spending some time on the open source framework because it helps to define deepset’s approach, particularly its focus on implementing a development process more akin to agile than waterfall. Haystack is designed for software engineers rather than data scientists. deepset is focusing on allowing developers to “just build”, while taking advantage of AI and LLM technology as it emerges (at a furious rate). deepset’s focus is on allowing customers to build NLP enabled products and applications, with iterative feedback loops. Haystack has more than 10k GitHub stars and 1,400 forks, clearly a healthy project – deepset even claims it for status as a defacto standard. Haystack doesn’t compete directly with Hugging Face, and actually takes advantage of the Hugging Face model hub to enable faster feedback loops.

In terms of vertical industry use cases, deepset is initially focusing on finance, legal, insurance, and public sector. Text extraction and classification are at a premium in these industries.

deepset plans to establish a “pincer movement” of top down and bottom up, selling to business owners it identifies that are empowered to build teams to build AI applications, but also appealing directly to developers as influencers and builders.

Partnerships & Ecosystem:

The complexity and fast moving nature of the space means that deepset is focusing on partnerships, notably channel partners like Atos and Evotek, cloud marketplaces including AWS, and tech GTM partners Doppler and Snyk.

Disclosure: deepset is a RedMonk client, but is an independent piece of research that has not been commissioned by any entity. AWS, GitHub, Google Cloud, Microsoft, and Salesforce are also RedMonk clients.