Thoughts on a Catalyst Roadmap

Every product roadmap needs to know where it is before you can figure out how to get where you want to be. Additionally every product, whether its a web framework, or hair gel, or whatever needs to know what it is so that you can plan how to make something a better and more desirable version of itself. In marketspeak this is called “A Product Statement”. In my mind, the idea of a product statement is inevitably intertwined with any meaningful roadmap; a roadmap without a sense of product is at best a jumble of well meaning but utterly uncoordinated and confusing changes.

So, what makes a good Product Statement? A good product statement helps you quickly understand what the product does, and how it is different from other similar products. In other words it helps potential users understand why they might want to use this product and why they’d choose it from others that they are also looking at to solve a given problem. A great product statement can even incorporate a philosophic stand, and actually inspire potential users. For example, when Roy Fieldings published his dissertation on REST, that was a product that inspired and shook up the web services industry. It quickly stated that you can build robust web architectures by simply following how the web works, and you don't need expensive, complicated middleware solutions like SOAP, CORBA or DCOM to achieve your wide area / distributed computing needs. Of course, great ideas like this have lots of gaps to fill, and we all continue to argue about how to do this and that, but in general the REST premise continues to offer guidance as we fill in those blanks and build a thought ecosystem of best practices offering solutions to common problems.

In this way a good product statement not only assists and inspires users, but also guides developers who are over time modifying the product, trying to keep it fresh and relevant.

So, in order to develop a meaningful roadmap for Catalyst, we need to be able to say what Catalyst is, and what is its reason for existence. What would be a good product statement for Catalyst? Lets start by seeing what we already say. On the Catalyst website we have two statements of interest, at least in my head. First we say:

Catalyst is an open-source Perl MVC web framework that encourages rapid development and clean design without getting in your way by forcing rules.

We also have a line like this:

Catalyst is the most popular Perl MVC framework and makes creating web applications fun, rewarding and quick.

These are very positive statements, however I am not completely convinced that they fully meet the goals I’ve outlined above regarding a great product statement. I would encourage you to take hard look at http://catalystframework.org/ , afterward asking yourself the following:

• How well do I understand what Catalyst is offering?
• Do I understand what makes Catalyst special and different from competing web frameworks such as Dancer, Mojolicious, Web Simple, or the temptation to just roll something from scratch using Plack?
• Do you feel that everything that is stated is completely accurate?
• If you wanted, as a user, guess where Catalyst is going to be in five years, can you do that? As someone that is contributing to Catalyst, or a possible contributor, do you know what would be a useful contribution?

I would say ‘probably not’ to these questions. I’m not saying the Catalyst website is bad, it does cover the bases, and there’s no rule that says your homepage has to slap your users in the face with a product statement, but it should be somewhere, if even just something floating around the minds of people participating on the thought ecosystem. And in addition, when you look at the homepage, can you honestly say things like Catalyst is as rapid out of the box as competing frameworks such as Dancer (which promotes the idea of having a basic working app in a single file, for better or worse, among other things). Additionally some things like the built in development server is no longer really a differentiating feature (particularly after the PSGI port was completed, bring the whole Catalyst::Engine thing full circle).

When looking at the recent Catalyst Poll, nearly everyone said they had no idea of the roadmap. This is terrible troubling, in particular since the people that did answer the poll are clearly involved and many of them have been part of the Catalyst community for five+ years.

Let’s take everyone’s favorite love it / hate it company, Apple. Apple is a great example to study since they are tremendously secretive regarding the product roadmap, yet in general people are not so surprised when thye bring out new stuff, and in general there product line is cohesive. l. That because its pretty much a no brainer to guess that whatever Apple does, they are going to focus on overall user experience over diversity of features, and that they are willing to sacrifice cutting edge technology when they can’t incorporate it without throwing off that targeted balance. We can also easily guess they are going to focus on a certain type of look and feel, and also focus on integrating how all the various things they sell work together.

Now, I’m not trying to start an argument regarding the de/merits of Apple products. And yeah, they seriously drop the ball as well (I’ve stopped using the new maps app in IOS6 after it sent me to locations that didn’t exist twice). What I am suggesting is that love or hate Apple, you have a pretty good idea of how their product roadmap will evolve over time, despite the fact that Apple goes very far out of the way to hide what they are doing.

So, for me, the question is can we develop a truthful product statement for Catalyst that similarly inspires and educates users, while helping guide a roadmap where Catalyst continues to be fresh and relevant to web application developers and a good citizen in the overall Perl software ecosystem.

I don’t have a sentence to offer but here’s a few things about Catalyst that feel to me to be core to what Catalyst is, and essential to what we hope it becomes over time. Maybe these thoughts can inspire some conversation?

Catalyst is the framework, but CPAN is the stack: Generally we prefer to work with the CPAN ecosystem, even at the cost of adding some complexity in our dependency chain. There is a downside here which I think is one reason I hear that Catalyst is a ‘heavy weight’ solution but it should be a core strength, and something that Catalyst should (at least in my mind) strive to be even more so. This is why I often say that Catalyst should strive to become nothing at all, or nothing beyond a thin layer of glue and conventions on top of the best and brightest CPAN has to offer. For example, many of the common plugins for authentication and sessioning could be ditched for their PSGI middleware equivalents.

Catalyst is just Perl: Each of the primary bits of Catalyst, such as controllers, models, etc are mostly just plain Perl classes, or Perl classes with a bit of subroutine attributes (which isn’t even required as you can just as easily stick that into configuration). Catalyst doesn’t try to define a domain specific language for creating url routes for example. So basically everything you know about writing good Perl code applies to writing good Catalyst applications.

That being said, again this is a place where “Catalyst could be more of itself”. People still think of Catalyst as a beast in its own world and we need to think of ways to make it more simple. Perhaps someday we’d have controllers that didn’t need to inherit from Catalyst::Controller, for example? Or we’d ditch the way we import plugins into your Catalyst main application class (we have a nice way to use Moosey conventions for this, no need for us to invent our own Catalyst only convention). Or like how Catalyst actions can chain, which is a great paradigm for re-use but since it doesn’t exist in other places in Perl syntax (unless you build your own chain of command pattern code) people sometimes find its alien brains...

Catalyst is MVC(ish...) MVC encourages clean separation of concerns, and in general my experience is that Catalyst applications scale better complexity wise than do other approaches. Again, this is a place we could do better, since there are times when you need to jump through hoops a bit to hook up your application they way you want.

I’m sure you can all think of some other things. Lets try to brainstorm a bit, together and see what we can come up with!

I’ll leave you with some thoughts about things that I don’t normally think of when I think of Catalyst, and I wonder if there’s something here we might want identified with the Catalyst product...

Meets the needs of programmers building modern, restful web services: Catalyst does have general support for building HTTP services, and the Catalyst REST tools have been around for a while, but I don’t personally find them as easy or correct as some other approaches. Perhaps this is a domain we mind wish to leave to something like Web::Machine, which focuses on doing that as well as possible...

Strong support for emerging web development practices like web sockets, long polling, asynchronous programming... Again perhaps this is a place better served by POE or AnyEvent, but it would be ideal if there were some good examples of this integration around.

Is easy to build up complex, Rich UI web applications: Again, maybe this isn’t something we are going to say is a core competency for Catalyst, but is worth thinking about since I am often asked about UI libraries, and all that stuff we currently lack.

I think once we can really get inspired by Catalyst’s core competencies, its ethos/ reason for being, that will naturally lead us to a roadmap that makes sense and is straightforward to communicate. The follow bit would be how we are going to manage such a project and get needed contributions, which alas is a topic for another post...

Comments

[Mamod Mehyar]

Thank you, this was a great read, I like Catalyst but at the same time I have the same thoughts you brought up.

For being heavy this totally depends on the project you are working on, if it's a big project then size of Catalyst doesn't matter but when you deal with small sized projects or a light web application then I think catalyst is not for the task, but again I really like the way Catalyst work and how it separate things for me, and since my work mostly deal with small applications I had to roll my own web framework module which resemble Catalyst to some point but as simple as Dancer.

I wish I had the choice of keep using Catalyst on all my projects since it's well engineered, mature and has a great community.

I'm with Catalyst being a thin layer or at least a thin layer port of it will be a great idea

[Alan]

Good thoughts. I'd add two more considerations:

1) What level of developer expertise is expected? Is Catalyst for beginning developers or for experts?

2) What kinds of websites/applications is Catalyst for?

In other words, who is the customer and what problem is he trying to solve?