[ckan-dev] Experimenting with a minimal CKAN

Thu Oct 1 17:01:24 UTC 2015

Hi Denis,

> On 1 Oct 2015, at 17:10, Denis Zgonjanin <deniszgonjanin at gmail.com> wrote:
> You've probably thought about this quite a bit Ross - would it be too much more work to have ckan-mini developed as a branch on CKAN itself? 

It was mostly the product of boredom and having a spare evening, but I've done some thinking about it yes.  I don't think any form of automated conversion from core to mini would be straightforward, so the biggest advantage would really be in it being easier to cherry-pick commits to core that are focused on the action layer.  I'm not *actually* expecting much use of ckan-mini, I just thought it was an interesting experiment.  I can push to a CKAN branch, but it might just make the repo messy. 

> It's unlikely that the work can be backwards compatible, but most orgs using CKAN like a clear migration path. And if we start ripping things out from CKAN with reckless abandon, an easy migration becomes impossible. That would slow adoption, and afterwards you'll also have hundreds of legacy CKAN instances around for years to come.

This is mostly true.  I think the original hope was that people would realise the advantage of having most of their functionality in the logic layer, but (and I am guilty of this too)  I don't think all the most used plugins take this approach. I've cut out the controllers, so there would be no UI for any of the extensions unless someone wrote one, so it's a big jump unless there was a commitment to provide UIs for those extensions that need it - and I would expect most to just see it as a extra cost.  

To counter-balance that, I suspect there are more people who are comfortable with Javascript and calling APIs than are comfortable installing and extending CKAN.  

I've possibly* been a little overzealous in ripping things out, I do love deleting, but I think there are some benefits:

1. There's a clearer definition of the functionality of CKAN, by knowing what the APIs expose (as we know that's what the UI used to provide).
2. It gives us the change to determine what's missing and what's surplus.
3. It gives any enterprising, time-rich, soul who wants to rebuild the front-end in something like, say, Flask a good starting point as it should now be a lot cleaner than trying to run side-by-side.  I'm more confident of moving mini to flask than I was of moving core. Of course, expect breakage.

> Another thing to think about is extensions. Nearly all would need major updates, and it's highly unlikely that would happen. A lot of the less popular ones would be left behind.

And many of the popular ones I expect. I think it would be quite nice to take the approach I proposed in https://github.com/ckan/ideas-and-roadmap/issues/65 and with more things than just QA (harvesting springs to mind too, and even possibly datastore). I'm not sure it would happen, or how it would be supported, but I think it would make things a lot easier to those maintaining and supporting a CKAN instance.  

> So really, what we're talking about is one of the possible alternatives for a CKAN 3.0 branch.

To be honest at this point I (personally) think CKAN 3.0 will look a lot like CKAN 2.5 - backward compatibility is clearly an overriding factor when discussing the future of CKAN.  I think it's pretty hard to call whether breaking things is worse than a potentially massive buildup of technical debt - or worse, having someone else come along and eat our lunch  Maybe CKAN is 'done', give or take a few major bugs, and the focus should be on extensions and external services - who knows?

What'd I'd *really* like to see if someone doing some market research and asking people what they need, how they use it, what the pain points are, what they'd like to see, what they depend heavily on (etc etc).  I think that would be beneficial to the community AND to companies building on CKAN.  I seem to recall a survey in the past, but I don't believe the results were made public - I'd love to be proven wrong though. I know there is the ideas repo, but I'm not sure everyone knows, or is comfortable with it.

Cheers

Ross.

* Definitely.