You can’t go very far with Kumu without needing to roll up your sleeves, open up the docs, and get your hands dirty writing some code. It’s not a coincidence that many of the prolific and successful mappers in our community have a technical background, but Kumu isn’t a tool for programmers. It’s a tool for anyone that wants to make sense of connected complexity.

Kumu (as you know it today) uses a homemade language that is a dialect of CSS for defining views. It’s not a language that has a name, or any kind of formal specification. We started with CSS (the language browsers use for styling web pages) and translated some of the concepts to apply them to networks. Behind the scenes there’s a forked PostCSS parser, that we’ve extended to understand concepts like @settings, @controls, and traversal selectors.

The decision to define views with code has saved us a huge amount of incidental complexity over the years. Adding new style properties is trivially easy. We already have the machinery in place to support powerful ideas, such as partial views, without ever having to think about how to give them a user interface.

The problem is that the complexity is still there, we’re just offloading it to our users instead. To use Kumu, they’ll have to learn to write code.

To tell a compelling story using Kumu, you’ll need to spend far more time in documentation than you would with most tools. You’ll need to understand concepts like selectors. You’ll need to have an intuition for syntactic correctness, and fixing problems from our relatively vague parsing errors. Heck, for a long time, you even needed to know how to resolve Git-style merge conflicts when multiple people were editing concurrently.

If you have a technical background, this isn’t a huge ask. Compared to modern day text editors, you’ll probably notice the lack of automatic completions and intellisense though. There’s some jank as controls modify the current view and we serialise the internal syntax tree back to CSS (clobbering most comments and any personal formatting preferences). It can be frustrating, but armed with the documentation, you can be reasonably productive, reasonably quickly.

If you don’t have a technical background, Kumu can be a bit of a scary place. We have a “Basic Editor” which gives users access to an important subset of the power of views, but most projects need to go beyond that subset. Most people who use Kumu will need to learn to use the advanced editor, and learning to use the advanced editor is still a significant hurdle.

These are the kinds of hurdles we’re aiming to remove forever as we re-imagine the tool. It has become one of the principles that’s guiding our design. Users should never need to write code to make maps.

Advanced Editor

Let’s take a look at a fairly simple style rule in the advanced editor to get a sense of the level of complexity here (it is easy to forget, if you’ve been using Kumu for a while).

Legend Metadata

We’ll kick off with the odd way we encode legend information. The comment (the /* … */ syntax) above this rule is a directive which says:

• Include a preview of this style rule in the legend.

• Render the preview as an element rather than a connection.

• Use the label “Congress”.

This has some symmetry with the way programmers often use doc comments to annotate the details of functions, but in Kumu there’s nothing obvious that links that comment to the legend.

Selectors

The next thing you’re hit with is an attribute selector. It selects all elements with the type “Institutional Norms & Processes”. This is how you decide which elements or connections will be styled. Most selectors are easy enough to read, but for many users, writing them by hand will require a trip to the documentation.

This is one way to write this selector, but you also have access to shorthand syntax for writing type selectors.

["Element type"="Congress"] { ... }

/* is equivalent to */

congress { ... }

The shorthand here is quicker to type and feels more familiar to folks with a CSS background, but users have to guess what our rules for normalising types are.

What would the shorthand be for the selector from the example?

["Element type"="Institutional Norms & Processes"] { ... }

Well, it depends entirely on how our normalisation process handles the ampersand. It could be institutional-norms-processes or it could be institutional-norms-and-processes. I would bet on it being the former, but off the top of my head, I don’t actually know.

This also introduces an unfortunate bias towards people using the Latin alphabet. Want to take a guess at the shorthand selector for 使用高级编辑器? Software has a huge problem with Americentrism and here we’re part of the problem!

Some of the complexity in selectors is invisible! Trying to figure out why one of your style rules is overriding another? Time to learn about specificity!

Even the folks coming from CSS can have a hard time with selectors. Gone is the browser’s element tree, now you need to learn to think in graphs! There are no parent—child relationships, so you’ll need to learn about the syntactic extensions we’ve added, like traversals.

person --> organization

Does this select all people that have a directed connection to organizations? Or does it select all organizations that have a directed connection from people?

If you come from CSS, you’re likely to assume it’s the latter, because of the associativity of CSS combinators. If you didn’t come from CSS, then you’ll need the docs to resolve the ambiguity.

Style Properties

And finally we get into the style properties inside the rule. These follow the traditional CSS key-value model, and when sensible, we’ve kept keys that overlap with CSS, but we’ve tweaked others which created confusion.

["Element Type"="Institutional Norms & Processes"] {
  color: #63A3AE;
  font-color: #111;
  size: 70;
  border-width: 0;
  text-align: center;
}

For example, color will set the background color (not the text color like it would in CSS). Properties like margin and padding probably work like you’d expect, but they too come with caveats, such as requiring unitless values. No px or em here, please! Properties like text-align work on the vertical axis, because that’s more natural for element labels.

What’s this #63A3AE thing? To many people, it’s a meaningless jumble of letters. In fact (as you probably know if you’re reading this blog) it’s the hexadecimal representation of a color. The first pair of digits are the red channel, the second pair is the green channel, and the last pair is the blue channel. Even when you’ve gotten your head around hexadecimal numbers, RGB is a notoriously hard model for humans to work in. We’re terrible at figuring out how much green to subtract to make a colour less saturated, for example! Hex codes are a conveniently terse way to express color, but not to design or adjust it.

The example we’re looking at has five style properties and the syntax is approachable enough that it’s reasonably straightforward to read and to change. But consider that all style rules begin life as an empty block with no properties at all.

["Element Type"="Institutional Norms & Processes"] {
  
}

Your cursor is there, blinking emphatically, waiting for you to start typing. There isn’t any more guidance than that. Either you’ve memorised our property reference or your next trip will be to the docs. Every single time you have to leave your map to read documentation disrupts your cognitive flow and the visits to the docs are an inescapable part of using the advanced editor.

Syntax Errors

So far we’ve only talked about the happy path where everything works first try. What happens when you make a mistake?

Well, it depends on the kind of mistake. An innocuous misspelling isn’t considered a syntax error. Are you the kind person who writes colour instead of color? That will be on you to spot. It’s technically feasible for us to detect unrecognised properties, but it would be harder than you’d expect due to the feature-by-feature parsing architecture we use.

When you do hit a legitimate syntax error, such as a missing brace or an unclosed quote, your whole map will revert to its unstyled form and we’ll show you a “descriptive” error.

Maybe if we’d started building Kumu v2 in the days of Monaco and the Language Server Protocol we’d have an advanced editor that gave you red squigglies and autocompletions, but our CSS language predates them both and retrofitting them now would be hard, if not impossible.

New Editor

The advanced editor has served us and thousands of others well for over a decade now. It has enabled us to iterate on features far faster than we ever would have done if we’d been needing to build user interface for every single style property we support.

All good things come to an end, and in v3 we’re saying goodbye to the advanced editor and hello to a more intuitive way to edit views.

Let’s take a look at that same style rule inside an early version of the new editor in Kumu v3.

We’re bringing the editor much closer to what you’d expect to find in contemporary design tools, with Figma being a particularly strong influence on how we’ve structured the interface.

This is not the finished product. We expect to do multiple rounds of refinements between now and the release of Kumu v3, but there’s enough here to give you a flavour of how it will eventually feel to create views in Kumu.

Views & Style Rules

The first thing you may notice here is that we’re no longer looking at an entire view. Instead we’re focused in on a single style rule.

When you open a view, you’ll see a list of all the style rules it contains.

Each rule has a style preview (same as you’d see in the legend) and if you’ve added a legend label, you’ll see that there too. If not, then you’ll instead see the selector that the rule uses, which is often the most accurate descriptor (it doesn’t look like a selector but it is. Read on!).

We also removed the idea of selector specificity whilst we were at it. Now your style rules are applied in the order they are defined. A rule at the bottom of the list beats a rule at the top of the list and you can drag and drop to re-arrange them.

Selectors

You can’t have Kumu without the concept of selectors. They’re an essential part of style rules, but we also use them for controls, for configuring clustering, focus, and showcasing, and even for presentations and widgets inside markdown. But there’s no escaping it, selectors are code and users should never need to write code to make maps.

Part of redesigning the editor involved a significant rethink of our selector builder (a process which deserves a whole post of it’s own).

Instead of leaving you to get the syntax right on your own, you get to type freely and we’ll suggest tokens that you can use to build a selector. Not only does this tend to be faster, it’s far less mistake prone, because it’s impossible to make syntactic errors, and the filtering will often guide you towards picking an existing value, rather than ever finding yourself typing out “Institutional Norms & Processes” by hand.

In those rare cases where you want to get at the underlying text, there’s still a way to hop back to editing manually!

A lot of work went into figuring out a blend between a UI that would be approachable and UI that would be efficient compared to writing text. What you’re seeing above is actually “Selector Builder 5” but we finally feel like it’s into a really solid place.

I’m tactically sidestepping some of the unsolved challenges here. We’re still figuring out a natural way to build UI for traversal selectors and some kinds of parameterised psuedoselectors (think :to and :from) where you actually end up with selectors inside selectors. Maybe we’ll explore some of the options we’re considering in a future post about the selector builder.

Style Properties

Once you’ve tweaked the selector, all that’s left is to start editing the style properties!

Unlike the intimidating empty block in the advanced editor, everything you can possibly do to style an element is discoverable right there onscreen. Borders, shadows, bullseyes, flags, labels. They’re all right there.

We’ve gone to great lengths to make these controls as user-friendly as possible. Every number you see is draggable (no more guessing values). Every colour is actually a colour (and opens a colour picker when clicked). We’ve got buttons that toggle and buttons that cycle. We’ve got dropdowns for selecting fields.

We’re currently in the final stages of supporting dynamic style values (think scaling a property, or categorizing by color, based on a field value).

A great benefit of this approach will be knowing which properties can take can dynamic style values, just by looking at the editor.

Internal Representation

CSS is a great format for humans, but it’s kind of awkward for computers. To interpret CSS you need to parse it. What you get back from the parser is a syntax tree which is easy to program. If something changes the syntax tree, then you can serialise it to get new CSS. If something changes the CSS, you can parse it to get a new syntax tree.

In v3, we can skip the parser and serialiser completely and always work with the syntax tree instead. It’s not as readable as CSS but JSON is still readable enough.

Most Kumu users won’t ever need to know what language we’re using internally, but the decision to move away from CSS means we’ll no longer be maintaining a custom CSS parser. That’s less code we need to ship to browsers for Kumu to work and it’s less time spent parsing views before your map can render.

We’ll Miss Writing Code

Sure, the advanced editor has some rough edges. Sure it’s unusual for a tool with a primarily non-technical user base to expect people to write code. And sure, it has a steep learning curve. But, it has its own charm and some of our users have invested significant time developing competency there.

When you’re editing in the advanced editor, you’re just editing text. It means you’re susceptible to making all sorts of mistakes, but plain text also has super powers.

The browser’s native search just works. Undo and redo are well defined operations with predictable operational semantics and built-in keyboard shortcuts.

You can see the complete definition of the view in one text input. That means you can edit multiple style rules in parallel without having to navigate backwards and forwards.

You can select, copy, and paste arbitrary selections and it’s hard to overstate how important this is. You can copy style rules to duplicate them. You can copy your view into a text editor of your choice as a backup. You can copy the style properties from one rule to another. We’ll try to mitigate some of this by making it straightforward to duplicate style rules and even entire views. We’ll also think about making it possible to actually copy (or export) a view or a style rule directly to your clipboard as JSON that you can paste into other projects.

The advanced editor also allowed us to iterate rapidly for years and years. We could experiment with new types of decorations, settings, and controls, without changing the UI at all. No need to figure out where something will fit, or which icon to use, or how to make it accessible to keyboard users. We’d just document the new properties and people could start using them immediately. There is no doubt that we will iterate more slowly when it comes to the new editor, but maybe that’s fine. There’s not a lot of decorative space left for Kumu to explore.

What’s Next?

There’s stuff we can’t show yet, like controls and partial views and that’s because we haven’t implemented them! But rest assured, we’re not planning to remove any advanced editor functionality, you’ll just be controlling it with inputs and buttons and dropdowns, rather than with text.

There’s a bright future for the new editor, but the ideas presented here are not yet rigid. We have some strong opinions but we’re ready to engage with feedback that challenges them too. Hop into our Discord server for v3 or drop us a line at support@kumu.io and let us know!

We spent much of the last two years trying to modernise the frontend of Kumu’s codebase, and ultimately, our slow progress caused us to abandon those efforts and contributed to the decision to rewrite Kumu instead. One of the inhibitors was CoffeeScript, and indirectly, the whole suite of tools that we use to turn code that isn’t-quite-JavaScript into JavaScript.

CoffeeScript

CoffeeScript (for anyone lucky enough not to remember) is a little language that provides some subjective syntactic sugar for JavaScript. It was created during a time when JavaScript had no arrow functions, no classes, no destructuring, no default parameters, no rest parameters, no spreading, no nullish coalescing, and no string interpolation. CoffeeScript provided all of the above and more. If you were going to write significant quantities of code, it was a decent quality of life improvement.

CoffeeScript often went hand-in-hand with Ruby on Rails, and that’s how it ended up becoming the first language in Kumu’s frontend codebase.

Most languages for frontend development need to be compiled into JavaScript, which means you’ll need a way to run a compiler. In those early days, our tools were Sprockets and the Rails Asset Pipeline. CoffeeScript goes in, JavaScript comes out. This was way before CommonJS modules and before bundlers, but you could still sort of stitch files together with some funky #= require comments. Still, the only way for code in one file to interact with code in another file was through global variables, and this was one of the defining features of the older parts of our codebase.

Webpack

Then along came Webpack, an imperfect harbinger of better days for modules and tools. It was an alternative to the Rails Asset Pipeline, creating non-global module boundaries with CommonJS (CJS) modules. Webpack also supported the concept of “loaders”—ways to transform arbitrary code into bundleable JavaScript. Armed with the “Coffee Loader” we added Webpack into our tooling and began a new chunk of caffeinated codebase.

Webpack was still a relatively new tool when we adopted it and a full migration from Sprockets would have been a gamble. Instead, Webpacked code lived in its own corner, and that’s where all the new code went. New code could talk to new code through requires and exports. New code could talk to old code through globals. Old code talking to new code? Well, that is a bit messy, the new code also needs to expose some globals. Not ideal, but we’d eventually move everything over, right?

Wrong. This setup was good enough that we ended up coasting for long enough that JavaScript had time to significantly improve as a language, implementing many of the syntactic niceties from CoffeeScript. There were fewer reasons to use CoffeeScript, and for new code we began using modern JavaScript features (along with some non-standard ones like JSX) adding Babel into our now burgeoning tool chain.

Our Webpack configuration grew to patch over some of the differences between the module formats we were using, and during this time we migrated all of our products to live in the same repository, in order to share Kumu’s core visualisation code. Monorepo-wide Webpack upgrades became a dreaded part of housekeeping, due to the complexity of the setup.

TypeScript

Ever turneth the wheel of frontend development, and we gradually began to adopt TypeScript in new projects. There was more contention around static types at the time, but these days it’s widely accepted that 20% more typing for 80% more confidence is an objectively good engineering tradeoff. Kumu is our primary tool, but it’s not our only tool. Of the other products we make, Sticky Studio, Undercurrent, and Weavr are all mature TypeScript codebases.

We’re sold on TypeScript, we have plenty of experience using it in production. Getting it into an existing codebase as big as Kumu, however, was a different challenge.

The story for incremental adoption is great. TypeScript is just JavaScript with some type annotations, so we began by sprinkling some types around the more modern parts of the Webpack side of our codebase. There was still friction where TS files imported completely untyped CoffeeScript files, but we were able to patch over that in many common cases by writing type declarations for CoffeeScript files.

It was a breath of fresh air to get some type safety into the codebase, but it wasn’t quite the strict TypeScript experience we were used to from our other codebases either. First, we couldn’t run the compiler in strict1 mode without creating lots of difficult work around the migration boundaries where TS and JS files interact. Second, we were still missing types for many of the bits of data that flow around Kumu’s frontend. Trying to fill in types for rabbit holes of object references was a trap we discovered in our earliest migration branches.

When types don’t line up, any is the easiest tool to reach for. In my experience, it’s also one of the few really poor design choices in the language. It’s easy to type and it looks harmless. It should instead be screaming “ALL BETS ARE OFF” in neon red. We opted to alias any as $FixMe which would serve as a clear indicator that we identified a missing or broken type, but fixing it would have been out of scope for whatever we were writing.

Decaffeination

Inspired by some wonderful write-ups on how Dropbox, Bugsnag, Benchling, and others, wrangled ambitious CoffeeScript migrations, we tried our hand at decaffeinate, a tool that turns CoffeeScript into readable JavaScript. Despite the battle-tested success of the tool, some of the quirks of our codebase and our Webpack setup meant that the automatic migration process didn’t go off without some significant hitches, generating code that lost a lot of clarity when translated from our idiosyncratic style of CoffeeScript.

With no way to confidently translate the whole codebase automatically, we began a painstaking file by file migration strategy.

We’d each take a CoffeeScript file, ensure it had unit tests, run decaffeinate to get JavaScript, clean up warnings and oddities by hand, convert it to loose TypeScript, check that the tests still pass, then apply more rigorous types. 50 lines of CoffeeScript would routinely turn into 200 or 300 lines of TypeScript, often due to the code in question being resistant to testing and requiring complex stubs for globals.

The line count inflation would have been reasonable if the code coming out the other side was rock solid, but time and time again, we introduced bugs during translation, because adding types steered us into adding safer checking branches, which conflicted with subtle edge case behaviours that would have been hard to infer and test from the original code. Many of these bugs made it through our end-to-end tests and we broke production in some fairly spectacular ways during this period. Sorry!

The direction of travel was good, but progress was Sisyphean and Sprockets was still doing its best to throw wrenches into many of our plans. Our codebase was still split (by this time, fairly evenly) between code on the Rails side, packaged by Sprockets, and code on the Webpack side, that could use modules and loaders. The only way to translate a CoffeeScript file under Sprockets, was to pull it across to the new side of the codebase, a process which invariably involved some hairy problems around the order in which global variables were declared.

We decided it would be good for our sanity to move everything from Sprockets to Webpack. We left the global variables alone, moved the asset directory over and replaced all of the Sprockets require comments with CJS require calls. There was a minor adventure in topological sorting to resolve some of the dependency chains that Webpack wouldn’t jive with, but somehow, miraculously, everything started working.

Major version upgrades to Webpack and Babel were surprisingly significant challenges during this process (including a particularly painful transition away from a plugin that smoothed over the Babel 5 changes to default exports at the CJS/ESM boundary). Normally a bundler would give you some kinds of static guarantees around module shape mismatch, but enough of our codebase still relied on globals that we sometimes didn’t notice errors until development runtime at best, and CI failures or bug reports at worst.

Then there’s also the inevitable, incidental firefighting which will always demand urgent attention:

• Oh, hey AWS, what’s that? Our main database server is running outside a VPC and we need to move it into the VPC by June? Ok. I’ll get right on that.

• Oh, not quite? the new database server was provisioned with a much smaller disk? That shouldn’t matter because our data is mounted onto a separate EBS volume with plenty of capacity. Then why is production down? Because our database stores gigabytes of indexes outside the mount point. Oh 🤦.

• Oh, why is search down? Because a rogue crawler ignored our robots.txt and decided to start crawling paginated search results for generic terms, overloading our Elasticsearch cluster.

• Oh, why are we getting huge bills from Twilio? Looks like our multi-factor authentication is being abused to send tens of thousands of SMS messages. Time to learn about “Toll Fraud” 🤷.

• Oh, why is there huge latency when creating new projects? Ah, looks like our database is overloaded due to spammers automating new project creation so that they can share suspicious links into social media platforms, using Kumu as a proxy. Time to deal with them. Again.

Energy is a precious resource in small engineering teams. If someone burns out, you notice their absence in ways that you can’t paper over, and this kind of tedious but well-intentioned work saps energy. No one enjoys sitting down to translate CoffeeScript, or to debug stack traces from tools by diving deep into the source for dependencies of dependencies of dependencies in the node modules directory. We were working harder than ever, and yet Kumu looked and felt the same.

Ultimately, we paused our migration process due to a lack of energy, to focus on some user facing improvements. That catalysed our decision to start from scratch, but we learned some important lessons from trying and failing to modernise a large codebase.

1. Bet cautiously but move confidently. Incremental approaches are good for exploration, but once you make a decision see it through, don’t get stuck straddling two approaches.

2. Static types are here to stay. We are betting on TypeScript for the next ten years of Kumu. It’s not a perfect language, but it is good enough.

3. Stay close to standards. Every deviation from the languages that actually run in browsers is an explicit decision to give yourself more work in the future when the landscape changes again.

4. Unopinionated tools create work. Our enormous Webpack configuration is effectively a new tool that no one else uses. This kind of complexity encourages abstractions and each layer of disconnect is a fragmentation that makes it harder to reason about the overall behaviour.

5. Be pragmatic around how you spend energy. Teams need energy in reserve to work effectively. Burned out engineers can’t fight fires, and the drip drip drip of slow CoffeeScript translations is not restorative.

There won’t be any CoffeeScript in the next version of Kumu. A rewrite is a chance to wipe the slate clean, but that doesn’t count for much if we make the same kinds of mistakes again.

If we’d stayed with the first version of Kumu, our ride would have stopped long ago, but because we rethought and rewrote the product at the right moment in time, we’re still here in 2024.

The second version of Kumu has been a wild success. It’s likely the only version of Kumu you’ll have ever known. It’s the version that has helped thousands of people all around the world wrangle complexity and make sense of stuff that matters.

It’s also the version of Kumu that has confused thousands of people around the world as they’ve tried to understand the differences between maps and views and elements and controls, or tried to import unstructured data, or had to learn our homebrew version of CSS to use the advanced editor. If you’ve used Kumu much, you’ll know that it’s an extremely powerful tool, with a steep learning curve and some pretty rough edges.

People arrive at Kumu hoping to make sense of something complicated and we hand them additional complexity. That’s a really difficult experience for a new user, especially if they don’t have a technical background, or the time to immerse themselves in our documentation, in order to map productively.

When people arrive with expectations from simpler tools, we often find ourselves having to say “No, you can’t do X, but if you combine Y and Z with a bit of Q, then you can get the same result with more control”. This is cool, but it isn’t helpful. Making powerful tools user-friendly is really tough.

For a long time, we’ve been chipping away at some of those barriers. We’ve learned a lot about how people expect Kumu to work, and we even built entire products like Sticky Studio to serve as an on-ramp for people who don’t need all of the features of Kumu to start mapping.

And here’s the crux of the problem; those barriers are growing faster than we can chip at them. We’re not trying to a cut out a chess piece, we’re trying to hold a cathedral together. We polish the floor, and an archway collapses. We work on the cloisters and the congregation never sees them. We add a flying buttress and the secret entrance into the crypts vanishes mysteriously, but we only find out three weeks later when the one monk who was using it sends a bug report.

Kumu has become resistant to change. The codebase is ten years old and many of the underlying technologies have not aged well. We spend more time than we’d like working behind the scenes to keep some of these obscure things stable. Technical debt is a very real problem and for every step we take towards modernisation, we watch another part of our product trend towards disrepair.

People often talk about these kinds of technical challenges whilst ignoring the fact that there’s an emotional angle that’s equally important. It’s hard to stay positive and motivated when progress is slow and the future is uncertain. If you hire thoughtful humans, it will be difficult for them show up every day, if they don’t feel like their work will make a meaningful difference.

We lost Ryan, our technical founder, in 2021. With him we lost a lot of the vision, and the energy, and the soul of Kumu. Losing a friend and a mentor is hard, and continuing his work without him is hard, but it’s the right thing for us to do.

We know how to improve Kumu, but we’re struggling to do it. We’ve spent the last few years filling the gaps in our knowledge, slowly modernising the codebase, upgrading the underlying technologies, and fighting the fires that are inevitable as a product grows and ages simultaneously. We live with an uncomfortable reality.

Kumu is aging faster than Kumu is improving.

That’s a difficult thing to write. You’re not supposed to be that honest about your product in public. You’re meant to project success and trap users on a treadmill of tedious tidbits of trivial changes to keep them “engaged”, but that’s not where we are today, and that’s not where we plan to be tomorrow.

We think it’s time to rethink Kumu.

Rewriting software is a dangerous undertaking. Starting over is a huge gamble, but for the sake of a world that seems determined to lose sight of the big picture, Kumu needs to still exist in ten years time. It won’t reverse climate change. It won’t solve world hunger, or end global conflict. It’s just a tool. But it’s a tool that might help in the hands of the people who could.

We’ve learned what works and what doesn’t. We know where people struggle, and we know where the cracks are starting to show behind the scenes. It’s time for us to do something ambitious and bold, something to make Kumu sustainable again. We’re going to rewrite the product from scratch. In fact, we already started, but now we’re confident that it’s the right decision at the right time.

The next version of Kumu is going to look a bit different, it’ll feel different, but Ryan’s ingenuity and ideas will live on as the heart of whatever we build.

This “Making Kumu” series is where we’ll tell the story as the next version of Kumu comes together. We’ll look at how we’re solving UI/UX problems, and the technological decisions we’re making. Most importantly, we want you—the people who use this crazy product—to get involved and ensure that Kumu v3 is the tool you need it to be.

We’ve set up a Discord server, where we’ll post sneak peaks, ask questions, and eventually, invite people to try closed betas of v3 when they’re ready. Here’s the invite link if you want to get involved. See you there! 👋

Subscribe now