[ckan-dev] Future, flask, breaking things, funding.

Tue Sep 15 09:23:50 UTC 2015

I should probably clarify something with regard to the purpose of the CKAN
Association (as I understand it and therefore operate within it, at least).
My view is that the main job of the Association is to support the
'community'. In large part this should really be the tech team and the
extended community of contributors to the project. It isn't an Association
that would dictate any roadmap direction, but through extension only in the
support of the project/community it might work hard to do things which
advance the consensus and actual word on on the roadmap.

How this would manifest, I think, might change over time but in a more
mature situation some time in the future it could be two main activities:

   1. Maintain ckan.org
   2. Organise and facilitate CKANcons

This would pretty much put it on par with the mission of similar
Associations, such as the Drupal Association.

So... those members who pay would help fund things like hosting and
maintenance of ckan.org. The association might end up hiring, down the
track, someone to do blog posts and social media; especially in overlap
activities around CKANcons, etc. With regard to CKANcon, positions could
exist to ramp these up and get them to the 'enterprise community' status
that people would appreciate.  All of this might require a position such as
an executive officer to run the admin of the association. Again, all of
this is some time down the track (maybe soon if the user adoption keeps
ramping up).

When it comes to the sort of funding opportunities that are out there in
the wild, there are organisations that are for profit, not for profit, or
some combination of both. It would be these organisations that could best
bid for grants to achieve great works that both advance the roadmap AND
support high value outcomes for the funding partners.

In my position I straddle roles in Open Knowledge Australia, CKAN
Association, Link Digital, GovHack and the Australian Government Linked
Data Working Group. I need to be very careful to disclose conflicts where
they emerge and honestly wear the right hat in each discussion. So, with
that said...

   1. I'm trying to recruit members into CKAN Association to mature its
   ability to support the CKAN community.
   2. I'm certainly trying to win various CKAN related projects for Link
   Digital and would love to get paid appointments to work on the CKAN roadmap.
   3. Within Australia, via Open Knowledge, I'm also trying to mature the
   organisation and help it to gain funding for great works. In this space I
   also need to be careful to disclose any potential conflicts.

I'm keen to not attract funding into the association that is earmarked for
any member organisation because that would certainly put me in a conflicted
position. Getting funding for staff within the Association would help, but
if in-kind support is offered then it is silly to reject it :) I should
point out that the CKAN Association is currently still housed within Open
Knowledge as an entity, so it is much easier for OKFN globally to pitch for
funding that goes into staff via OKRN Services to support CKAN's roadmap.
However, as per some of the presentations I've given this is identified as
both a strength and a risk to the project. The community should be strong
enough in its own regard without needing dedicated staff from Open
Knowledge Services to keep things moving.

Recent activity to have David Read do the 2.4 package and release with
Adria in support, is one of the ways we are trying to help the community
outside OKFN take on more responsibility. My suggestion to divert support
issues to stack overflow comes from this position too. It takes some
pressure off core contributors that might currently be otherwise employed
on paid engagements for their respective organisation.

Re this: https://github.com/ckan/ideas-and-roadmap/issues/152

I'm painfully aware of the fact I'm building a business on top of a project
with technical debt to clear out. Whatever hat I'm wearing my interests are
aligned on trying to find any way to fund that work. A paid for-profit
project, a grant, a team of contributors working on 3.0 - any approach we
can use is good for me :)

Hoots!

*STEVEN DE COSTA *|
*EXECUTIVE DIRECTOR*www.linkdigital.com.au

On 15 September 2015 at 16:54, Ross Jones <ross at servercode.co.uk> wrote:

> Hi Steven,
>
> > On 14 Sep 2015, at 22:11, Steven De Costa <
> steven.decosta at linkdigital.com.au> wrote:
> >
> > 1. Perhaps redev could be bottom up. Start with resources and widen its
> ability. Crud can then be rebuilt over the top.
> > 2. Carefully consider the longest term possible and how the app may
> mature in the future.
> > 3. Consider interoperability between n+1 platforms via linked open data,
> again with realtime in mind
> > 4. Consider packages further. Could we add new package types that are
> built on 3.0 thinking and have them co exist with current packages? If so
> then existing extensions could be modified less dramatically to apply only
> to v2 packages.
>
> I think this is one of the key points, how much change can we make without
> breaking the ecosystem of extensions that people have worked on, are in use
> etc.  It'll be quite hard to break the model in any significant way because
> we've no idea who the extensions use that model.  There is already some
> guaranteed breakage because there are things that extensions authors tend
> to import directly that may not be there in v3 (pylons.config being the
> first thing that comes to mind).
>
> > 5. Think about migration scenarios. Could a v2 CKAN remain as a dumb web
> app harvesting from a 3.0? If so, we could priorities workflows around
> custodians and ETL before end users.
>
> I think a v3 CKAN would have to support the action API, so harvesting
> should/could still work as it does today. And including machines as users
> in a user-needs type approach to v3 would be very welcome.  Some components
> in various repos have user-stories written, but I don't think these exist
> for CKAN itself.  It would be awesome to get more of these from outside -
> As a machine, I want ..., so that ....
>
> > 6. Yes I'm sure others in the steering group would support the work.
> Just remember they are also just volunteers :)
>
> I do - and thank you for volunteering and engaging so frequently (on here
> and on twitter and elsewhere). It really is appreciated!
>
> > 7. Yes I'm sure funding could come from the Association, just so long as
> funding first goes into the association. So, we'd all have a part to play
> in signing up paying members - happy to take any leads from people on that
> point :)
>
> It's unfortunate that the Assoc doesn't have access to funds, obviously
> donating resources is very valuable but I'm not sure that will scale enough
> - everyone who is 'donated' to CKAN also has other things that are also
> priorities :( I'm not particularly clued-in as to the story with grants and
> applications for them, but if there's some other useful way I could help, I
> will.  I seem to recall the original plan was for some people to be
> actually employed by the association - is this no longer the plan?
>
> Even if v3 is only the same as the jump from 1.x to 2.x (which would be
> fine, OKF invested a huge amount in that work and it was definitely worth
> it) - we still need to find a way to do
> https://github.com/ckan/ideas-and-roadmap/issues/152
>
> Would also love to see the use-cases doc you mentioned in another email,
> it'll probably serve as a good starting point for finding user-needs and
> from there, user stories.
>
> Cheers
>
> Ross
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20150915/4af30d5f/attachment-0003.html>