[boringg]

Looks neat - pandas is very powerful and it makes it more approachable for non-programmers. However paid product like this - I probably wouldn't make the switch to this and then have the company go belly up leaving users stranded. Too much risk.

Hope for the best though - pandas is pretty fantastic.

[okennedy]

You might want to check out a tool Vizier: https://vizierdb.info (I'm one of the devs). Direct interaction with notebooks state (e.g., dataframes as spreadsheets) is one of the central ideas, and it's fully open source.

[aarondia]

This looks cool :)

[aarondia]

One of the creators of Mito, here. Thanks for your feedback. I wanted to share a couple of nuggets about Mito that have been helpful in talking about this with other users.

1. The core Mito product is open source. You can see our GitHub here [1]. We also have a pro version that has some additional, code visible, but non-open source features. The way that we think about which features belong in which version of the product is as following: Features that are needed to just get any average analysis done are open source features. On the other hand, features that are specifically useful in an organization -- connecting to company databases, formatting / styling data and graphs for a presentation, etc. -- are pro features. So if you are a team that is relying on our pro features, you're helping support the longevity & progress of Mito. If you are not one of those users and using the open source version, then you will always have access to Mito (and can even help improve it!). Of course the line between what features are specifically helpful in an organization and what feature are needed for an average analysis is a bit blurry, and is a moving target as we continue to expand Mito's offering.

2. Mito is designed specifically to not force users to make a big 'switch'. I've commented this elsewhere in this thread, but just to recap: Because Mito is an extension to Juptyer and because we generate python code for every edit you make, Mito is designed to improve your existing workflow instead of lock you into a new system. Many Mito users use Mito as a starting point! They do as much of their analysis as they can in the Mito spreadsheet and then continue writing more customized Python code to finish up their work.

Not requiring a big switch is nice for the user and its nice for Mito too! Lots of large companies have been able to get up and running with Mito in 30 minutes because it fits into their data stack.

Anyways, not that these are the only two reasons you might feel uneasy about adopting Mito, but at least wanted to share why the switch to Mito might be less scary than switching to other tools.

[1] https://github.com/mito-ds/monorepo

[kite_and_code]

I love how mito enables companies to use the power of open-source!

You might want to think about enabling companies to create the company specific extensions themselves e.g. via a plugin API. You might still request them to pay for this version of Mito but they are enabled to extend it with their engineering power instead of relying on you.

We had good experiences with this at bamboolib (I am one of the co-founders) and in addition to recurring license revenue it also increased demand for consulting from our end because the internal company devs started working on plugins and then wanted our direct guidance on how to get the more tricky things to work.

[narush]

Yeah, we've thought a bit about a plugin API - for the reasons you say, I think it would be an awesome feature to open up to teams!

Any tips on going about it? No need to share the secret sauce, unless you want :P

To be totally honest, we're not architected super well to support plugins currently. The big challenge would be allowing users to specify this plugin in pure Python (seems like we want this) - but we think that hand-coded UIs outperform autogenerated ones for now. We've been thinking about how to do better though... maybe soon.

Of course, if Mito is missing features, we're open source [1] -- all contributions are welcome! Also feel free to open an issue and we can discuss :)

[1] https://github.com/mito-ds/monorepo

[kite_and_code]

Cool to hear that!

To be honest, we regularly refactor our architecture at bamboolib in order to make sure that there is almost no gap between what we would love to say in natural language and the code that we need to write.

This resulted in a very stable and clear internal API surface (read architecture). So, literally, all we had to do was adding mount points where users could register their plugins and then include those at render time.

The next day, customers could write plugins just as we did. And, as a matter of fact, all the bamboolib transformations, visualizations, views, etc are just sophisticated plugins that our customers could write themselves because they have access to the same API as we do.

So, no secret sauce except for "good architecture" which is easiest achieved as an ongoing effort rather than an one-off project.