Commit | Line | Data |
---|---|---|
8736b05d WKG |
1 | .. _design-decisions-chapter: |
2 | ||
3 | ================== | |
4 | Design Decisions | |
5 | ================== | |
6 | ||
6729d65a WKG |
7 | .. contents:: Sections |
8 | :local: | |
9 | ||
10 | ||
8736b05d WKG |
11 | This chapter talks a bit about design decisions. |
12 | ||
13 | ||
1b9e2541 WKG |
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 | ||
8736b05d WKG |
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 | |
cafc7451 WKG |
81 | Landscape`_). Me starting a project like this makes sense if it's |
82 | done in Python. | |
8736b05d WKG |
83 | |
84 | You might say that PHP is way more deployable, that Rails has way | |
cafc7451 | 85 | more cool developers riding around on fixie bikes---and all of |
8736b05d WKG |
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 | ||
109c87f8 CAW |
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? | |
8736b05d WKG |
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 | ||
109c87f8 | 148 | .. _Django: http://www.djangoproject.com/ |
8736b05d WKG |
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 | ||
00fdc7bd | 207 | I also don't want things to be too loose so that we forget or lose |
8736b05d WKG |
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 | |
00fdc7bd WKG |
211 | without adding too much bloat or overhead (MongoKit is a pretty |
212 | lightweight wrapper and doesn't inject extra MongoKit-specific | |
8736b05d WKG |
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 | ||
cafc7451 | 222 | `Sphinx`_ is a fantastic tool for organizing documentation for a |
8736b05d WKG |
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 | |
cafc7451 WKG |
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/ | |
fad67707 WKG |
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 | |
efb291d6 WKG |
251 | permissive in the same absolutely permissive way. We're waiving |
252 | our copyrights to non-software things under the CC0 waiver. | |
fad67707 WKG |
253 | |
254 | That brings us to the templates where there's some code and some | |
efb291d6 WKG |
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 | |
fad67707 WKG |
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 | |
efb291d6 WKG |
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. | |
fad67707 WKG |
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 | |
efb291d6 WKG |
278 | or worry about attribution concerns. Thus we're waiving our |
279 | copyrights to the documentation under CC0 as well. | |
fad67707 WKG |
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 | ||
efb291d6 | 292 | * software (Python, JavaScript, HTML templates): licensed |
fad67707 | 293 | under AGPLv3 |
efb291d6 WKG |
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 | |
fad67707 WKG |
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/ | |
6a338d8e WKG |
305 | |
306 | ||
2514dc02 CAW |
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 | |
3dca2776 | 327 | Webber. See :ref:`contributing-howto-chapter` for details. |
1b9e2541 WKG |
328 | |
329 |