8 ms·
Has Django become a pay-for-features framework?
I happened to ask a question on IRC last night to see if it would be possible to improve runserver such that it was able to reload between code changes faster or swap in new code on the fly without reloading.
It got a response from Russell Keith-Magee and others who are very skilled with Python/Django.
Basically the general census was it's possible but it would be a ton of work. Russell immediately placed the blame on third party apps and shrugged off the feature request while others said a feature like this would take a lot of time and is a massive under taking.
To get migrations in 2014 with a future release of Django required the community to pony up $30,000 USD through kickstarter.
I'm really worried about Django's future because it seems like we won't get any new features in the framework in a reasonable amount of time unless the community pays them tens of thousands of dollars. Couple that with the 2 BDFLs leaving recently, then who is using Django in a project where they can extract/create features into the framework based on real needs rather than invented ones?
It really sounds like to me that none of the core devs even use Django, so it's up to the community to figure out useful features that people actually want but the community wants money because it takes up their time.
Thoughts? Would you pay real $ through kickstarter if runserver swapped new code in like rails so development wasn't a torturous experience?
- rbanffy 13y agoNo. I don't think the experience is that bad anyway. Django is Free Software. You get a corpus of software developed by an incredibly competent and generous group of people for free. These people solve their own problems and kindly donate their solutions for all to use. For free. If you have a problem that bothers you, you are free to solve it or to pay someone else to solve it for you. If it's a problem for too many people, it will, eventually, be solved by some generous person and you'll have your solution, again, for free. If it's your problem and only your problem, nobody else has any obligation whatsoever to solve it for you. BTW, nobody has any obligation to solve any problem with Django. It's done out of either love or necessity. We all have busy schedules. We all have families we love to spend time with. If I have to choose between spending time with my family and solving your problem, you'd better not hold your breath.
- antelopesalad 13y agoThat's kind of my point. If there's no love from the core devs to solve real problems that the community has then what are our choices? Having to throw up kick starters for every feature is unreasonable. Migrations were something that SO many people wanted and the core devs didn't even think to add it. It had to be merged in by a random person in the community for $30,000 and it also took 14 months assuming Django ships 1.7 in May going by their roadmap. That is 14 months and $30,000 to get a feature into the framework while already having a tested and battle hardened implementation as a third party module.
- rbanffy 13y ago> solve real problems that the community has Define "real". Like I told you, it doesn't bother me. > Migrations were something that SO many people wanted You are right - and we had South for it and we used it a lot. Integrating South into Django's core was not a trivial effort, however, but, again, since we already had South, it was not a big issue. > That is 14 months and $30,000 to get a feature into the framework while already having a tested and battle hardened implementation as a third party module. IIRC, the 30K were paid to the third party who created South to build a better migration engine it into Django. You can continue to use South for as long as you want. It's just that, starting with 1.7, you'll get migrations built in and South will no longer be required. I still fail to see why do you think everybody has to be concerned with the problems you find important. If it bothers you so much, then solve it. edit: corrected the character of the effort
- antelopesalad 13y agoYou seem to have a grudge against the world for some reason. Why are your posts so hostile? Do you not see the bigger picture? The runserver problem is only 1 thing. People are expecting to be fed tens of thousands of dollars through kickstarter to create features that people want instead of the core django devs implementing them. The reason why rails has an amazing development experience has nothing to do with rail's API or ruby. It's because rails is extracted and built out of a product that some of the core devs work with 24/7 (basecamp). They add useful things like a development server that isn't garbage because they work with it on a daily basis full time. I don't want to see Django fall over because they don't add any features that people actually want and instead force the community to beg for money on kick starter to do it.
- jasonlfunk 13y agopip install django-extensions ./manage.py runserver_plus 8080 Just saved your $30,000 ;)
- SEJeff 13y agoThe money for migrations was to employ the guy who wrote south to work on those migrations fulltime. It wasn't as much of a "community" thing as one guy who did it all. That wasn't the django "community" but a single django contributor. I think you've got things a bit mixed up here. Overall, the core of django sholud be small. The real good stuff is in the reusable apps. Besides, runserver isn't supposed to be for production. If you want things to run faster run it under a real wsgi server such as circus/chaussette, uwsgi, or gunicorn. That being said, I highly suggest looking into runserver_plus from: https://github.com/django-extensions/django-extensions https://github.com/django-extensions/django-extensions, it is really nice stuff.
- antelopesalad 13y agoThis has nothing to do with production mode. The development experience is unacceptable with runserver in development mode. I have a trivial app with half a dozen apps and it takes 5 seconds to reload runserver when I touch a view file. On the same hardware a ~6k SLOCs rails project with 40 gems reloads pretty much instantly because the rails dev server is smart enough to do code swapping. Edit: runserver_plus does nothing to make runserver reload faster, it is an improved stack trace with a built in debugger. Since I am already using django-extensions I tried runserver_plus and it added 2 full seconds to each reload. So now it takes 7 seconds just for runserver_plus to reload after touching a view.
- rbanffy 13y agoIf you consider the development experience to be unacceptable, then use something else.
- hexsprite 13y agoWhy don't you try using Python's profiling tools and file a bug report with what you find? That might get you a better response than asking on IRC.
- antelopesalad 13y agoI don't have the time to audit and analyze the entire django framework and every third party app I touch. I am only using a few apps too that are popular in the community. Realistically I'm a web app developer who wants to be productive. It's insane that I need to even consider doing that just to not have to wait 5 seconds for runserver to reload in development mode on a trivial app. It should be on the shoulders of the django core team to make sure their platform makes developers happy. P.S., if you want to give me $100,000 I will quit my job and spend the next half a decade learning advanced python, audit the entire django code. You would probably laugh and call me insane right, but this seems like what the django core devs are forcing us to do because they don't want to address the problems with the framework.
- gboone42 13y agoDevs clearly thought integrating South into Core was worth shelling out for, they could have sat on their hands after the project hit it's modest 2500 pound goal but, they didn't. Django, and all open source projects, benefit from the law of increasing returns. As more people contribute to it, with code, money, or simply by using it, the entire user base benefits. WordPress is a great example. I remember the days when WordPress was kind of wonky, but as it rose in usage and attracted more developers (and more of us started getting paid to contribute to the theme/plugin repos or Core), it quickly became stronger and oh so much more stable. There are tons of paid ("premium") plugins and themes out there now, and so many people paying for WP.com, but it's by no means a "pay for features" platform. With Django, paying Andrew Godwin to dedicate some of his time to integrate South into Core is definitely the kind of thing all of us will benefit from whether we contributed or not, as would runserver. At £2500 (his original goal) it's not like we're paying his salary. Even with the $30,000 he raised, it's not like he's living high on the hog ℅ the django community. If someone wants to field a kickstarter for £2500 to improve runserver and people want it as badly as people wanted South integrated, it'd probably be successful. That kind of voluntary patronage hardly makes it a pay-for-features platform.
- yen223 13y agoI, too, hate it when people ask to be paid for services rendered. You're supposed to be working for free, damn it!
- stormqloud 13y agoThere is a reason work is called work and not play!
- sergiotapia 13y agoIf you feel the direction is lacking in Django I would recommend switching to something like Rails or Laravel.
- antelopesalad 13y agoI'm already proficient in rails, it's why I'm so jaded by having an unbelievably good developer experience. I'm not talking about ruby or even the rails API/community/etc. either. It's just the problems that they address are the problems that matter for people who actually develop web applications full time because the core rails team develops basecamp full time and extracts rails features from their experiences. The django guys are simply not doing this. I can't put my finger on it exactly but Python calls to me like a siren. It's unfortunate that Django doesn't seem to want to address problems that people have, aren't addressing modern web development problems and are calling out to the community to raise money to introduce features to django's core. It took me like 3 weeks of hunting down random packages that add certain functionality, forking and fixing libs because the maintainers of those libs hate python 3 and won't support it just to get to the point where django was even usable as a development platform and now after all that I'm stuck having to waste 5 seconds of my life every time I touch a view or model. Then I have to wait 1.5 seconds for SASS to recompile between page reloads because the django-pipeline author (who is awesome btw) doesn't have the time to make pipeline cache the sass files and only recompile them when they change. It's one of the more anti-productive environments I've ever developed under and it's a pity because the django API is actually pretty good and I want to give it a chance.
- sergiotapia 13y agoI'm 100% agreeing with - I hope my comment wasn't taken as a snarky, "If you don't like it leave!". Take it as a "there are better alternatives, don't bother." :)
- deleted 13y ago[deleted]
- memracom 13y agoWhat you described is not a feature. Speed, or anything involving time, is an optimization, not a feature. Features are easy to add on to an application, but time, once lost, can never be regained. Optimization usually requires fundamentally changes to architecture, and in the case of Django it is well-known that it is not for building fast or highly scalable apps. Functional Reactive Programming is far better for building high performance apps. Specifically, you are asking about code swapping which is something that is only used by developers during development, not during production. Most developers deal with such problems by getting faster hardware. And finally, even if Django development stops today and it never gets any new features, it is still an ideal tool for building apps that are in its sweet spot. And it is easy to supplement with things like Celery or RabbitMQ to communicate with scalable non-Django backends. Nothing to fear here, move along.