“Ghost is a distributed non-profit foundation which gives away all of its intellectual property under a permissive MIT license. The company has no investors and, in fact, no owners of any kind. I don’t own any part of Ghost, and neither does my co-founder Hannah.

We currently generate around $7.5M in annual revenue, and have been profitable and sustainable for the past 12 years.

“Wait, what?”

I’m glad you asked.”

Django’s admin site is about 12 years old. It started circa early 2004 as an internal CMS at the Lawrence Journal-World, was released as part of Django in 2005, and has been chugging away ever since. There’s been some substantial re-writes along the way – magic-removal, new forms, the flat theme – but for the most part the admin’s stayed pretty much the same for that entire time. The interface, functionality, and CRUD-oriented workflow haven’t really changed since those early years at the Journal-World.

Getting new features into Django isn’t easy. It’s that way for a reason — I spoke recently about why conservatism is a virtue — but it does happen. I’d like to do a better job explaining how we decide what goes in and what goes out, so here’s a lightly adapted version of something I posted on the mailing list this evening. It’s three things I look for when I’m trying to determine whether something is “right” for Django or not:

Here’s a thought that’s been rummaging around in my brain for some time now: is there a market for commercial, closed-source Django apps?

Suppose someone released a high-quality, well-documented, well-supported Django app… under a commercial license. Assume of course that this app does something you actually need, and that the commercial license isn’t odious. Would you pay for a Django app?

I think I would. I have no qualms about paying for good software: in the last month I bought some backup software (Arq), started using a commercial ticket tracker (Pivotal) and time tracker (Freckle). In all cases, free/libre alternatives existed, but the paid versions were easier, slicker, faster, or in some sense “better.” Enough so that they justified their prices (to me). I think if Haystack (to pick an arbitrary example) was commercial (and reasonably priced) I’d pay for it — the time required to build an alternative would almost certainly cost me more.

man tar:

The GNU folks, in general, abhor man pages, and create info documents instead. Unfortunately, the info document describing tar is licensed under the GFDL with invariant cover texts, which makes it impossible to include any text from that document in this man page. Most of the text in this document was automatically extracted from the usage text in the source. It may not completely describe all features of the program.

Mark Shuttleworth:

Tribalism is when one group of people start to think people from another group are “wrong by default”. It’s the great-granddaddy of racism and sexism. And the most dangerous kind of tribalism is completely invisible: it has nothing to do with someone’s “birth tribe” and everything to do with their affiliations: where they work, which sports team they support, which linux distribution they love.

[…]

Let’s be clear: tribalism makes you stupid.

Guido van Rossum:

Maybe we’ve been too careful with only giving commit privileges to to experienced and trusted new developers. I spoke to Ezio Melotti and from his experience with getting commit privileges, it seems to be a case of “the lion is much more afraid of you than you are afraid of the lion”. I.e. having got privileges he was very concerned about doing something wrong, worried about the complexity of SVN, and so on. Since we’ve got lots of people watching the commit stream, I think that there really shouldn’t need to be a worry at all about a new committer doing something malicious, and there shouldn’t be much worry about honest beginners’ mistakes either – the main worry remains that new committers don’t use their privileges enough. So, my recommendation (which surely is a turn-around of my own attitude in the past) is to give out more commit privileges sooner.

Mike Malone emailed me an interesting question, which I thought I’d answer publicly:

[We’ve released code] under the BSD license. We want to accept patches from the community, but were wondering whether we need to get everyone who submits a patch to sign a release or something saying that their patch is BSD too. [Does Django] require everyone who submits a patch to sign that sort of release?

The Right Way is to require that all contributors sign a contributor license agreement (CLA). These differ from project to project, but generally say:

1. foo.py is a Python library released under the GPLv3. bar.py is a library distributed commercially. If bar contains import foo, must bar.py be released under the GPL?
2. Does the answer change if foo.py does not ship with bar.py, but nonetheless requires foo.py to function?
3. Does the answer change if foo.py does not ship with bar.py and does not require its presence to function?
4. libfoo.so is a C shared library released under the GPLv3. bar.rb is a Ruby library that uses Ruby/DL to call into libfoo (via dlopen() and friends). Must bar.rb be released under the GPL?
5. Does the above answer change depending on whether bar.rb is distributed with libfoo.so?
6. foo.js is a JavaScript library released under the GPLv3. bar.js is a library with all rights reserved. For performance reasons, I would like to minimize all my site’s JavaScript into a single compressed file called foobar.js. If I distribute this file, must I also distribute bar.js under the GPL?
7. foo.js is a JavaScript library released under the GPLv3. Bar.app is an application developed on the Mozilla platform using XUL. If Bar.app includes foo.js (via a <script> tag), must the source to Bar.app be released under the GPL?
8. Foo.exe is an application released under the GPLv3. Initech’s HR department modifies Foo.exe for use internally. If Initech shares this application with the Accounts Receivable department, does that count as “conveyance” and require release of the modifications under the GPL?
9. IniSys is a fully-owned subsidiary of Initech. If Initech shares its modified version of Foo.exe with IniSys, does that trigger the GPL’s conveyance clause?
10. IniCom is a majority-owned subsidiary of Initech. If Initech shares Foo.exe with IniCom, does that trigger the GPL’s conveyance clause?
11. Do either of the above answers change if IniSys or IniCom pay IniTech for the right to use (the modified version of) Foo.exe?
12. Jane is a consultant hired by Initech. If Jane wishes to purchase Foo.exe from Initech for use in her consultancy, does that act trigger the GPL’s conveyance clause?
13. Jane is a consultant hired by Initech. If Initech provides Foo.exe to Jane for code review, does that trigger the GPL’s conveyance clause? Does the mechanism that Initech uses to provide Jane the code change the answer?
14. As a standard practice, Initech requires that all consultants working with them use the modified version of Foo.exe. Does this trigger the GPL’s conveyance clause?
15. To apply for a job at Initech, potential employees must visit an Initech recruitment center and complete an job application using Foo.exe. They do this on computers provided by Initech. Does this trigger the GPL’s conveyance clause?
16. Initech now decides to make Foo.exe available to job applicants who wish to use their own computers, provided they visit a recruitment center and are within Initech’s private network to download Foo.exe. Does this trigger the GPL’s conveyance clause?
17. Initech now decides that any job applicant may download Foo.exe from any network connection via a VPN connection to Initech’s internal private network. Does this trigger the GPL’s conveyance clause?
18. Initech finally decides to simply let any applicant download Foo.exe from a public web server. Does this trigger the GPL’s conveyance clause?
19. This publically-available download of Foo.exe requires a password only available by calling Initech HR. Does this form count as conveyance?
20. The previous six questions are all variations on a theme. Is there a basic principle than enables them (and the other countless variations) to be answered quickly by laypeople?

Bonus question:

Lately a large number of questions posted to django-users have included phrases like “this is a show-stopper” or “this is critical”. I think it’s worth my time to point out that this is a lousy method of getting developers to do what you want. It’s the online equivalent of threatening to take your ball and go home, and is about as effective.

I understand the impulse perfectly: there’s the fear that we won’t take you seriously if you don’t tell us just how important this is.