[ckan-dev] Forking culture (was Re: Running ckan on heroku)

Fri Dec 13 11:17:25 UTC 2019

Hi,

> Forking this conversation ;-)

Moving this important conversation to the new mailing list
(ckan-dev at ckan.org) as the one where it started
(ckan-dev at lists.okfn.org) is shutting down next week.

I agree that forking is a common practice in the CKAN ecosystem and
one that we should work towards avoiding.

In my experience forks happen for various reasons. I've found several
teams over the years, perhaps coming from a background less familiar
with open source, that saw forking as something natural to be done at
the start of a project. We could dedicate a prominent section in the
docs to describe the benefits of following upstream versions, extend
via extensions and contribute back relevant changes.

To the question of whethere there is a lack of maintainers and owners,
the answer is yes and as always I'll take the opportunity to remind
that if anyone uses an extension regularly, they might want to
consider helping out maintaining it. Having your PR sitting awaiting
revision for a long time might well be a reason (or a requirement) to
decide to maintain a fork. Reaching out to the community to help out
maintaing extensions could be a part of the answer to this.

Finally there are legitimate reasons for forking an extension if you
think your customizations are going to be really specific and it's not
feasible to implement them separately.

CKAN core forks are an entirely different matter and I would strongly
advise agaisnt it unless there are very good reasons. It is very
likely that if you need something changed in CKAN core it either 1)
can be done in an extension or 2) should be done in an extension, so
some functionality needs to be exposed. Yes, that means changing CKAN
core which is a slow process but eventually you'll be able to get back
to follow upstream and stop using a fork. Relying on a fork is a
committment to rely on your own CKAN code base and inevitably you will
find difficult to keep up with the upstream version. Data.gov is
perhaps one extreme example just because of the size of it. At the
time the initial version was being developed and given the project
constraints it was just impossible to rely on upstream CKAN alone and
a fork was created. For whatever reasons during the following years
development was done on the fork rather than trying to align again
with upstream so I guess that the problem amplified itself over time.

Would love to hear more from others in the tech team and the community
about how to address this.

Adrià

Over time there wasn't an effort to bring back the project to upstream
and I imagine that

On Tue, 3 Dec 2019 at 19:37, Aaron D Borden <aaron.borden at gsa.gov> wrote:
>
> Hey folks,
>
>> Ah I just clicked you're probably referring to CKAN needing to use the variable names heroku defines automatically for dynamic-ish connection strings - the easiest is probably a custom plugin, e.g. to fork ckanext-envvar for that.
>
>
> Forking this conversation ;-)
>
> I'm a python developer working in open source for a decade but have only been with CKAN for a year, mostly working on the fringes. Is there a reason that forking is so pervasive in the CKAN community?
>
> It seems to be a common "solution" on this mailing list, but forking causes all kinds of problems and inefficiencies. I'm used to folks pushing changes back upstream instead of creating forks.
>
> Data.gov is one giant fork and has caused a lot of wasted time and effort for us and a lot of missed opportunities for CKAN. Instead of solving problems for CKAN, we're solving the same or similar problems again for Data.gov.
>
> Is there a historical reason why there are so many forks? Do we have a lack of owners and maintainers?
>
>
> --
> Aaron D Borden
> Lead Engineer | IT Specialist
> TTS | Data.gov
> _______________________________________________
> 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