←back to thread

310 points brylie | 2 comments | | HN request time: 0s | source
Show context
danpalmer ◴[] No.43512772[source]
> Plain is a fork of Django

Why. This makes me sad. Plain looks great, but Django's strength is its maturity and amazing, enduring community built on contributions from thousands. Forking it will at best split contributions and mean infrequent merges, and at worst means Plain users lose out on Django improvements and Django users lose out on Plain patches.

It seems like Plain could be just a set of Django packages known to work together, and perhaps a new wrapper script replacing `django-admin`, but instead it appears it is a true fork.

Plain basically looks great. I love Django, and this is a long list of things that I'd need on top of Django anyway. Would I use a framework on top of a framework like this? I'm not sure. I just wish it was built in a way that contributed to the Django community instead of one that divides it.

replies(12): >>43512813 #>>43512854 #>>43512920 #>>43513037 #>>43513063 #>>43513104 #>>43513224 #>>43513342 #>>43513446 #>>43514468 #>>43516716 #>>43516766 #
airstrike ◴[] No.43512854[source]
The author actually addresses all of those points in the about page https://plainframework.com/about/
replies(3): >>43512938 #>>43512943 #>>43513955 #
danpalmer ◴[] No.43512943[source]
The author discusses these points in the about page, but for me, does not sufficiently address them.

My experience of contributing to Django does not match theirs, and I don't feel this page sufficiently justifies this being a fork. In fact it actually makes me suspect that Plain will/has diverged enough that it won't be able to pull in changes from Django. As a user this would concern me, as Django ships meaningful changes regularly, as well as having a mature approach to security disclosures.

I have disclosed vulnerabilities in Django and they were handled very well and quickly. I actually went to see if Plain was vulnerable to the issue I disclosed, but my issue was around the memcached integration, and it seems Plain has completely removed all caching (except from a database-backed cache), making it in one way less batteries-included than regular Django. This puzzles me, for a project that is all about including more batteries, and as a potential user would lead me to further question the project.

replies(1): >>43513411 #
1. boxed ◴[] No.43513411[source]
Upstreaming to Django becomes very hard because he's moved stuff around. Also, switching to plain just to try it out becomes super hard because of this same thing. The idea of having a faster moving fork makes sense, but this isn't it.
replies(1): >>43513463 #
2. danpalmer ◴[] No.43513463[source]
Agreed. The about page also says that the plan is to update Plain to include new Django changes, but that would also be hard.

Django has a "contrib" package. I could see a fork with a fast moving contrib directory, or even just the Django project doing that with an explicit call-out for that package having a different set of breaking change expectations. A bunch of features started in contrib and graduated out of it over time, would be nice to keep that going.