| 1 | .. _design-decisions-chapter: |
| 2 | |
| 3 | ================== |
| 4 | Design Decisions |
| 5 | ================== |
| 6 | |
| 7 | .. contents:: Sections |
| 8 | :local: |
| 9 | |
| 10 | |
| 11 | This chapter talks a bit about design decisions. |
| 12 | |
| 13 | |
| 14 | Why GNU MediaGoblin? |
| 15 | ==================== |
| 16 | |
| 17 | Chris and Will on "Why GNU MediaGoblin": |
| 18 | |
| 19 | Chris came up with the name MediaGoblin. The name is pretty fun. |
| 20 | It merges the idea that this is a Media hosting project with |
| 21 | Goblin which sort of sounds like gobbling. Here's a piece of |
| 22 | software that gobbles up your media for all to see. |
| 23 | |
| 24 | `According to Wikipedia <http://en.wikipedia.org/wiki/Goblin>`_, a |
| 25 | goblin is: |
| 26 | |
| 27 | a legendary evil or mischievous illiterate creature, described |
| 28 | as grotesquely evil or evil-like phantom |
| 29 | |
| 30 | So are we evil? No. Are we mischievous or illiterate? Not |
| 31 | really. So what kind of goblin are we thinking about? We're |
| 32 | thinking about these goblins: |
| 33 | |
| 34 | .. figure:: goblin.png |
| 35 | :alt: Cute goblin with a beret. |
| 36 | |
| 37 | *Figure 1: Cute goblin with a beret. llustrated by Chris |
| 38 | Webber* |
| 39 | |
| 40 | .. figure:: snugglygoblin.png |
| 41 | :scale: 50% |
| 42 | :alt: Snuggly goblin with a beret. |
| 43 | |
| 44 | *Figure 2: Snuggly goblin. Illustrated by Karen Rustad* |
| 45 | |
| 46 | Those are pretty cute goblins. Those are the kinds of goblins |
| 47 | we're thinking about. |
| 48 | |
| 49 | Chris started doing work on the project after thinking about it |
| 50 | for a year. Then, after talking with Matt and Rob, it became an |
| 51 | official GNU project. Thus we now call it GNU MediaGoblin. |
| 52 | |
| 53 | That's a lot of letters, though, so in the interest of brevity and |
| 54 | facilitating easier casual conversation and balancing that with |
| 55 | what's important to us, we have the following rules: |
| 56 | |
| 57 | 1. "GNU MediaGoblin" is the name we're going to use in all official |
| 58 | capacities: web site, documentation, press releases, ... |
| 59 | |
| 60 | 2. In casual conversation, it's ok to use more casual names. |
| 61 | |
| 62 | 3. If you're writing about the project, we ask that you call it GNU |
| 63 | MediaGoblin. |
| 64 | |
| 65 | 4. If you don't like the name, we kindly ask you to take a deep |
| 66 | breath, think a happy thought about cute little goblins playing |
| 67 | on a playground and taking cute pictures of themselves, and let |
| 68 | it go. (Will added this one.) |
| 69 | |
| 70 | |
| 71 | Why Python |
| 72 | ========== |
| 73 | |
| 74 | Chris Webber on "Why Python": |
| 75 | |
| 76 | Because I know Python, love Python, am capable of actually making |
| 77 | this thing happen in Python (I've worked on a lot of large free |
| 78 | software web applications before in Python, including `Miro |
| 79 | Community`_, the `Miro Guide`_, a large portion of `Creative |
| 80 | Commons`_, and a whole bunch of things while working at `Imaginary |
| 81 | Landscape`_). Me starting a project like this makes sense if it's |
| 82 | done in Python. |
| 83 | |
| 84 | You might say that PHP is way more deployable, that Rails has way |
| 85 | more cool developers riding around on fixie bikes---and all of |
| 86 | those things are true. But I know Python, like Python, and think |
| 87 | that Python is pretty great. I do think that deployment in Python |
| 88 | is not as good as with PHP, but I think the days of shared hosting |
| 89 | are (thankfully) coming to an end, and will probably be replaced |
| 90 | by cheap virtual machines spun up on the fly for people who want |
| 91 | that sort of stuff, and Python will be a huge part of that future, |
| 92 | maybe even more than PHP will. The deployment tools are getting |
| 93 | better. Maybe we can use something like Silver Lining. Maybe we |
| 94 | can just distribute as ``.debs`` or ``.rpms``. We'll figure it |
| 95 | out when we get there. |
| 96 | |
| 97 | Regardless, if I'm starting this project, which I am, it's gonna |
| 98 | be in Python. |
| 99 | |
| 100 | .. _Miro Community: http://mirocommunity.org/ |
| 101 | .. _Miro Guide: http://miroguide.org/ |
| 102 | .. _Creative Commons: http://creativecommons.org/ |
| 103 | .. _Imaginary Landscape: http://www.imagescape.com/ |
| 104 | |
| 105 | |
| 106 | Why WSGI Minimalism |
| 107 | =================== |
| 108 | |
| 109 | Chris Webber on "Why WSGI Minimalism": |
| 110 | |
| 111 | If you notice in the technology list I list a lot of components |
| 112 | that are very "django-like", but not actually `Django`_ |
| 113 | components. What can I say, I really like a lot of the ideas in |
| 114 | Django! Which leads to the question: why not just use Django? |
| 115 | |
| 116 | While I really like Django's ideas and a lot of its components, I |
| 117 | also feel that most of the best ideas in Django I want have been |
| 118 | implemented as good or even better outside of Django. I could |
| 119 | just use Django and replace the templating system with Jinja2, and |
| 120 | the form system with wtforms, and the database with MongoDB and |
| 121 | MongoKit, but at that point, how much of Django is really left? |
| 122 | |
| 123 | I also am sometimes saddened and irritated by how coupled all of |
| 124 | Django's components are. Loosely coupled yes, but still coupled. |
| 125 | WSGI has done a good job of providing a base layer for running |
| 126 | applications on and if you know how to do it yourself [1]_, it's |
| 127 | not hard or many lines of code at all to bind them together |
| 128 | without any framework at all (not even say `Pylons`_, `Pyramid`_ |
| 129 | or `Flask`_ which I think are still great projects, especially for |
| 130 | people who want this sort of thing but have no idea how to get |
| 131 | started). And even at this already really early stage of writing |
| 132 | MediaGoblin, that glue work is mostly done. |
| 133 | |
| 134 | Not to say I don't think Django isn't great for a lot of things. |
| 135 | For a lot of stuff, it's still the best, but not for MediaGoblin, |
| 136 | I think. |
| 137 | |
| 138 | One thing that Django does super well though is documentation. It |
| 139 | still has some faults, but even with those considered I can hardly |
| 140 | think of any other project in Python that has as nice of |
| 141 | documentation as Django. It may be worth learning some lessons on |
| 142 | documentation from Django [2]_, on that note. |
| 143 | |
| 144 | I'd really like to have a good, thorough hacking-howto and |
| 145 | deployment-howto, especially in the former making some notes on |
| 146 | how to make it easier for Django hackers to get started. |
| 147 | |
| 148 | .. _Django: http://www.djangoproject.com/ |
| 149 | .. _Pylons: http://pylonshq.com/ |
| 150 | .. _Pyramid: http://docs.pylonsproject.org/projects/pyramid/dev/ |
| 151 | .. _Flask: http://flask.pocoo.org/ |
| 152 | |
| 153 | .. [1] http://pythonpaste.org/webob/do-it-yourself.html |
| 154 | .. [2] http://pycon.blip.tv/file/4881071/ |
| 155 | |
| 156 | |
| 157 | Why MongoDB |
| 158 | =========== |
| 159 | |
| 160 | Chris Webber on "Why MongoDB": |
| 161 | |
| 162 | In case you were wondering, I am not a NOSQL fanboy, I do not go |
| 163 | around telling people that MongoDB is web scale. Actually my |
| 164 | choice for MongoDB isn't scalability, though scaling up really |
| 165 | nicely is a pretty good feature and sets us up well in case large |
| 166 | volume sites eventually do use MediaGoblin. But there's another |
| 167 | side of scalability, and that's scaling down, which is important |
| 168 | for federation, maybe even more important than scaling up in an |
| 169 | ideal universe where everyone ran servers out of their own |
| 170 | housing. As a memory-mapped database, MongoDB is pretty hungry, |
| 171 | so actually I spent a lot of time debating whether the inability |
| 172 | to scale down as nicely as something like SQL has with sqlite |
| 173 | meant that it was out. |
| 174 | |
| 175 | But I decided in the end that I really want MongoDB, not for |
| 176 | scalability, but for flexibility. Schema evolution pains in SQL |
| 177 | are almost enough reason for me to want MongoDB, but not quite. |
| 178 | The real reason is because I want the ability to eventually handle |
| 179 | multiple media types through MediaGoblin, and also allow for |
| 180 | plugins, without the rigidity of tables making that difficult. In |
| 181 | other words, something like:: |
| 182 | |
| 183 | {"title": "Me talking until you are bored", |
| 184 | "description": "blah blah blah", |
| 185 | "media_type": "audio", |
| 186 | "media_data": { |
| 187 | "length": "2:30", |
| 188 | "codec": "OGG Vorbis"}, |
| 189 | "plugin_data": { |
| 190 | "licensing": { |
| 191 | "license": "http://creativecommons.org/licenses/by-sa/3.0/"}}} |
| 192 | |
| 193 | |
| 194 | Being able to just dump media-specific information in a media_data |
| 195 | hashtable is pretty great, and even better is having a plugin |
| 196 | system where you can just let plugins have their own entire |
| 197 | key-value space cleanly inside the document that doesn't interfere |
| 198 | with anyone else's stuff. If we were to let plugins to deposit |
| 199 | their own information inside the database, either we'd let plugins |
| 200 | create their own tables which makes SQL migrations even harder |
| 201 | than they already are, or we'd probably end up creating a table |
| 202 | with a column for key, a column for value, and a column for type |
| 203 | in one huge table called "plugin_data" or something similar. (Yo |
| 204 | dawg, I heard you liked plugins, so I put a database in your |
| 205 | database so you can query while you query.) Gross. |
| 206 | |
| 207 | I also don't want things to be too loose so that we forget or lose |
| 208 | the structure of things, and that's one reason why I want to use |
| 209 | MongoKit, because we can cleanly define a much structure as we |
| 210 | want and verify that documents match that structure generally |
| 211 | without adding too much bloat or overhead (MongoKit is a pretty |
| 212 | lightweight wrapper and doesn't inject extra MongoKit-specific |
| 213 | stuff into the database, which is nice and nicer than many other |
| 214 | ORMs in that way). |
| 215 | |
| 216 | |
| 217 | Why Sphinx for documentation |
| 218 | ============================ |
| 219 | |
| 220 | Will Kahn-Greene on "Why Sphinx": |
| 221 | |
| 222 | `Sphinx`_ is a fantastic tool for organizing documentation for a |
| 223 | Python-based project that makes it pretty easy to write docs that |
| 224 | are readable in source form and can be "compiled" into HTML, LaTeX |
| 225 | and other formats. |
| 226 | |
| 227 | There are other doc systems out there, but given that GNU |
| 228 | MediaGoblin is being written in Python and I've done a ton of |
| 229 | documentation using Sphinx, it makes sense to use Sphinx for now. |
| 230 | |
| 231 | .. _Sphinx: http://sphinx.pocoo.org/ |
| 232 | |
| 233 | |
| 234 | Why AGPLv3 and CC0? |
| 235 | =================== |
| 236 | |
| 237 | Chris, Brett, Will, Rob, Matt, et al curated into a story where |
| 238 | everyone is the hero by Will on "Why AGPLv3 and CC0": |
| 239 | |
| 240 | The `AGPL v3`_ preserves the freedoms guaranteed by the GPL v3 in |
| 241 | the context of software as a service. Using this license ensures |
| 242 | that users of the service have the ability to examine the source, |
| 243 | deploy their own instance, and implement their own version. This |
| 244 | is really important to us and a core mission component of this |
| 245 | project. Thus we decided that the software parts should be under |
| 246 | this license. |
| 247 | |
| 248 | However, the project is made up of more than just software: |
| 249 | there's CSS, images, and other output-related things. We wanted |
| 250 | the templates/images/css side of the project all permissive and |
| 251 | permissive in the same absolutely permissive way. We're waiving |
| 252 | our copyrights to non-software things under the CC0 waiver. |
| 253 | |
| 254 | That brings us to the templates where there's some code and some |
| 255 | output. The template engine we're using is called Jinja2. It |
| 256 | mixes HTML markup with Python code to render the output of the |
| 257 | software. We decided the templates are part of the output of the |
| 258 | software and not the software itself. We wanted the output of the |
| 259 | software to be licensed in a hassle-free way so that when someone |
| 260 | deploys their own GNU MediaGoblin instance with their own |
| 261 | templates, they don't have to deal with the copyleft aspects of |
| 262 | the AGPLv3 and we'd be fine with that because the changes they're |
| 263 | making are identity-related. So at first we decided to waive our |
| 264 | copyrights to the templates with a CC0 waiver and then add an |
| 265 | exception to the AGPLv3 for the software such that the templates |
| 266 | can make calls into the software and yet be a separately licensed |
| 267 | work. However, Brett brought up the question of whether this |
| 268 | allows some unscrupulous person to make changes to the software |
| 269 | through the templates in such a way that they're not bound by the |
| 270 | AGPLv3: i.e. a loophole. We thought about this loophole and |
| 271 | between this and the extra legalese involved in the exception to |
| 272 | the AGPLv3, we decided that it's just way simpler if the templates |
| 273 | were also licensed under the AGPLv3. |
| 274 | |
| 275 | Then we have the licensing for the documentation. Given that the |
| 276 | documentation is tied to the software content-wise, we don't feel |
| 277 | like we have to worry about ensuring freedom of the documentation |
| 278 | or worry about attribution concerns. Thus we're waiving our |
| 279 | copyrights to the documentation under CC0 as well. |
| 280 | |
| 281 | Lastly, we have branding. This covers logos and other things that |
| 282 | are distinctive to GNU MediaGoblin that we feel represents this |
| 283 | project. Since we don't currently have any branding, this is an |
| 284 | open issue, but we're thinking we'll go with a CC BY-SA license. |
| 285 | |
| 286 | By licensing in this way, we make sure that users of the software |
| 287 | receive the freedoms that the AGPLv3 ensures regardless of what |
| 288 | fate befalls this project. |
| 289 | |
| 290 | So to summarize: |
| 291 | |
| 292 | * software (Python, JavaScript, HTML templates): licensed |
| 293 | under AGPLv3 |
| 294 | * non-software things (CSS, images, video): copyrights waived |
| 295 | under CC0 because this is output of the software |
| 296 | * documentation: copyrights waived under CC0 because it's not part |
| 297 | of the software |
| 298 | * branding assets: we're kicking this can down the road, but |
| 299 | probably CC BY-SA |
| 300 | |
| 301 | This is all codified in the ``COPYING`` file. |
| 302 | |
| 303 | .. _AGPL v3: http://www.gnu.org/licenses/agpl.html |
| 304 | .. _CC0 v1: http://creativecommons.org/publicdomain/zero/1.0/ |
| 305 | |
| 306 | |
| 307 | Why (non-mandatory) copyright assignment? |
| 308 | ========================================= |
| 309 | |
| 310 | Chris Webber on "Why copyright assignment?": |
| 311 | |
| 312 | GNU MediaGoblin is a GNU project with non-mandatory but heavily |
| 313 | encouraged copyright assignment to the FSF. Most, if not all, of |
| 314 | the core contributors to GNU MediaGoblin will have done a |
| 315 | copyright assignment, but unlike some other GNU projects, it isn't |
| 316 | required here. We think this is the best choice for GNU |
| 317 | MediaGoblin: it ensures that the Free Software Foundation may |
| 318 | protect the software by enforcing the AGPL if the FSF sees fit, |
| 319 | but it also means that we can immediately merge in changes from a |
| 320 | new contributor. It also means that some significant non-FSF |
| 321 | contributors might also be able to enforce the AGPL if seen fit. |
| 322 | |
| 323 | Again, assignment is not mandatory, but it is heavily encouraged, |
| 324 | even incentivized: significant contributors who do a copyright |
| 325 | assignment to the FSF are eligible to have a unique goblin drawing |
| 326 | produced for them by the project's main founder, Christopher Allan |
| 327 | Webber. See :ref:`contributing-howto-chapter` for details. |
| 328 | |
| 329 | |