Camunda Community Podcast

10 years of bpmn.io: “Empowering people to be better at BPMN”

• Camunda Community Podcast • Season 5 • Episode 5

Share episode

On this episode of the Camunda Community Podcast we are celebrating 10 years of bpmn.io–can you believe it?–with host and Senior Developer Advocate Niall Deehan and special guest Nico Rehwaldt, the creator of bpmn.io and principal engineer here at Camunda. 

Today, bpmn.io has a vibrant community of active users and contributors, has gone beyond Business Process Model and Notation (BPMN), and is used throughout almost every front end Camunda product. 

But this was not always the case. 

Join us on this journey from the starting vision, “BPMN everywhere, for everyone,” through inspiring community contributions and scope jumps (Hello Decision Model and Notation [DMN] and forms!), all the way to what the next 10 years might hold. 

Listen to learn more about: 

  • bpmn.io and why it’s a set of libraries instead of an app
  • Why Nico believes Camunda is lucky he was asked to build a solution for drawing BPMN
  • A very brief history of modeling tools
  • Just how extensible bpmn.io really is
  • Fun things the community has built with bpmn.io
  • What the bpmn.io team does
  • BPMN linting
  • Token simulation
  • One of Niall’s proudest moments


Additional Resources: 

---

Visit our website.
Connect with us on LinkedIn, Facebook, Mastodon, Threads, and Bluesky.
Check out our videos on YouTube.
Tweet with us.

---

Camunda enables organizations to orchestrate processes across people, systems, and devices to continuously overcome complexity and increase efficiency. A common visual language enables seamless collaboration between business and IT teams to design, automate, and improve end-to-end processes with the required speed, scale, and resilience to remain competitive. Hundreds of enterprises such as Atlassian, ING, and Vodafone orchestrate business-critical processes with Camunda to accelerate digital transformation.

---

Camunda presents this podcast for informational and entertainment purposes only and does not wish or intend to provide any legal, technical, or any other advice or services to the listeners of this podcast. Please see here for the full disclaimer.

[NICO REHWALDT] Our vision is BPMN everywhere, for everyone.

[NIALL DEEHAN] Hello and welcome to the Camunda Community Podcast, where you’ll learn all sorts of things about Camunda, BPMN, DMN, and, of course, all sorts of general orchestration topics. 

I’m Niall Deehan, senior developer advocate here at Camunda, and I’m host of the podcast.

So Mendelssohn was only 15 years old when he created his first symphony, which is very young, indeed. But not actually even as young as Schubert who was 14. Or the greatest prodigy of them all, Mozart who created his first symphony at 13. 

But today, we’ll be focusing on a more modern prodigy. And that is, of course, bpmn.io which turns 10 this year. And fun fact: has more Github stars than all of those composers combined, so measurably superior to all those mentioned.

bpmn.io is a set of libraries that is core to the BPMN modeling experience. Everything you do – modeling on the canvas, adding execution semantics, everything that happens uses that collection of libraries.

And who better to help me tackle this topic than our own Principal Engineer and Creator of bpmn.io, Nico Rehwaldt. We’ll be talking about the development and history of bpmn.io over the last ten years as well as the decisions that were made and the consequences of those which have been really interesting–especially for the community.

We’ll also be discussing how the community has actually inspired some of the choices we made.

We hope that you enjoy the conversation about it, hope it gives you some inspiration to join the community and help us raise this wonderful little prodigy. 



01:35 - Meet Nico Rehwaldt
[NIALL] Hello! Well, it is the year 2024, and the biggest event that happened 10 years ago, in 2014, was, of course, the creation of the bpmn.io libraries. So, in respect of that great milestone, we have brought with us the only brain in Camunda that can possibly guide us through the intricacies and the history of bpmn.io, the the creator of bpmn.io: Nico Rehwaldt. Would you like to introduce yourself?

[NICO REHWALDT] Good day, Niall. Thanks for having me. I'm Nico. I am working with Camunda since a long time. I actually started with trying to implement stuff on the engine. So, I remember when I was working with Daniel Meyer together, trying to get the terminate end event implemented. Then he rewrote whatever I did. That was my introduction into Camunda.

What I found soon is that I'm really interested and obsessed with editor tooling.

So we at Camunda, already at the time, we had a great engine. But engine is not the full picture.

As users, we need to work with technology in all different aspects. And only automation doesn't cut it. I need to be able to have this technology to draw BPMN. Drawing has to be easy. BPMN is not an easy standard. It's a complex standard. But this is really when I started to realize that we at Camunda were something missing fundamentally, which is a great modeling tooling that basically adds to the great engine that we had.

So now I'm here with company for, I think, like 12 years or something, have been working with the bpmn.io crew for a long time, bootstrapped the project initially.

And now I am as a principal software engineer in the whole modeling space, making sure that the things that we're building comes together for the user. Like, while there's many different teams working on many different things and we're solving different problems, in the end, it should all be simple and understandable, and should all empower the users.

[NIALL] Yeah, absolutely. And it is, of course, part of Camunda lore that the terminate event was the moment that terminated Nico Rehwaldt’s career as a back end engineer and ended up propelling him to to front end and Javascript life of fun.

03:45 - What is bpmn.io?

[NIALL] Can you please give me a quick, very simple answer to a very complicated question: what is bpmn.io?

[NICO] bpmn.io is basically the answer to the question that I have: like building tooling that empowers people to make those standards accessible on the modeling side of things, right?

We started with BPMN, but we extended it to DMN, CMMN. We also extended it to Forms which is actually not a standard but it's something that is fundamental to process orchestration. bpmn.io basically complements your engine with the tools that you fundamentally need to draw those diagrams to communicate, right?

You mentioned It's a library. Yes, it's a library. It's not like a full-fledged editor application. Why is it a library in the first place? Why wouldn't I create an application when I have the task for Camunda to build a solution to build, to draw BPMN?

I would say, Camunda is, here, maybe a little bit lucky that they chose Nico to do it. I fundamentally believe that really we can't make a simple call, “This is a program that people are going to use to draw.”

Because, already in 2014, it was clear that the Internet was a platform.

Nowadays, at Camunda, bpmn.io is used everywhere. It's used in the Web Modeler. It's used in the Desktop Modeler. It's used in the community. Someone, for example, is is xml-based format and merging xml is a pain, right? So you rather want to merge visually. So someone actually created a git merge tool based on bpmn.io.

You have a task. And the task is to visualize BPMN and to be able to edit it like, have a BPMN toolkit. And you really limit yourself down by saying, I write this in a C# application, or I embed this in Eclipse. And where we are we're coming from, actually, there was obviously a little bit of history. People were not hand-drawing those BPMN diagrams.

There was an Oryx-based editor, later Signavio for example, where people would be able to use this. So we would basically partner with them and or say, like, “This is a great, good BPMN editor.”

There was an Eclipse-based modeling tool from Red Hat, which I think is still, it's still there. So the very first version of the Camunda Modeler was actually an Eclipse Plugin.

[NIALL] I remember that. That's a really good point you made. We didn't just build bpmn.io because we needed a modeler. We built bpmn.io because–I remember, I, at the time, I was a consultant, so I was building projects with the Eclipse Modeler. But I was training people in BPMN with the Signavio Modeler, because the Eclipse Modeler was very developer-focused, and for developers who wanted to build BPMN models for execution. But the BPMN training was, in some cases, not technical. So we– we couldn't get people to install Eclipse.

And I think the fact that Camunda was using two different types of modelers for two different reasons–you've probably noticed we have very, very cleverly combined both use cases into a single place where a technical or non-technical user can feel at home.

And it's not just because, as you just said, someone said to, “Hey Nico, go build an application that's going to be able to make us build models.”

You looked at what we had. And we thought, you know, “Let's build something that isn't there yet. Let's build something that is much better than what's currently there.”

[NICO] Exactly. I always like to look back at when we set up bpmn.io and there's a strong project vision.

So bpmn.io, the vision was, “BPMN, everywhere for everyone.”

Obviously, nowadays the scope broadens. So we also have DMN, Forms, right? But still this, “everywhere for everyone.” So what we're really trying to do is, we're trying to not cause a divide. Like that some user group uses one tool, another user group uses another tool, because, in the end, everyone is going to collaborate. I, as a developer, need to be able to collaborate with a business person, right? And this is really why we did something which is which is bold, which is also complicated. But we tried to build something that is simple enough.

And one way we do it, we're doing it is by making it a library that is being that is possible to embed everywhere. The second way we're doing it is by making it extensible. And this is again also like like at, at the core of “Everywhere, for everyone.”

Like we early realized that, when we want to realize this vision of having one tool for all the different use cases, we have to realize that people are using it in different ways. They have different requirements. They may require different features–for example, a properties panel for technical editing, but then also for non-technical editing, you know, on-canvas comments and whatnot, right? So we realize we can only really do this when the core is also extensible.

So when we look at bpmn.io now, we- we actually have a really well-working, or bpmn-js particular, well-working BPMN Editor. But also it is superpowered through extensibility at the core.

08:51 - The Role of the Community in bpmn.io

[NIALL]  Let's talk more about that, actually. Because community has a really big part in this. And just because something is extendable doesn't necessarily mean it'll be extended. Someone needs to go and do- do things with that.

The biggest example I can think of from early on was probably the heat map which was a community contribution on bpmn.io, which became a fundamental part of our our product.

And that's just one example. Can you talk a little bit about the trajectory of the community along with the growth of bpmn.io– how it started, where you kind of saw the growth, and how we managed to have what is right now an incredibly vibrant community, still, which is consistently adding– we were just talking this week about new extensions from about what was it? The collapsed events subprocess.

[NICO]  There's many different perspectives to consider, right? So the first perspective, obviously, a lot of the things that we've built at bpmn.io, we've built because, you know, I had some gut feeling that it makes sense. And obviously, if we build a community, we need to give something to the community.

So we gave people this tool that they can use in all the different places easily. So we made it accessible to them.

We could have hidden that behind a paywall. We could have made it closed source. It could have been done in C# as a desktop-only tool. No, we decided to use a web platform which is ubiquitous. We make it super easy to get started. We started with examples really early. So this is basically how we kick-start people into using it.

And at the same time, we always had a strong messaging on extensions. So our messaging was always that, “This is what you got right now, but this is how you can extend it.”

So the first extension, which was an obvious one is how to add overlays. Because, you know, in Google Maps, people can do that. Basically, you can add your markers on top of the existing map. So one of the first things and examples we created is, “Okay. This is how you can add custom metadata to your diagram.”

So then people would immediately read about. “That's super interesting, because I can use that for comments on the diagram”,” or “I can use that to show production KPIs on my running processes,” right? There's so many things that people could do.

And what's really interesting here that the community isn't necessarily coming from the Camunda context. The community is coming from the BPMN, BPM–like business process management–context at large.

Where there's a lot of people that realize the value of, you know, having the BPMN diagram visible inside your applications, inside your dashboards, inside your monitoring tools, but also being able to model it. So a lot of places, and we don't actually have ties to Camunda; there's no Camunda engine running behind.

Still, people buy into this ideas. “Oh, I can easily embed it. but then I can also extend it.”

Why do we make it as as extensible as possible? Like you can literally exchange every screw.

We have a sketchy extension which basically replaces the whole rendering part so suddenly a diagram looks like hand-drawn. We made an April’s Fool when there was Corona Pandemia going on–how you know child-friendly, like how you can improve your child-parent collaboration by just, you know, using this child-friendly BPMN modeling notation which both would just replace renderer. So that's an easy thing to do, right? But why? Why do we do that? And the answer is because we can't know all use cases.

But in order to be this universal, like this for everyone, we need to account for someone being an expert in their domain and saying, “I need this and this. But I can build it myself, because I'm also an expert.” And so this is this interesting alternative to us needing to build everything– making it extensible, and then allowing everyone, if they spend the time and effort, to extend it. And and honestly, there is incredible things that people do.

Some of those bpmn.js-powered editors, they don't actually look like BPMN editors anymore.

[NIALL] Yeah, actually, it made me think about your alma mater in Potsdam. In Potsdam, some folks there used the bpmn.io libraries to build an entirely different modeling notation. The choreography modeling they built entirely with bpmn.io which is a completely different notation. It's in the same realm. But it's, it's looks different, different rules. And it was so extendable and so customizable that they managed to use that correctly as well to build their entire thing from scratch with a tool that is actually built for a completely different notation.

It's always really impressive to see and you can sometimes never fully know what, as you said, what people are going to use it for next. All you can do is, yeah, allow people to take off as many screws as they want and replace more things.

[NICO] One additional note, like BPMN is often used also in the context of, you know, software– like like large-scale enterprise architecture connecting systems, and so on. So we have one community contributor that wrote a Modeler for ArchiMate diagrams. ArchiMate.js makes accessible this, you know, ArchiMate modeling notation which is otherwise only available for desktop editors, on the web, based on the kind of bpmn.io platform.

Those are obviously, those are tremendous contributions. We also have contributions that are smaller, a little bit just extending bpmn.js right? Or we have people that contribute by fixing. Or we have people that are just helping the Forum. So there's many different layers where people contribute nowadays.


14:08 - The Role of the bpmn.io Team

[NIALL] But what we can talk about now is actually things that people don't necessarily see. Can you talk a little bit about what the team inside Camunda is like? What kind of decisions they make? bpmn.io is used throughout almost every front end product, I think we have. How does the bpmn.io team stay abreast of every way that it's being used across Camunda? And how does it help other teams and decision-making internally?

[NICO] We're a little bit in a unique position, right? We don't actually build a Camunda product. But we built a foundation of a Camunda product. We built a general-purpose BPMN toolkit and Camunda is one of the users.

Camunda is obviously a driver of innovation that happens inside bpmn.io. So, for example, one of the initiatives that we had that we had was improving the canvas, which, you know, if you look back, it hasn't really changed since 2014, fundamentally.

Now we look at other tools, the hypothesis is, maybe we can give the canvas a refresh, to make it actually still simpler. So this is one of the investments that Camunda actually drove.

Let me give you another example. 2022, one of the fundamental modeling UX improvements was create append anything. So we have the context pad in the bpmn-js, where you can append a task or a gateway or an end event.

And one thing that we realized, especially when you do technical modeling, I don't want to just append a blank task.

I want to append a service task. I want to append a collapsed sub-process, right? I want to, or I want to create something that may not visible in the palette. I still want to easily create it. So what we added, is an extension that is like a dot dot dot, you know, and then you just append whatever, create whatever. And if we combine that with keyboard shortcuts, we really superpower professional users, power users.

So this is what we did. We integrated it into the core. And then we got a lot of pushback from the community and say, “No, in my very very limited setup of bpmn.-js right, where I, by design only allow start event tasks and end events. And so I don't need this.”

So what we do a lot of times, we translate Camunda requirements that we have and then we really make sure that how can we get those things into the bpmn.io sphere but also taking account the hundreds of different ways how people are using bpmn.io. So what we did in one of the next major releases, we ripped it out again. We said, “Okay, we learn this is nothing that fits into the core of the library. But it's absolutely an extension that we support.”

So you see it embedded to the bpmn.io demo, you see it basically added to all of Camunda's modeling tools, and you will probably see it to most professional, you know, large-scale modeling tools that use bpmn-js.

But you will not see it in every BPMN Editor there is. So this is really one of the things that we do.

The other thing that we do as a team is one really important aspect is the community work. So we are basically the in the bpmn.io forum, like answering people's questions. When people reach out with their new use cases. And we have, you know, a constant stream of issues opening across our 100 something repositories– people asking for how to do this like, “I have a new use case which I think isn't being addressed yet.”

And then we spent a lot of time to really understand those use cases and always figuring which of those things are actually where the person needs to extend the core, and which of those things are actually feature gaps in the core. And then we implement those things.

And then the third aspect that we're doing as the bpmn.io team, we're actually doing a lot of internal consulting because we have at the core a huge amount of experience when it comes to, first, the BPMN standard, how it works, but also using it, making it accessible to people.

What we're really doing is we're working, for example, very closely with the Web Modeler team. We are maintaining also the Desktop Modeler ourselves. So we're not only building libraries, but we're also consuming, which is, I think, called dog-fooding, which is always a good practice. Yeah. So this, really, we're also consulting quite a lot inside the organization.

And we've seen bpmn.io extend beyond just those diagrams, right? We have BPMN diagram editing. We have DMN diagram editing. We have Forms which is not a standard. But again, it empowers people in the same domain. Now we have FEEL. FEEL is an expression language.

So the bpmn.io, it actually extends to all those places that are fundamental to you being successful to communicating process.

[NIALL] It’s worth mentioning what a great success bpmn.io has been for Camunda. The jump from Camunda 7 to Camunda 8, one of the only things we really kept unchanged was the bpmn.io libraries and BPMN in general. It's this incredible success which makes makes the next question a strange one. But bear with me.

19:17 - Are there any regrets from the past 10 years?

[NIALL] It's been 10 years since you first created bpmn.io. And I'm interested if there's any decisions you think you could have made earlier or differently, or there's some things that you feel, “Oh, if only we had done that, then it would have made things easier in the long run?”

[NICO] I am an impatient person. So if you ask me, one of the things I would regret is, why didn't we do certain things earlier?

bpmn.io, honestly, we're super successful now, but we had an extremely slow start. Like, you know, reflecting on my internal impatience. When initially, it was me and Jörg from from Zalando working on it. But very, very early, for example, we like we've seen the potential.

But we didn't really act on it. If you, at at some point, you know, when the architecture is set, this is the point when you can scale out, you can actually add more people to it. So it took us a little bit of time to really form a stable team around it. That only happened in the last 5, 6 years.

We need to have a stable team. We also need to have a stable team of experts.

So this is more like a personal, you know, feeling like, if we have things like bpmn.io, which has such a potential, we as a Camunda could have staffed that a little bit earlier.

And now I'm super happy. This is why I don't actually really have regrets, because there's always things that you can change in the past. But you have to look at the now, and now we're in a super healthy position.

We have the core modeling team is like one of the very senior teams in the company.

But also, why is that important? We need to think in all those like 3,000 external people that use bpmn-js when we build features right? Because we're building a framework and and which also requires a lot of considering a lot of different things. Also we want to accomplish quite a lot like, catering towards all those different audiences. So there's some complexity involved, and we're super well-staffed. We have a nice team. Also, the team gets the freedom and they are, as mentioned, used as a knowledge source as well, which is super important, right?

And then there's other things, you know. We are extremely extensible, which is amazing. But also, you know, not.

If you, for example, consider the use case where you want to make the Camunda Web Modeler extensible. When we talk about extensibility, especially in enterprise setups like, sometimes you want guardrails. Sometimes you actually don't want full freedom. So then you could argue well, was it a good decision to be so extensible? And I would still say by that, yes, it is because it enabled so much growth, internal like creativity, everything.

I still have no regrets, because it's extremely powerful, it's easy to use. And if we wanted as a company to really invest into collaborative modeling, we'll probably be able to make it work right?

[NIALL] Yeah, the guardrails thing was a great comment, because I still remember when, when your team had reached the milestone of implementing all of the BPMN symbols that we wanted to have in the Modeler and rendered, I still remember that one of the very first couple of questions we got was about, “How do I limit the number of symbols that people can see and use?” Immediately, our users wanted to add guardrails around what was possible for the reasons you mentioned before.

A great example being the complex gateway. If you're only building executable models, you do not want to see that gateway anywhere near any of your models. So you would ask, “Hey, can we remove this, please?”

And it always made me kind of smile, because I think it was the same week, or something that we had all the symbols added to bpmn.io that I then saw a forum question asking, “Can we limit the number of symbols people can see in bpmn.io?”

I-I do agree with you. I-I-I love the bpmn.io team, by the way. Of course I do, because I bug them all the time, and if I said otherwise, they maybe never help me again. Maciej, Calvin, Flip, and yourself, and and the others as well–incredibly helpful and really incredibly knowledgeable. So you're absolutely right. Like, right now, the core team, a very senior team of folks who have to help make a lot of decisions across all the products, as well as the community. It's a lot of responsibility.

23:24 - What’s next for bpmn.io?

[NIALL] We've talked a lot about going back. I want to, of course, discuss the the future of what's going to be happening in bpmn.io. We have a completely extendable set of libraries. We've gone beyond BPMN. Scope gets bigger and bigger every year.

So can you maybe talk a little bit about on an intellectual level, where you see the bpmn.io trademark, as it is, being defined as in, let's say, 5, 10 years?

[NICO] You mentioned that the scope gets bigger and bigger, and that that's the nature of the thing right? When the core tooling is so stable and so reliable, and people will use it. But in the process, because this problem is solved for them, they would approach us with different things, right? I compare that a little bit like, if you have no door in your house, you will not be able to get in.

Only when you are at the door, you can actually get in. And then you can think about the interior right? So this is really what we see happening. Like, when some aspect is super stable, super reliable, super extensible, then actually, we're going to get very different feedback. And this is also great learning from the product management perspective. Sometimes you have to build something in order to get the proper feedback to actually make a knowledgeable, a proper decision in some other areas. So a couple of things that we did in the past.

We did bpmn-js token simulation which is a fully BPMN-spec compliant token simulator. It doesn't tell you, you know, where the bottlenecks in your process. But it's simulation like being able to see the tokens flow on the diagram, and it is a fundamental learning tool. Because, yes, you can have a BPMN editor that prevents silly mistakes. But then, again, getting this idea of, “Okay, what would it execute like? What would execution look like? Right? It's something that is non-trivial for most of us.

Okay, this is a diagram. But then, again, how would it work in execution. So this is where we created token simulation as a project because it really complements core bpmn.io, it complements the idea of empowering people to be better at BPMN which they are only if they understand it also in the execution department, right?

[NIALL] Did you see token simulation as being like a step into a different domain, like a bigger scope around, “We can teach people stuff about BPMN?” Because going from modeling and viewing, to then fully explaining what's happening in a more concrete way. Is that a part of BPMN scope in the future?

[NICO] It is. Because our vision is, “BPMN, everywhere for everyone.” There's many other ways how we can empower you.

Token simulation is one of them which really reifies inside your head, “This is actually how the OR gateway join semantics work. Interesting.” And, obviously, we're not done with token simulation. Yes, it is BPMN-spec compliant. We just this year we got, or actually the OR-join implemented, which is very interesting. It's one of the most complicated constructs actually in BPMN.

You could call transactions and compensation also interesting concepts. But you know OR join is like really interesting and and a token simulation like helps so tremendously for you to understand it right.

But there's more things. For example, validation similar to token simulation. BPMN lint is one of those things that we created to empower you. So the idea that not only the Editor would prevent the most silly mistakes.

And then there's so much more. There's modeling guidance. There's different ways to model. There's implicit modeling with no gateways. There's explicit modeling that says no implicit gateways, no implicit modeling–please only use gateways. So there's actually this topic of modeling styles.

But also, you know certain ways how you shoot yourself in the foot, how you maybe cause harm to your coworkers if you build something in one way, because it's not as easy to understand as in another way.

So this is where BPMN lint comes in, which is an infrastructure that we've created to validate BPMN diagrams. But obviously not only on the web platform, because validation can also happen in your CI pipeline. Validation can happen, you know, in headless environments. So, for example, you would only allow a certain process to be put in production when it meets certain also, you know, quality criteria.

BPMN lint is another one of those projects which doesn't really have to do with BPMN drawing and visualizing on the web. But it's really fundamental, it's really core to this, “Everywhere for everyone.” Because validation is something where we can empower our users even more. Right?

[NIALL] Yeah, I agree. And I’m gonna go a little bit beyond that, because there's that is possible now, right? That's what we currently have. And I love the linting tool. It's really good. As everything that's built there, it's also extendable. So if your linting rules are different, it's very easy to change those.

One of the things I thought about when you were talking about that scope is something we get asked quite a bit, by, designers and analysts of BPMN models which is being able to create what is essentially a like a more complex simulation.

Where they say, “Hey, I've got my model, but I want to know what it might be like if it were to run given certain restrictions like this service takes X amount of time to use, or this costs this amount of money,” and then run a simulation that way. Do you think that's beyond the scope of bpmn.io, and should be used, maybe in conjunction with the engine? Or do you think that's definitely something bpmn.io should be able to handle?

[NICO] It becomes a little bit hard to draw the line right? I mean, this is also, you could, argue like this is a different kind of simulation, which is sometimes, you know, confused with what we have in token simulation, which is about really understanding where are bottlenecks in my process. For example, how much cost would it happen, right, in when I scale up like certain amount of process instance. So this is this other kind of you know simulation that you were referring to. It has its own sets of complexity.

And it's also not fundamentally about learning BPMN, but really learning in depth what effects does the way that I implement my process have on execution. So this is actually something that I see much more in tools that we, as Camunda offer, like Optimize, for example.

I think the token simulator, it doesn't evaluate expressions, which is something that you would want to add.

But but I think that extends the scope of bpmn.io, just because this is then not about learning BPMN anymore. But this is really about, analyzing in detail, the impact of the solution that you created, right? Which is going a little bit more into the scope of Camunda, for example, as a tool vendor for for BPMN platforms and and analytics tools. And so on.

[NIALL] Yeah, that makes a lot of sense. Thanks for that. I don't think we can predict what the scope of BPMN.io, might look like.

I definitely remember thinking DMN makes complete sense to add. And then forms.io showed up, and I thought, “Oh, that's that's definitely a jump in scope.” But they've all been great, great successes for Camunda internally and for the community at large. So I'm really looking forward to seeing what the next big like scope jump will be. Whatever it is, it'll be a massive success.

We actually could talk for a long time, and probably will further about this and other topics around bpmn.io and Camunda. And it's always great to chat to you. So thanks for taking the time, Nico. Greatly appreciate it.

30:41 - Thank You

[NIALL] Do you have any parting words for the community at large using the product you've created?

[NICO] I would like to thank the community. I would like to thank everyone who's actually contributing. That means everything from reaching out to us to the Forum, but also just contributing fixes. And last year we received 85 community contributions, just fixing things or improving things around internationalization, bugs, new BPMN support–that's incredible.

So I would like to thank everyone for that.

[NIALL] Cool. Well, thanks a million, Nico, and yeah, I'll talk to you in soon, and thanks everyone for listening. Bye, bye.

[NICO] Bye.

31:20 - Conclusion

[NIALL] Now, obviously, as a very big fan of BPMN myself, it was a joy to chat to Nico about it. And, of course, being at Camunda, I’m very lucky to get that opportunity. BUT did you know you have that opportunity, too? That’s right! I have a bunch of links below to the community pages where Nico and the rest of the team tend to hang out. They are very active in the community as Nico mentioned. 

And, hey, if you’re using bpmn.io or you want to contribute, go for it! Why not? And, while you’re there, why not also subscribe to the podcast and you can continue to listen to fun stuff about Camunda and orchestration and DMN and BPMN and FEEL and all sorts of stuff. 

I’ve been Niall the whole time. Byeee. 


32:12 - Easter Egg

[NIALL]  So I also want to very briefly to to remind the world that I bothered your team about token simulation for so long that Paddy created a website, ‘Is token simulation implemented yet?” that just had the word, “No,” on it.