Ideally, yes, you would be able to contribute plugins that work in both. And with the code in its current state, a plugin written for one (such as a simple docker) would probably work in another. From a practical standpoint, though, the code bases are going to start to diverge and that will probably mean API changes in the next couple versions. So down the road, that probably won’t be as easy.

Dion:

The beauty of the koffice design is that everything is modular. The music flake is just a plugin like any other plugin If the user doesn’t want it, he can simply turn it off and use the other features of koffice. Similarly, we only need to invest development resources there if someone wants to pick up the music flake plugin and really start to push the boundaries with it. The “one thing” we have chosen to do well is to make the code modular. In fact, it is a little too modular right now for my taste. The design seems to be heavily influenced by the “Design Patterns” programming paradigm which prioritizes runtime modularity and abstraction over code readability and inheritance. The more I get used to it, the more I like it, though.

Everyone:

It’s good to see everyone on here contributing their ideas. If any of you would like to dive into the code, I’ve gotten to a point where I think I can give you some good pointers on how things work and would love to help you get started.