Things your Mother Didn't Teach you about Sharing your Toys
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 12 | |
| Number of Parts | 52 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/32724 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DjangoCon US 201612 / 52
6
10
13
14
17
20
23
31
36
44
46
47
48
49
00:00
Disk read-and-write headFlagSheaf (mathematics)Graph coloringComputer animation
00:29
Projective planeMultiplication signGenderOpen sourceCore dumpForcing (mathematics)Combinational logicData miningInheritance (object-oriented programming)NumberPredictabilityAxiom of choiceBuildingShared memoryUser interfaceWeb pageCondition numberSingle-precision floating-point formatAndroid (robot)Library (computing)Web applicationSoftware maintenanceoutputComputer animationLecture/Conference
02:07
SoftwareCondition numberProjective planeSurfaceGender
02:40
FlagExpected valueHacker (term)CodeProjective planeContent (media)WritingCategory of beingPoint (geometry)Right angleStatement (computer science)Computer fileOpen sourceRootLine (geometry)VideoconferencingDifferent (Kate Ryan album)Core dumpWordMereologyForm (programming)SoftwareNumberSingle-precision floating-point formatExclusive orDefault (computer science)Huffman codingPublic domainPublic key certificateProof theoryPatch (Unix)Constraint (mathematics)Limit (category theory)Physical lawSoftware developerQuicksortExistenceMessage passingMultiplication signDistribution (mathematics)Email1 (number)AreaHeat transferComputer configurationPhysicalismTheoryResultantEntire functionSound effectWebsiteDirection (geometry)Open setSign (mathematics)Observational studyDesign by contractPlastikkarteGame theoryKernel (computing)GenderVideo gameTerm (mathematics)Computer animation
10:32
Right anglePublic domainCodeMereologyOpen sourceRun-time systemCloud computingSoftwareMetropolitan area networkHeat transferPrice indexRepository (publishing)Stack (abstract data type)Radical (chemistry)Physical lawTerm (mathematics)Buffer overflowPlastikkarteMultiplicationCondition numberDifferent (Kate Ryan album)Order (biology)Set (mathematics)Directory serviceRootProduct (business)GenderInteractive televisionNormal (geometry)Projective planeComputer configurationCartesian coordinate systemWordImage registrationWeightAxiom of choiceImplementationInheritance (object-oriented programming)Self-organizationMixed realityAdventure gameChainMultiplication signService (economics)Local ringMilitary baseProcess (computing)Combinational logicGraph coloringGenetic programmingFlow separationGoodness of fitVapor barrierState of matterLogical constantDecision tree learningOnline helpData storage deviceWritingShared memoryEntire functionWebsiteMoving averageComputer fileSound effectAuthorizationDefault (computer science)Basis <Mathematik>Complex (psychology)Electronic signatureAreaComputer animation
18:23
AnalogyGoodness of fitMultiplication signInterpreter (computing)Branch (computer science)Projective planeNetwork topologySocial classWeb pageArithmetic meanCellular automatonLimit (category theory)Level (video gaming)State of matterRobotFamilyInformation technology consultingSystem callElectronic mailing listDrill commandsOpen sourceModel theoryFocus (optics)ChainGenderFormal languagePlanningNormal (geometry)WordIdentity managementImage registrationForm (programming)Product (business)Associative propertySoftware testingNominal numberSelf-organizationAreaSoftware developerWebsiteInternetworkingConnected spaceWeightFood energyResultantSet (mathematics)Bound stateException handlingCASE <Informatik>Web crawlerUser interfaceExpected valueEvolutePhysical lawMoment (mathematics)FreewareTerm (mathematics)Wage labourSoftware bugEnterprise architectureKey (cryptography)Ferry CorstenPoint (geometry)Musical ensembleData structureDependent and independent variablesReading (process)Library (computing)Process (computing)MereologySoftwareMathematicsSource codeAxiom of choiceDecision theoryDerivation (linguistics)Commitment schemeNP-hardInheritance (object-oriented programming)Structural loadInternet service providerShared memoryMeasurementArchaeological field surveyComputer animation
26:15
Computer animationXML
Transcript: English(auto-generated)
00:00
Come on! Thank you very much Adrian and hello Philadelphia. A little quick heads up, towards the end of this talk
00:21
I am gonna discuss a couple of issues around depression and burnout. So as a trigger warning, if you need to take some steps for self-care, be advised, I'll flag this again before I start that section. As Adrian said, my name is Russell Keith-McGee. I've been around the Django community for a long time including serving on the technical board, being a member of the core team. Django is an open source project, but it's not the only open source project
00:41
I'm associated with. These days I'm spending most of my time working on the Bewear project. Bewear is an open source collection of tools and libraries for creating native user interfaces in Python. For desktop, but also for iOS and Android and for single page web apps. And I've been associated with a bunch of other open source projects as a user, as a contributor,
01:01
as a project maintainer over the years. Now if your parents were anything like mine, they drilled into you at a very young age that it's important to share your toys with the other children. And it's this sharing philosophy that is at the core of open source. Yes, I could tinker away with my own thing and build something useful and lock it away so that nobody else could see it. But if I share what I know,
01:20
everyone gets richer for the experience. Others can see how my toys work. Others can take my toys and use them. And I can use their toys to do the same. And if we work together, we can combine forces and build something truly magnificent together. However, as we grow up, we discover that it isn't quite as simple as just share. We can certainly aspire to this as a philosophy,
01:42
but you have to be proactive. You have to set up the conditions that make sharing both possible and attractive. And there are people out there who weren't taught to play, by their parents to play well with others. And so while sharing is a good philosophy to maintain, it's also necessary to protect yourself. Sivispatcham parabellum, if you want peace,
02:00
prepare for war. Because when some nefarious individual has stolen your toys, it's the worst possible time to discover that you're not protected. What I'm presenting here is a redux of the things that I've picked up in my 20-something year, a year career as a software engineer, preceded by another 10 years as a software enthusiast. And in particular, from the experience I gained from my role as being president
02:22
of the Django Software Foundation. The role of the DSF was and is to be the coordinating entity around the Django project. The DSF is charged with ensuring that the Django as a project can continue to exist. This means establishing the conditions that enable Django to thrive and providing the big stick of protection for the project's assets.
02:41
Okay, so let's take a look at a couple of areas where you need to have your wits about you if you are going to be sharing your toys with others. Start with copyright. What is copyright? Copyright is the right created in law, granting a creator of an original work the exclusive rights to decide how that work is used and distributed. Copyright is granted immediately and by default to the person
03:03
who creates the piece of work when they create it. If you write a song, write a book, write some software, you are the creator of that work. And you have the right to decide how that creation will be used. A copyright, using the word as a noun there, is property. It's intellectual property. It's something that can be bought and sold.
03:21
It can only be owned by a single legal entity at any given time. And I say entity there because it can be a company that owns it. If you have a copyright, and if I have a copyright and I sell it to you, you now own it. You have the copyright for that work. Copyright isn't granted indefinitely, it's granted for a period of time. In theory, it eventually expires, and when it does,
03:42
the work reverts to the public domain. I say in theory because copyright durations keep getting extended, but in theory, all work will eventually revert to the public domain. If you've got a tangible, physical piece of property, there are obvious limitations to use. This is my phone, and if you take it without permission, you're stealing it, and that's a criminal act.
04:01
But I can give you permission, I can license you to use my phone, and then it isn't a criminal act for you to use my phone. I can set constraints on your use. I might ask you not to tweet pooping while you have access to my phone. And lending you my phone doesn't inherently give you any property rights over my phone.
04:20
You can't lend my phone to someone else unless I say you can. It's still my property. You're just using it under license. However, I can give you or sell you my phone. I can transfer my property right to you, but it makes a big difference whether I'm giving you my phone or licensing you my phone. A piece of software is intellectual property.
04:41
The copyright for a piece of software is owned by someone. By default, the creator. If you want to use a piece of software, you have to either be given ownership, given the copyright, or granted a license to use that work. And it makes a very big difference which one you get. Traditionally, copyright was granted
05:01
to give creators exclusivity to sell copies of their work. The expectation was that people would license copies of their work in exchange for payment. But in the early 80s, the Free Software Foundation engineered a very clever legal hack. They wrote a software license that rather than defending the rights of the creator defended the rights of the user.
05:21
And the result was copyleft. Copyleft, if you've heard that term, is not a replacement for copyright. It's a clever legal hack that uses copyright law to enforce the exact opposite of what copyright was intended to provide. Without copyright law, copyleft wouldn't exist.
05:41
So, time for a pop quiz. Who owns Django's copyright? If you answer the DSF, you are only partially correct. And by a line of code count, you're wrong. Django's copyright is held primarily by its individual contributors. That's you.
06:00
If you contributed code, there is a small amount of code that was written as a work for hire for the DSF. And some of the initial code was transferred to the ownership of the DSF from the journal world when the DSF was set up. But if you haven't received a paycheck from the DSF or the journal world at some point in your life, and you have code in Django's code base, you still own the copyright to that code.
06:23
That means the DSF doesn't hold the copyright for all of Django. Therefore, the DSF needs a license to distribute the code it doesn't own. This is why Django has contributor license agreements. A CLA is a license that a creator grants
06:41
to another project that enables that project to distribute their code contribution under the same license as the rest of the project. It's that license that allows the DSF to license Django as a whole. So, if you have contributed to Django, make sure you have signed a CLA. And if you work for someone else, make sure they have signed a corporate CLA saying
07:03
that they are allowing your contributions to be used by Django. A contributor license agreement isn't the only way to address the licensing issue. It's the way that the Django project currently uses. A much more lightweight mechanism is something called a developer's certificate of origin. A DCO is the mechanism used by the Linux kernel,
07:21
by Docker, the Bware project, and a number of others. The DCO is a statement that's made by the contributor that verifies that they wrote the code, that the contributor has the right to license it, and that you're willing to grant the project a license to redistribute it. All that's required to acknowledge DCO is actually a single line of text in a git commit message. You're signed off by your name, your email address,
07:43
where that name and email address matches your git credentials, and it's done. When it's merged in, that becomes the git history because the git commit message is part of the hash, it therefore can't be modified, and we've got a permanent proof that you actually signed this piece of code. And to make things easy, git even gives you a command to do this for you.
08:00
If you pass in the minus S flag when you commit, git will add that sign-off line for you based upon your git credentials. A third option is to transfer ownership entirely. Now, this is obviously the heavy-handed approach. When you submit your patch, you sign over all your property rights to that patch. However, some projects do require this,
08:21
most notably the GNU or the core GNU tools, because they have a political goal. They want to ensure that, potentially, they could go to court and defend the GPL, and they don't want to get thrown out of court on the technicality that they don't own the copyright for the code that's being licensed. So they require you to give them ownership of the code, and you lose all your property rights.
08:42
There's a more common form of ownership transfer, though. That's when software is developed as a work-for-hire. If your employer pays you to develop a piece of code, you've probably signed an employment agreement that says your employer owns your creative work. But not always, and not necessarily by default. Check your employment agreement.
09:01
Check your local legal jurisdiction. Check twice if you're a freelancer or contractor, because if you're writing code for a living, it's really important to know whether you own the copyright or your employer owns the copyright, because if your employer owns the copyright, you cannot take that code that you've written and use it in your next project for your next customer,
09:23
unless you've been granted a license to do so. So, assuming you are the copyright holder for a project, or at least a licensor of contributions, how do you grant a license to your end users? Well, there's a number of ways to do it, but the easiest way, the way that's sort of becoming expected practice in the GitHub era, is you put a single license file
09:41
in the root of your code tree. Just contains the contents of the legal agreement that you're asking users to comply to. And how do the users accept that license? By using the code. The license will usually have text to the effect of, by using this code, the user agrees to, blah, blah, blah, blah, blah. There's no need to sign anything for that license to come into effect. It comes into effect through use.
10:02
But what license should you grant? Well, that's entirely up to you. After all, it's your creation. It's your copyright. But if you're managing an open source project, allow me to offer some advice. First off, use one of the well-known licenses. The Open Source Initiative recognizes 78 different open source licenses
10:20
as being compliant with open source guidelines. But even they suggest that you stick to one of the well-known ones. I don't even remotely have enough time to dig into each of these licenses in detail. There are plenty of other videos and articles and resources that analyze what each of these provide and will help you pick the best license. But before you pick a license,
10:40
consider what it is you're trying to achieve. What do you want to be able to use your software for? Who do you want to be able to use your software? Are there particular uses or uses that you're trying to encourage or prevent? Are there particular threats to your project that you perceive? What will be the impact of competing projects or competing implementations or hostile forks?
11:01
Don't just pick one. Pick one that's going to help you achieve your goals for your project. Your choice of license is also a signal about how you perceive your project and its interaction with other pieces of the software environment that it's used in. To that end, it's worth looking at the social signals your community is sending. Django is, for example, a BSD-heavy community.
11:22
You're totally free to use another license if you want. But if you release a Django project under the terms of the BSD license, then you're signaling that you're broadly aligned with community norms. Also, keep in mind what it is that you're writing. The terms of the GPL use lots of specific, software-specific terminology. Those terms may not provide the best protection
11:42
for your work. Maybe you should choose a different option. And you can use different licenses for different pieces of your project. You know, the code under BSD, documentation under Creative Commons, for example. As long as it's clearly communicated what license applies where, you're set. You can, if you choose, offer multiple licenses.
12:02
Remember, a license is an agreement between a licensor and a licensee agreeing the conditions of use. You can offer me multiple sets of terms that I might wish to accept. I only have to accept one in order to use the piece of code. If you have competing interests, for example, commercial users and open-source community users,
12:20
you might want to offer two different licenses on two different sets of terms. The only thing you can't do is not provide a license. If you don't provide a license for your code, if you don't have a license file in your root of your repository or some other indication somewhere in your code of what license the code is available under, the default terms allocated by copyright law
12:42
are all rights reserved, even if you don't say that. That means that nobody can legally use your code. And if you see code with no clearly offered license, you cannot legally use it. This even applies to code snippets. It doesn't matter how long that snippet is.
13:02
It's still a creative work. The owner, the author, still owns the copyright. So you need a license to use that snippet. Sites like Stack Overflow get around this through a user agreement. Part of your agreement as a user of Stack Overflow is that all your contributions are licensed under a creative commons by share alike with attribution.
13:21
You agreed to this when you created your Stack Overflow account. And so through having accepted that agreement, you can use any snippet on Stack Overflow as long as you've got an account. But what if you want to publish a snippet somewhere other than Stack Overflow? You don't want to manage a license, but as a creator, you also can't just throw up your hands in the air and say, well, I've given this away to the public domain.
13:41
As the creator of a work, in some jurisdictions, certain rights cannot be transferred. Issues of copyright are closely turned with a concept known as moral rights, rights that are considered innate to the human experience. The problem is that moral rights are very jurisdiction dependent. Moral rights recognized by European and in particular German courts are much stronger
14:03
than the moral rights recognized by US courts. So if you declare that you've released your code into the public domain, that is actually illegal in Germany. German courts won't recognize that transfer of ownership to the public domain any more than they'd recognize a legal agreement to sell yourself into slavery.
14:21
Your moral right to fair compensation for your creative work is a moral right that is considered unalienable. And so your work reverts to its default license, all rights reserved, and then Germans can't use your code. The other thing you shouldn't do, don't write your own license. And that includes taking a well-known license
14:41
and adding some custom term. The common licenses and their interactions are all well-known quantities. Lawyers know how they work. There's a body of scholarly research on how they affect projects, how they affect companies and so on. I am old enough to remember when open source licenses were shunned by commercial organizations simply because lawyers didn't understand them yet. They're complex.
15:01
The consequences from the states were huge. And so lawyers were, as they always are, conservative and said, no, that's their job. We've broken down that barrier now, but it's taken decades of advocacy and lots of work by the legal community. And you can leverage all of that work simply by picking a known license. If you write your own license, you have to break down those walls by yourself.
15:22
It's also really easy to introduce unexpected consequences. JSLint, it's a really good example. JSLint's license is the MIT license with one appended clause. This software must not be used for evil. Oh, how cute. The side effect is that most Linux distributors
15:40
cannot distribute this code because they cannot ensure that their users are not going to do evil. IBM's lawyers even went as far as to go to Douglas Crockford, the writer of JSLint, and get an explicit license from the author to do evil. So unless you have a really good reason,
16:02
and let's be clear, you don't have a good reason, don't roll your own license. Now, legal concerns don't stop with copyright. Copyright is about the work itself. How you identify that work is a separate issue entirely. And that's where trademarks come in. A trademark is literally a mark of trade. It's how you identify your work.
16:22
It can be a word, a symbol, a set of colors, a shape, a combination of all those things, anything you use to identify your project. How do you get one? You start using a word to identify your product or service. You don't have to do anything else. As long as you're using a name, you can assert trademark rights. You can, if you want, go through the process of formally registering a trademark.
16:42
That's done on a per nation basis. It can be done internationally, but obviously it's a lot more paperwork. Registration, though, doesn't give you any more rights. It just makes it easier to claim your rights because you've got paperwork that says when you started using your trademark. As an example, how many people know what this is?
17:00
Does it look familiar? It's an Australian fast food restaurant chain noted for their signature burger, the Whopper. There's a problem. In Australia, when Burger King came to Australia, there was already another company using that name.
17:21
They only had one store in Adelaide, but they had the trademark. Burger King had to pick another name. It didn't matter that they were a bigger company, that they were an international company, that they were gonna make better use of the name. There was an existing trademark registration and they had to change their name. They chose Hungry Jack's because that was a trademark the parent company already owned.
17:41
It used to be a pancake mix made by Pillsbury. Another example that's closer to home. A couple of years ago, a British organization tried to register a trademark for the name Python to describe cloud software. They claimed ignorance. They didn't know that Python was used in cloud software already. The PSF lodged a complaint arguing prior use
18:01
and the company backed down. Now, this wasn't done because of the US trademark registration. A US trademark registration doesn't hold much weight in Europe but the PSF was able to demonstrate that the name Python had been used for cloud software for many years prior to this registration and that company made the trademark application moot. Trademark applications are also scoped.
18:22
A trademark is generally only granted for a specific subject area. In the US, there are actually three trademark registrations for the name Django. The DSF usage is for downloadable open source computer software for use in connection with internet publishing and website development. So no one else can get the name Django registered for that purpose
18:41
or use the name Django for that purpose. The second registration is for picks for guitars and other musical instruments. So it's held by Breezy Ridge Instruments right here in Pennsylvania. So if the DSF wanted to start selling Django brand guitar picks, it wouldn't be allowed to or at least Breezy Ridge Instruments could stop the sale really easily. The third registration is for perfumes, rouge,
19:00
face powders, toilet waters, cologne waters, cosmetic skin creams and lotions, lipsticks, nail lacquers, hair lotions, lotions for the beard, bath salts, talcum powder, and dentifices. Luckily, this one expired in 1971, so it's clearly just a matter of time before the DSF starts selling Django brand beard lotion. I know, exactly, yeah.
19:22
So, does this all really matter? Yes, a trademark is what lets you stop other people from doing bad things in your name. And this isn't an abstract idea either. The DSF had to stop lawyers, they had to engage lawyers to stop someone selling Django 2.0. It was Django 0.96 with enterprise features,
19:42
like a lack of bug fixes. Now, the thing is, this was a completely legitimate use under Django's source code copyright license. But Django's trademark belongs to the DSF and it can't be used without the DSF's permission and as a result, the company was told,
20:02
well put on a headlock and told, to stop doing it. Now, this raises an interesting question. What happens, when it comes to open source projects, how do you get permission to use a trademark? On the one hand, you want the Django community to be able to use the Django name, but you also have to protect the community from nefarious actors. Answer, once again, is a license.
20:21
If you want to put a commercial logo on your product, you need to get and usually pay for a license to do so. In the case of the DSF, there is a license for the Django name and logo, just a much more liberal one. And once again, if you don't have a license to use that trademark, you can't use it. Except, the one exception is something called nominative use. Nominative use is the usage that is necessary
20:42
in language to name a thing. If I wanted to say, Django was released in 2005, I can't do that without using the name Django, or at least it would be very cumbersome to do so. So trademark law carves out the nominative use as a specific exception. However, that nominative use doesn't stretch through logos, typefaces, or other forms of identity,
21:01
it's just the word, so you can use it to refer to things. The one thing that isn't nominative, is incorporating someone else's trademark into your own. One of the tests for nominative use is whether your usage would confuse someone into believing there was an association between two products. So the best solution, if you're going to set up a company, please don't incorporate someone else's trademark
21:21
into your own. So don't call yourself Django software consultants, because that gets you into some very messy territory. So far, I've been very much focused on the legal aspects of maintaining an open source project. But it's important to know that measures of success for a project are about much more than just covering your butt. I'm gonna talk about two others, one briefly in one or more detail.
21:41
We are, for the most part, techies, and I know the drill, we hate ads, we hate salespeople. Sales and marketing is very, very important. I'm gonna give a second talk this afternoon that covers this part of the puzzle, so come along. And now, trigger warning, I'm about to start talking about depression and burnout. So there are some aspects of open source projects that are almost unique to open source.
22:01
Many of you will know a children's book called The Giving Tree. For those who don't know it, the book is the story of an apple tree and a boy who are able to communicate with each other. In his childhood, the boy enjoys playing with the tree, climbing its trunk, swinging from its branches. As time passes, he starts to exploit the tree. Initially, he just sells the apples, then he cuts the branches of the tree to make lumber for a house, then he cuts down the trunk of the tree to make a boat.
22:21
Each progressively stay, a destructive stage is promoted by the tree itself and ends with a sentence, and the tree was happy. The final page is the tree sadly says she has nothing left to give as her apples, branches, and trunk are all gone and only a stump remains. The story is sometimes told as a parable of the joys of giving and selfless love, but it's also cited as an example of an abusive relationship.
22:42
And in both interpretations, it's a story that's a really good analogy for open source communities. If you're maintaining a project, it's really easy to keep giving of yourself until you have nothing left to give, especially if it's a project you started or you invested a lot of your own time in it. Helping other people gives you a great rush. Seeing other people use your project is a great feeling,
23:03
but it's also really easy to fall into the trap of giving until you don't have anything left to give. On the other end, it's easy to keep taking and without realizing the load that you're putting on the person who's giving. I've made no secret of the fact that I've been struggling with depression for a couple of years now. A big part of the reason that I stepped down from the DSF last year was that I came to the realization
23:22
that I was giving too much of myself to Django. I wasn't growing new branches. I'd reached the point where I was just a stump, but I didn't want to step down from the DSF because if I didn't do it, who else was gonna do it? You know what? Turns out this is an awesome community, and when I said I was stepping down, people like Frank Wiles stepped up and took over. If this was a primarily commercial community,
23:41
that decision's easy. You don't like your job, you change jobs. It's not quite that simple, but you can change jobs. You're exchanging money for labor. You stop getting paid. You're not expected to provide labor anymore, and you're only reasonably expected to have one job at a time. But in a volunteer scenario, the exit path isn't as clear. It's easy to acquire responsibility,
24:01
but a lot harder to divest it. As an individual, you need to make sure you look after yourself. As a community, you need to build structures so this doesn't happen. One way to do this is to institutionalize exits from key roles, set term limits, or at the very least, provide regular opportunities where an active opt-in is required. That regular requirement for an opt-in
24:22
means there's an opt-out point as well. Responsibility shouldn't last forever. Better still, set up community structures where the expectation of free labor is minimized. If you're identifying a role that's going to take resources, be it material, labor, emotional energy, don't just assume those resources will be available forever in boundless quantities.
24:40
The greatest shocks occur when something we assume is plentiful and ubiquitous disappears. Gasoline, electricity, clean water. If your open source project isn't planning for the day when your biggest contributor steps down, your project has a clock on it. And if you're a commercial organization who depends on that project, I would argue you are being criminally negligent
25:00
to your investors because you have not secured your supply chain. You haven't mitigated the key risk associated with using that software. This approach helps to stave off burnout amongst your volunteers, but it also has the added benefit that it broadens the list of people who can do the work. Volunteers, by definition, are made up by those who have the time to volunteer.
25:20
If you've got a family or children or a loved one who needs care, that limits your ability to volunteer. You want to address diversity? Make sure you're not just taking from the pool of people who have copious free time, which, broadly speaking, means white, middle to upper class, Anglo-Saxon men, age 16 to 30. And if you are someone who uses open source, don't just take.
25:41
Give back in tangible ways, either with hard commitments of time or with cash that organizations like the DSF can use. And this is especially important if you're a large organization that has extraordinary resources at their disposal and who derive immense benefit from open source and their volunteer contributors. So, there's a survey of a few important things
26:01
your parents didn't teach you about sharing your toys. Run along now, children. Share your toys and have fun. Just be careful. Make sure you're home in time for dinner.