Process Mechanics

Social: VanL on LinkedIn VanL on Hacker News Code: VanL on Github VanL on Bitbucket Me: About VanL VanL's physical location

A Model IP and Open Source Contribution Policy

Many times I come across companies that have open source policies that are just backwards. For many companies, their default legal position is that they don't want anything to do with open source. They don't want their partners working with it, they don't want their suppliers working with it, and they especially don't want their employees working with it.

This is despite the fact that in the last "Future of Open Source" survey, 97% of companies surveyed use open source as part of their product or operations.

Obviously, this kind of contradiction creates problems and stresses. I can't solve all of these problems... yet. But one issue that frequently comes up is how a company can deal with the interactions between its own developers and the open source community.

To help solve that problem, I am releasing a Model IP and Open Source contribution policy based upon the policy we use at Rackspace. Take it, use it - it is released under a Creative Commons CC-BY license. If you click through above the it is available for download in lawyer-friendly .docx format.

This policy reflects many years worth of development, some of which took place before I even came on board at Rackspace. The actual writing didn't take that long, of course. The work went into the development of the specific language, understanding, and arguments that allowed us to implement a policy that worked for for our executives, and our lawyers, and our technical population.


This policy is not for every company. Even if your company has a very similar outlook to Rackspace, your specific needs or strategies are different. You will need to look at what will work for you.

Also, I am not your lawyer. I probably don't even know you. We have no attorney-client relationship. This information is given for your information and amusement only. This information is provided without any warranties, duties, or guarantees. You have been warned.

A detour into philosophy

There are a number of philosphical points of view that are reflected in this document. If you don't agree with underlying framework for understanding and creating value with IP, then you will likely not like (or even understand) this policy. So let's take a minute and break them out.

Developing employees is a better investment than developing many kinds of IP.

This is the key assumption, and it is controversial in some circles. This is about your business philosophy, not the law.

Most companies take the approach that they are better off capturing all the possible IP output from each employee and keeping it within the company. The "capture it all!" philosophy comes from an effort to eliminate downside risk. If you don't know what might be valuable in the future, then you try to hold on to everything to avoid letting out the goose that lays the golden eggs.

In contrast, this IP policy comes from an effort to maximize the value of each employee's contributions, even if the place where the IP is most valuable is in outside hands. There are other ways that IP provides value other than keeping things secret or licensing them for money.

This policy builds on the assumption that only some parts of a company's IP matter to the company. The other parts of the company's IP can be more profitably used in developing the culture in the workplace, the capabilities of the employees, and the reputation and mindshare of the company.

Because of this assumption, this policy requires a high degree of internal self-knowledge and self-confidence within company leadership about what the company does to provide value.

Contributing to existing projects

Let's be more concrete: Let's look at the case of a patch to an existing OSS project. The chance that your company will have unique, valuable IP in a patch provided to an existing open source project is very low. The project is already in the sphere of public knowledge. If the patch is not shared, it probably stays within the mind of the one employee who developed it, and it can even be a financial burden to the company to maintain as a parallel, non-integrated patchset over time.

On the other hand, letting out the IP associated with the patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.

Releasing company IP to the outside world

The trickier issue has to do with the release of company-developed IP to the outside world. This policy takes the pragmatic view that not everything should be released - but that many things can be.

This is because only a fraction of the company's efforts actually provides differentiating value to customers. Regardless of what you do, or what business you are in, or what your product is, you spend a lot of time, effort, and money on stuff that either serves your internal needs or is simply "table stakes" for customers.

At a high level, this should not be controversial. From an accounting perspective, companies already break out "G & A," or "General and Administrative Expense." This is finance-speak for overhead - things that companies do that don't directly build products or create revenue.

But let's look within a revenue-producing, you-sell-it-for-money product. A "product" is usually not a singular entity. Instead, it is a bundle of lots of little services, or code, or components. While each of these little pieces may be necessary to the final product, most of them are not differentiating to the customer. They don't provide a reason to buy.

A few simple examples: Screws and nails are essential parts of a house, but only rarely do buyers care about which screws and nails are actually used. A smartphone dialer (the number pad used to input the phone number) is a necessary part of the smartphone product, but buyers only really care that it is there and that it works.

You can break apart every product into smaller and smaller bits, and you will find that most parts of most products are necessary, but they don't actually drive customers to buy. Any parts of your product that don't drive customers to buy are candidates for sharing.

Build assumptions about trust and judgment into your agreements with your employees.

Your employees have already made a substantial commitment to your company. They are trusted to exercise their discretion on behalf of the company all the time. So, where possible, build on those assumptions in your employment agreements. It is better to have a flexible policy that implements an expectation of good judgment and honesty than to have a rigid policy that ends up creating compliance headaches because you can't anticipate every situation.

It is true that you need to "trust but verify" by building checks into the process. But starting from the assumption that your employees can exercise judgment makes many things easier. And if you can't trust your employees, well, you need much more help than I can give you.

Finally, optimize for easy compliance.

Policies are overhead. The most effective policies are the ones that receive the highest voluntary compliance. Sometimes policies can be effectively enforced, sometimes they can't. A strict, "optimal" unenforced and unenforceable policy is far worse than a less-constraining policy that has high voluntary buy-in.

The policy

This policy takes the form of an IP assignment agreement between an employer and an employee. It has some legalese, but the jargon is kept to a minimum. The agreement as a whole is designed to be read and understood by the employee. Remember, the goal here is voluntary compliance. The employees will have a hard time with voluntary compliance if they feel like they have been given an inscrutable wall of small print.

Unfortunately, there is only so much you can do to make things simple: it is eleven pages long, with three of those pages providing state-specific guidelines that govern employer-employee IP agreements. But the agreement as a whole tells a logical story, roughly based on the chronological experience between the parties.

The Preamble

Diving into the policy itself, it is worth starting with the preamble. The preamble is designed to be a combination executive summary and announcement of the core principles motivating this agreement:

ModelCo employees are productive and creative individuals. ModelCo has a responsibility to safeguard our corporate interests, but we also value and respect the personal initiative of our employees. We hired you because we believe in you, your skills, and your value, and we recognize you will have many opportunities to do and create cool things outside of your employment here. We support your independent efforts to build, and create, and contribute, and we want to provide clear communication and guidelines about how to do so properly. We want to make sure that we set common expectations so that we are never in an adversarial position relative to our employees. The legal terms below flow from these objectives.

Three points to take away from this preamble. First, this sets up a position of mutual respect between the company and the employee. Both are entering into this agreement to provide something of value.

Second, the purpose of this agreement is to provide rules and guidelines to coordinate the employer and employee's mutual efforts.

Third, and this will be important later on, we never want to be in an adversarial position with our employees.

Section 1: Definitions

The definitions of "Confidential Information" and "Intellectual Property" are relatively straightforward. There are two important definitions, though, that pave the way for the later sections. The first is the definition of "Company Resources":

“1(c): Company Resources” means any action or Intellectual Property that meets at least one of the following conditions: created (1) acting at ModelCo’s direction, (2) in connection with your employment by ModelCo, (3) for use by ModelCo, (4) during your working hours as a ModelCo employee, or (5) using ModelCo equipment other than a ModelCo-provided laptop or ModelCo-provided mobile phone.

This is an important definition because it defines Company Resources in a way that includes time, direction, and intention. In most IP agreements, "Company Resources" are defined relative to the use of equipment. This definition includes most uses of company equipment, but also makes clear that intention and direction also count.

This definition also includes a siginificant give-back to the employee: they can use their company-provided laptop and mobile phone to do personal work. This is a reflection of the fact that we all live mixed lives these days, with work and home life both blending together. This avoids a trap for the unwary and makes it easier for employees to comply with the policy overall.

The second important definition is the definition of an "Open Source Project":

1(d): “Open Source Project” means a project that (1) has its complete source code, documentation, and build files available to the public under a license accepted by the Open Source Initiative as an open source license, (2) is downloadable by the public without registration, payment, or any other type of consideration, and (3) is publicly advertised and available on the World Wide Web.

This definition is designed to prevent some types of possible gamesmanship. Per this definition, a project only counts as open source if it is not only licensed appropriately, but is widely available to the public for free. An "open source project" that only exists on your server at home isn't really open source.

Section 2: Ownership of IP Created Prior to Your Employment

IP created prior to employment belongs to the employee. Period. The employee can also continue to develop Prior IP, as long as the employee does so without using Company Confidential Information or Company Resources.

One noteworthy bit is that this policy recognizes repo commits as a reasonable method of proving that something was truly prior IP in the case of a dispute.

Section 3: Ownership of IP Created Using Non-company Resources

This is the next section because most developers will want to know if they will be allowed to have side projects. The answer to that question is yes - but the policy has some important nuances. Keep in mind that these guidelines are for new side projects created by employees, not on company time.

Section 3(a): No Subject Matter Conflicts

You will not knowingly participate in the development of IP related to a current or planned Company product, service, technology, or offering without prior authorization from the ModelCo IP Committee. Authorization may only be provided on a per-project basis. Knowledge of a product, service, technology, or offering includes knowledge of perceived gaps or opportunities for add-ons, extensions, improvements, complementary technologies, or value-added services.

This is one section where employees are expected to use their judgment. The policy doesn't try to spell out every possible situation. Instead, it spells out that employees cannot put themselves into conflict with the employer.

Sections 3(b)-3(c): Notice, not permission

Employees are required to give notice of their side projects in a very low-ceremony way: by sending an email.

3(b): Notice to Company. You will promptly notify the ModelCo IP Committee using the proper channel (currently by email to whenever you start any new project that involves the creation or development of IP. The proposed project and resulting IP must be described in enough detail to allow the Company to understand the scope, purpose, timeline, and any known conflicts. You must also promptly notify the IP Committee if the nature or scope of an existing project changes significantly.

As I stated earlier, one of the keys to a successful policy is voluntary compliance. We want to provide as small a barrier as possible to employee creativity, while still giving the company the chance to track and respond ongoing projects.

From the business and legal side, though, this is one of the parts that makes people worried. It is up to the company to review and keep up with these new project requests. If the company does nothing, the project is deemed OK:

3(c): Authorization. The Company understands that you may not know the full scope of ModelCo’s business activities, and so a project may pose an inadvertent subject matter conflict. To address the possibility of inadvertent subject matter conflicts, the IP Committee will have sixty (60) days (the “Notice Period”) to provide an initial response to your request.... If no response is provided within the Notice Period, your participation is deemed to be authorized within the scope and purpose of your notice. If the Committee responds to your notice with anything other than clear words of authorization, you may not participate in the project.

"What if we miss something?" they say. "What if there is a new project that crosses into company territory, and we let it go?"

There are a couple responses to these worries. First, don't do that. This is low-ceremony and low-overhead for a reason. It doesn't just make compliance easier for the employees, but it makes it easier for the employers as well.

Second, you need to look at the actual risk, not the theoretical risk. Let's say that in one area of the company they have a plan to implement a new product with feature X. In another part of the company, an independent engineer decides to start a new project providing the same feature X.

Note that this is an issue of two strands of independent development; if the employee was already aware of the parallel development effort, then they would already be barred from creating a subject matter conflict.

What are the reasonable responses?

First, you have an employee who has self-identified as being interested and capable in an area that the company has deemed strategically important. Invite the employee to join the effort!

Second, if feature X is so easy to implement that a single engineer is able to make it work in a couple months of off-hours work, then perhaps feature X is not the differentiator you are looking for, and the product offering needs to be further refined.

Section 4: Ownership of IP created using Company Resources

This part of the policy is about the other side of the bargain: there are certain things that companies pay their developers to do, and they want to own those things. The position taken by this policy is that anything made with Company Resources (which includes company information, direction, and time) is owned by the company, regardless of whether it is part of your official "job description" or not.

4.1: Ownership of Company IP. Any IP created by you using Company Resources belongs to ModelCo (“Company Intellectual Property” or “Company IP”), whether or not the IP is related to your specific job duties. By signing this agreement, you hereby assign and promise to assign all right, interest, and title to all Company IP to ModelCo. In addition, you promise to cooperate with ModelCo in securing and protecting our rights in Company IP that is created by you, whether or not you continue to be employed by ModelCo, and you hereby appoint ModelCo as your limited agent for that purpose.

4.2: Release of Company IP

The ModelCo IP Committee is the only entity authorized to establish new licensing terms for any piece of Company IP. If you believe that your work would be beneficial to release as open source or otherwise license, send an email describing the suggestion to the IP Committee at

The policy also makes explicit that the company's authorized representatives (here, the IP Committee) is the only group authorized to license out Company IP, for example to create a new open source license. While the process around release is deliverately simple (again, set an email), and the policy is relatively open, each company needs to decide whether the release of particular IP is strategically the right thing to do.

As an aside, at Rackspace we have found that in most cases, our employees already have a good idea about what is and is not sensitive and what can and should be released. We have only had to deny a handful of requests over the past several years.

4.3: Exceptions

With the ongoing and written approval of your manager, you may use Company Resources for the creation and development of IP to be contributed to existing Open Source Projects or to be used as part of any Non-Code Works, as those terms are defined in this Agreement. The ability to use Company Resources to contribute to Open Source Projects or to develop Non-Code Works does not change or supersede your day-to-day job responsibilities as set by your manager. In all cases, you shall exercise good judgment and act consistent with The Company’s core values.

This section peels back some of the more absolute rules to give employees the flexibilitiy needed to develop their skills and participate in various communities. It opens the door for people to work on open source projects, even at work. But these exceptions represent a couple of key compromises:

  • You need the approval of your manager. The existence of a policy that allows employees to contribute to OSS projects does not mean that employees can substitute OSS work for whatever they have been assigned to do.

  • You need to use good judgment. It is true that asserting that employees must use good judgment and adhere to company values is not enough to deter all bad behavior. But by making the requirement explicit, it allows poor judgment to be dealt with as a violation of the policy without trying to specify all the ways in which people can do stupid things.

4.3(a): Contribution to Existing Open Source Projects

You may contribute your original code in your own name and under your own copyright to existing Open Source Projects that do not directly compete with a Company-sponsored project or product. You may contribute to existing Open Source Projects that are directly competitive with a Company-sponsored project or product where you have received prior authorization from the ModelCo IP Committee.

This policy allow carte blanche contributions to open source projects that are not competitive with company-sponsored projects or products. This provision is to minimize conflicts of interest as well as reducing the possibility of inadvertent IP release. Competing projects are whitelisted on a per-project basis.

Within Rackspace, we have even gone further, and allow contribution to all established open source projects, even ones that compete with our sponsored projects and offerings. We only ask that employees talk with us and explain why they want to contribute and what they hope to improve.

4.3(b): Non-Code Works

Not everything that people do is just code. One of the pitfalls of overbroad IP policy is that it captures things that are beneficial to the company, like creating and giving presentations, writing books, etc. This section gives employees the freedom to create in other ways but with a few specific restrictions.

4.3(b): Non-Code Works. Employees are encouraged to create non-executable copyrighted works (such as books, speeches, articles, and publications, collectively “Non-Code Works”) and can do so in their own name and with their own copyright, without any prior approval, subject to the following:

i. Notice Required for Compensated Works. You must provide notice to the ModelCo IP Committee at least ten (10) business days prior to publishing any Non-Code Works for which you expect to receive compensation in any form from any third party. ModelCo may, at its discretion, require you to forego any compensation for work done using Company Resources.

ii. Credit to the Company. You may state that you work for the Company in your background or biographical material. If you developed any part of the work using Company Resources, you may say that the Company sponsored the creation of the work provided that you do not represent the work as an official the Company publication.

These sections are designed to address double-dipping (for conflict of interest purposes), to give appropriate guidelines for talking about the developer's employment.

There is also a special restriction for those employees who create non-code works as the output of their job responsibilities:

iii. Limitations on Non-Code Works. This section does not apply to any Non-Code Works made in the course of employment or with Company Resources (such as documentation, teaching curricula, business plans, etc.). This section also does not give any right to use or publish any Confidential Information or to use any ModelCo trademarks in a Non-Code Work.

If your company has a someone whose job it is to create written or visual materials, then those materials created at the direction of the company should be treated as work output, and not as something that was created for personal development.

Section 5: Limitations and Restrictions

Sections 3 and 4 provide considerable freedom for employees to engage outside the company; section 5 provides guidelines and guarantees that make sure that the company isn't harmed.

Section 5.1: Confidential Information

Employees have a duty to keep Confidential Information confidential, whether it belongs to the company or a third party. Unauthorized release of Confidential Information may result in an injunction.

Section 5.2: No Conflicts of Interest

You will not solicit, enter into, or accept any contract or agreement with the Company, any of its employees, agents, or customers (collectively “Conflicted Parties”), for the purchase, license, or paid use of any IP which you have created or in which you have any right, title, or interest. In the event that an authorized agent of the Company, or a Company customer, approaches you about a possible contract, your conflict of interest must be disclosed and waived, in writing, by one of the Company’s Associate General Counsel or the Company’s General Counsel.

Conflicts of interest are poisonous. I have almost never seen an occasion where overlooking a conflict of interest led to a good outcome. For that reason, many of the restrictions in section 5 deal with various types of conflicts.

This section is designed to prevent the situation where an employee develops something with an eye to selling it back to the company later.

Technically, such development would already be a subject matter conflict as discussed in section 3(a), which forbids employees from developing new projects based upon "knowledge of perceived gaps or opportunities for add-ons, extensions, improvements, complementary technologies, or value-added services." This provision is designed to provide an absolute bar to such activity.

Two real-world wrinkles. First, what if an employee creates a mobile app, or a service, where they don't know if someone is a Conflicted Party or not? How can the employee be sure to stay in compliance? That led to the following clause:

5.2(a): Mass-market offerings. It is not considered a conflict of interest to provide a service or software product accessible to the public in general, including possible use by Conflicted Parties, provided that 1) there is no direct contact with any Conflicted Party; 2) the terms offered to Conflicted Parties are identical to the terms available to all members of the public; and 3) you do not use your relationship with ModelCo, nor any Confidential Information, to establish, advertise, develop, or serve any customer.

Second, some moonlighting arrangements, even if they would otherwise be acceptable, require a restriction on the employee's actions, like a noncompete. This sort of arrangement required another clause:

5.2(b): No restrictions on work. You will not enter into any agreement during the term of your employment with the Company that would restrict the type of work you may perform at the Company.

5.3: Covenant not to Compete

During the term of your employment, you will not solicit, enter into, or accept any contract or agreement with a Company competitor or any of its agents for the purchase, license, or paid use of any IP which you have created or in which you have any right, title, or interest.

This is another type of conflict of interest - providing personally owned IP to a competitor. If a competitor is interested in a particular piece of IP, then it is probably applicable to the company as well.

5.4: Covenant not to Sue

In consideration for your access to the Company’s Confidential Information, you hereby covenant not to sue the Company or the Company’s customers in any venue, for any reason, to enforce any right associated with IP which you have created or in which you have any right, title, or interest.

One of the worst situations is to be in a lawsuit between an employee and employer. Again, by putting the employee and company on different sides of a lawsuit, it creates divergent and conflicting interests. Thus, all suits between the employee and the company over employee IP are prohibited.

5.5 Shop Rights

If you use, embed, or otherwise bring IP which you have created or in which you have any right, title, or interest into the Company in such a way that the Company or any of the Company’s customers may be liable for infringement of that IP, you hereby grant a worldwide, fully-paid-up irrevocable license to the Company and the Company’s customers for such use.

This provision is based upon personal experience: I saw a situation where an employee brought some software into a company and built it into a product. When the employee was fired some time later, he sued the company for copyright infringement.

Therefore, this clause provides a check on the employee's ability to bring individually owned IP into the company. If employee-owned IP comes into the company for whatever reason, then the company and its customers get a license.

5.6 Freedom of Action

Nothing in this agreement shall restrict the Company’s freedom to pursue any business opportunity, course of development, or business plan regardless of any information disclosed by you to the Company at any time.

A final variant of the conflict of interest scenarios: the company can pursue business ideas wherever they find them, regardless of where that idea came from.

Implementing the policy

In concrete terms, there are a few items that are needed to implement this policy.

  • Again, and most important: you need to have your own attorneys look at it. I am not your lawyer, and this is not legal advice. You will probably have other documents and agreements that apply; those need to be harmonized with this document.

  • You should be able to customize this by doing a search and replace, changing "Model Company" and "ModelCo" to your company name.

  • You need to have an IP Committee set up that has both the appropriate authority and knowledge to review submissions that come in under this policy.

  • You need to have appropriate email addresses, lists, or workgroups set up. In particular, the email addresses and are referenced in the text of this document.

  • There are a few specifics you may want to change: the notice period (set in the model as 60 days), the choice of law (Texas).

Final thoughts

There is a lot more to the policy. I have only highlighted a few key provisions that help provide the balance between the two parties that made this an acceptable policy for everyone within Rackspace. I invite you to read the whole thing. Feedback is also welcome - click the email link above.

It took a long while to get to this policy, both in terms of understanding and discussing the acceptable tradeoffs and business issues, and in terms of getting feedback from developers. I want to thank Tina Wuest and Glyph Lefkowitz in particular for their feedback. But the time was worth it; I have been told by a number of people, developers, executives, and lawyers, that they consider this the best policy in the industry. I hope that it proves useful to you too.

The 2015 Future of Open Source Survey

Black Duck Software and North Bridge Venture Capital just released a the results of their "2015 Future of Open Source" survey. The summary is below.

2015 Future of Open Source Survey Results from North Bridge

Amongst the high level of bizspeak, a couple things stood out to me:

Slide 8: The big number on the slide talks about 78% of companies "running" on open source, but the big news to me is the small number: Only 3% of businesses say that they don't use OSS in any way. From my experience, I would guess that a high percentage of those who say they use no OSS are mistaken.

Open source is becoming a fundamental part of business everywhere, but I still see very little open source strategy at play. There is a huge opportunity for those companies willing to adopt a whole-company strategic mindset towards OSS.

Slide 13: Of the companies surveyed, 50% of engineers were working on OSS projects. There is definitely wiggle room in that number: not only is there selection bias, but "working on OSS" can mean anything from engaging with a community to sysadmin-ing Linux boxes. Still, the raw number is astounding. I believe that this is the reason why new developments and innovations are coming out just as often (or even more often) in the OSS world as in the proprietary world.

Slide 14: 88% of companies expect to increase their engagement with OSS over the next couple years. From a front-line developer perspective, this means that working on proprietary code will increasingly become a net negative. Expertise in a single-company application is less portable (and thus less valuable). Also see slide 20 about recruiting.

Slide 15: 53% of companies surveyed want to make it easier to contribute to OSS. Nevertheless, getting the business leaders and legal departments to agree with engineering can be hard. This is part of what I am going to be talking about at OSCON.

Slide 32: I found the list of the "most valuable OSS projects" surprising. I wonder what measurements they used. I hope it wasn't lines of code. :)

Read the whole thing.

The PSF: Behind the curtain

Several months back I put out a call, asking what people would like to learn about the Python Software Foundation in my talk at PyCon. I got a lot of responses, both in email and twitter.

My favorite was from David Beazley:

Beazley quote

I followed this advice and spent time watching a number of Samuel Beckett plays. I saw one that I particularly remember - a Python-themed version of Waiting for Godot called Waiting for 2.8. I hate to spoil it for anyone who hasn't seen it, but 2.8 never appears.

I also got a lot of requests to talk about the PSF, like this one from Nick:

Nick Tweet

So the first thing is to explain exactly what the PSF does. This is easiest to explain by comparing the Python Community to a corporation. When most people think about the parts of the Python community, they think about it like this:

Python Corporation 1

We of course have Product Strategy and Development - that is Python core dev. We also have R&D in places like PyPy and Numba. We have Enterprise Integration - Jython and IronPython. We also have libraries and SDKs, Addons, and Tooling - packages on PyPI, Anaconda, the SciPy stack, etc. We also have many developer advocates and evangelists all over the world.

In a corporate world, almost everything above is capitalizeable. That's a long way of saying that the people above this line build stuff that is valuable over a long period of time.

There are a bunch of other support functions, though, that support the efforts above. It is mostly what is known as G & A, or "General and Administrative Expense." The PSF takes care of this stuff. And as a general rule, these are the groups that people love to hate:

PSF Corp 2

You all know these groups. IT. Finance. Accounting. Legal. Human Resources. Events and Logistics. Public Relations. Sales and Marketing. The PSF has a significant effort in all of these areas and more. We provide the support functions for many hundreds of thousands of Python users worldwide.

Some of that support is in keeping the infrastructure running - like the infrastructure that hosts PyPI, the mailing lists, and If you deploy Python infrastructure, the PSF helps you.

Some of that support is financial. We directly supported conferences where over 50,000 Python users attended. We sponsored projects and development efforts. We paid for sprints and meetups. If you attended a Python or Python-related conference, chances are that the PSF helped you.

Some of that support is legal. Not only does the PSF handle the IP associated with the cPython and Jython interpreters, we also manage trademark usage requests for "Python," the two-snakes logo, "PyCon," "PyLadies," and more. To the extent that there is a clear public perception of what "Python" is, the PSF helped with that too.

The PSF also created the PSF Code of Conduct, and actively encourages the community to be welcoming and helpful. For example, we don't fund conferences without a code of conduct. That is one reason why it is very unusual to find a conference in the Python ecosystem that doesn't have one.

We field inquiries from the press. We work out payment issues (including international ones) for companies. We keep the books straight and the lights on.

So what are the problems? There are a number of them. We're not perfect. This is supposed to be no holds barred look at what the PSF does, so I will tell you what some of the key problem areas are, and what you can do about them.


The first problem is simply time. The PSF has exactly one full-time employee and three part-time employees. Everyone else at the PSF, and those who are working on PSF events like PyCon, do so as a service to the community. Even those few people who are employees serve far more than they would if this were just a job.

Now I am not complaining about this.

On a concrete level, though, people working on PSF things are limited. There are more things that we would like to do - and there are even some people who have stepped up to help. But communicating and managing and teaching takes time. It is difficult to do all those things and still have time to get the immediate items done.

So what can you do?

First, say thanks. If you see someone helping out at a conference, buy them a beverage. Recognize others for what they do. Find someone who has written a library that you can't live without and tell them what their work has done for you. You can do that via email or social media.

Second, the best thing that you can individually do to help the Python community is to reach out, lift, and mentor others. There are always new people. It doesn't matter if they are new to Python, or new to your meetup, or new to your mailing list. Welcome them in and show them the ropes. Bonus points if you bring in someone who doesn't look like you.

Third, for those who are trying to work with others in the PSF, we need you to persevere and be understanding. I heard the story of a new contributor who felt turned off because it was hard to contribute. No one was mean, but no one made the time to help someone new come in. Thankfully, she persevered and was able to land some code. She got over the hump.

There shouldn't be a hump to get over before people can contribute. But there is. Please persevere.


The second major challenge is empathy. A lack of empathy is the biggest strategic weakness in the Python community. By empathy I mean a willingness to place yourself in another's shoes and try to see the world through their eyes.

I believe that the PSF is better at this than most open source communities. I am regularly impressed with the wonderful people in the Python community that go out of their way to help others. Nevertheless, this is still a weakness.

A lack of empathy is expressed through being dismissive of others and their point of view. It doesn't matter if you agree or not. It doesn't matter if that person is wrong. It matters if you try to understand that person and their viewpoint from the perspective of their lived experience.

Banksy quote

This is one of my favorite quotes. As I think of it, every person is the hero of their own story. They are trying the best they can and doing good. It is a failure on our part if we dismiss people as wrong without taking the time to understand why they think they are right, or why they think their contribution is valuable.

Yes, there are trolls. But they are one out of 100, or one out of a thousand. We should eject those who are intentionally or persistently abusive.

There are a few people in every community I am in that I pretty much never agree with. But behind those few people are many others who think the same way. When I take the time to understand, I do better. Sometimes I am convinced. A lot of times not. But those people who think that I am doing it wrong teach me more than all of those who agree with me.

What can you do?

Stop labeling. Wait before you attach labels to people, or conduct, or arguments that don't take into account the content and intent of what people are saying. It's ok to have those labels - they are meaningful to you. But if you want to connect with a person, you need to reach out and start from where they are, not from where you are.

Always give people the benefit of the doubt. One of the difficult things about our society is that more and more of our discussions come through as pixels, not people. It is easy to misunderstand a statement posted on the Internet or sent through and email if you don't have the cultural and personal context that drove that statement.

This doesn't excuse things when people get hurt. As @jacobian correctly pointed out to me, intent isn't magic. But we should always, always assume that people are trying to do good and strive to understand others in that light.


The third biggest problem we deal with in the PSF is a lack of responsibility.

We have many people who are willing to criticize how something is done. Many of those criticisms are correct. And, truth be told, I find great value in being told when I am doing something wrong.


Too many of us stop when we have raised our voice to complain, without taking responsibility to take the next step. At minimum spend the time to work out and politely express what could be done better, or even step up and help. Does this mean that if you don't like a library you need to become a core maintainer? Of course not. But it does mean that we need to take responsibility for the burdens that we ask others to take for us.

There was a thread recently where a long-time and prolific contributor described how people would insist on changes to his libraries. Users felt entitled to criticize and insist that work be done on their behalf with no thought for how that would fit within that developer's other demands.

This is not good enough. It is a failure of empathy and responsibility. It is not kind, and it needs to stop.

So what can you do?

Stop before you complain, directly to a person or generally on the Internet. Do your homework. Remember, people are always trying to do their best. Was there a problem that prevented the result you want? Find out first.

Second, look for ways that you can engage constructively. Do that instead.

Be specific and constructive. Do you still think that you should speak out? Isolate the change that needs to be made so that your feedback is actionable. "It doesn't work" isn't a bug report and "It sucks" isn't a feature request.

The next question asked what advice I might have for open source projects that want to grow up to be the PSF:

grow up

Don't rush it. You can and should set rules of the road and expectations early on, but make processes as lightweight and informal as possible.

Default to openness - but realize openness is not really an end in itself. Openness is the start of communication. What you really want to do is to understand and empower, not just check a box.

Culture matters. Build one that reflects the best of who you are. The best determinant of which technology will succeed is not the technology itself, but instead the strength and vitality of the community around it. If you put obstacles in the path of people participating with you, you put obstacles in the path of your own success.

There have been anomalies - technologies or projects that have succeeded despite a difficult or toxic culture. The time when projects or companies can succeed with toxic cultures is quickly disappearing into the rear-view mirror.
In the PSF, what we consciously try to encourage is a culture of service.

I'm going to go out on a limb because I know there are a number of people who disagree with me here. I believe that the culture of service is what sets the Python community apart from almost every other community I know. The PSF doesn't pay its directors or committee members. While we PyCon doesn't pay speakers or organizers for their service.

Don't mistake me. I am not saying that people should never be paid when they provide valuable services. I think it is wrong when commercial interests see communities as the equivalent of contractors that they don't have to pay. I also think it is reasonable to have paid positions that help empower others.

But a group where everyone only interacts if they are paid is not a community. It is a bunch of mercenaries.

A community that reaches out to serve and to help others becomes deeper, richer, and better over time. This is the reason why we reach out to others. This is why the PSF cares so much about including others, because they are our friends - or at least we hope they soon will be. Reach out and serve another person and you will find a friend.

Threats and opportunities

I got a final question via email - what are the greatest threats to Python and the Python community? What are our greatest opportunities?

In my opinion, the greatest threat to the Python community is that we are not adapting to changes in the industry fast enough. I am worried about technical shortcomings that lead people to choose other technologies, even if they would prefer to be in Python.

I don't think that other languages must "lose" for Python to win. But every time someone says, "I love Python, but I had to do my new project in ______," I get a little worried. Software is an ecosystem, and when our ecosystem shrinks, the opportunities available for all of us get diminished.

The term “software ecosystem” was coined about ten years ago in a book written by David G. Messerschmitt and Clemens Szyperski. In this book, they laid an extended argument that different people and companies, acting with their own interests in mind, can be thought about as an ecosystem just like the natural ecosystems around us. The term stuck. Even though the specific roles that Messerschmitt and Szyperski imagined haven’t caught on, the concept has. For example, Stephen O’Grady from the analyst firm RedMonk named his blog “tecosystems" after this concept, "because," as he says, "technology is just another ecosystem."

Python has a huge and vibrant ecosystem. Everyone in the Python community is a beneficiary of this fact. But Python has lost something in the transition: underdog status.

It was ten years ago that Paul Graham wrote “The Python Paradox,” in which he said:

"[P]eople don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job.”

Isn’t it funny that ten years ago Python was considered “relatively esoteric”? This is the most recent ranking of programming languages based on a cross-tabulation of github projects and stack overflow questions. Python comes in a solid #3. In other publications, Python is a solid top-4 or top-5 language, and is considered a “safe and well-supported” choice by publications like CTO magazine.

Why does underdog status matter? Because in 2015, there is no more Python paradox. A number of key developer communities have moved on, setting the stage for Python to be disrupted (in an Innovator's Dilemma sense). I may talk a lot about improving our community, but I think the Python community is our greatest strength. Our weakness, right now, is technical.

From a technical perspective, three threats I worry about most, and they are all related: multicore, mobile, and package management. From a language standpoint, I am really worried about Javascript and Go.

The reasons Javascript worries me should be broadly apparent. It is the most widely deployed language on the planet except for C and C++. It is dynamic, it is getting lots of funding, and it is an intrinsic part of the web.

As for Go, that is a more fundamental threat. Go is close to the metal, has an easy-to-understand concurrency model, is mostly low friction, and is "close enough" to good that it is becoming a language of choice for networked applications. It also has a deployment story that is way better than it is for Python: Copy the binary and it's done!

Go also has the advantage that it has full-time developers working on nothing but improving Go. Twenty years on, and we still don't have full-time developers working on Python. Every core dev in Python is contributing "on the side."

The problem with Go is that any code written in Go is dead code. Because of the static linking, because the primary compiler uses an unusual calling convention, any effort that people put into Go software is locked into the Go ecosystem. Unlike, say, Rust, there is no way to use Go for the things that it is good at and use Python in the places where it shines. If someone makes the shift to Go, they have to go all-in. It makes the choice stark.

What is our greatest opportunity? That is easy - schoolkids. Python either is, or is becoming the dominant teaching language across the world. Organizations from middle school on up to universities are adopting Python as their teaching language.

The Raspberry Pi includes Python 3. MicroPython is incredibly successful in the embedded world. The BBC Microbit is going to be distributed to every single child in the UK - and it will be programmable in Python 3.

With so many new people being exposed to Python, we have the opportunity to create great new things. We have dedicated, wonderful people who are trying to move the world forward. If we are able to evolve so that we can address our challenges, Python has the potential to be the dominant dynamic language worldwide.

Convenience, open source, and the cloud

Matt Asay wonders whether the superior convenience of cloud-based services may reduce the uptake of open source solutions:

Open source risks being devoured by the very cloud to which it gave birth, by @mjasay: Google, Facebook, and the other dominant web companies depend upon open source. Born in the cloud, the economics of proprietary software are inimical to the scale at which such companies operate. As Facebook's engineering team noted in a blog, "Facebook is built on open source from top to bottom, and could not exist without it." Could not exist. This isn't a matter of personal preference, but existential reality....

On the one hand, as Redmonk analyst Stephen O'Grady highlighted, the Facebooks and Googles of the world are happy to release mountains of open source.... The problem, however, is that one of open source's biggest advantages - convenience - is trumped by cloud convenience.

Asay concludes that this is overall a positive trend, one that open source companies should embrace.

I generally agree - in the past, individual open source packages may have been the convenient for individual developers due to cost, licensing, availability, etc., and that this is not necessarily still true due to the widespread availability of SaaS apps.

But the "convenience" argument still rings true for me. I think that the locus of "convenience" is just moving up the stack, from a focus on individuals to a focus on teams. If you move up one layer to the type of software being developed by teams, you again start to see the the use of open source as an enabler. Sure, individual components may be "outsourced" to SaaS apps as various teams begin development. Non-core functions may be outsourced for a long time. But as soon as product-market fit is found, teams tend to bring the development in house and build using traditional open source development methodologies.

I see this behavior as the result of discovered competitive advantage and resultant specialization. If an app is so simple that it can be built/scaled by simply wiring together other existing IaaS/PaaS/SaaS infrastructure without a custom component, then it is likely that new entrants into the market will reduce the profit in that segment down to an uninteresting level. Alternatively, teams that build bespoke architectures will have advantages in scale or cost of delivery that that will drive others out of the market.

I also believe that this is why the new hot applications in open source tend to be software that shines when scale or team coordination is needed - DevOps (generally), container orchestration (Docker, Mesos, Kubernetes), and streaming-ready architectures (Kafka, Spark, Storm, etc).

On the Economic Rationality of Voters

On Economist's View, Mark Thoma asks "Why don't voters penalize politicians for poor economic decisions?" and quotes Paul Krugman:

Economics and Elections, by Paul Krugman, Commentary, NY Times: Britain’s economic performance since the financial crisis struck has been startlingly bad. ... Yet as Britain prepares to go to the polls, the leaders of the coalition government that has ruled the country since 2010 are posing as the guardians of prosperity, the people who really know how to run the economy. And they are, by and large, getting away with it.... This is ... a distressing result, because it says that there is little or no political reward for good policy.... In fact, the evidence suggests that the politically smart thing might well be to impose a pointless depression on your country for much of your time in office, solely to leave room for a roaring recovery just before voters go to the polls.

So how would you model how people might incorporate economic information into their voting?

First, and most fundamentally, even economically savvy voters are acting under uncertainty. It is very difficult for any voter to identify what the "correct" macroeconomic policy is for any particular circumstance. While not all people are Nobel-winning economists like Paul Krugman, there are well-regarded, non-political macroeconomic theorists on both sides of almost any issue. There are only a relatively small number of principles and policy responses that are widely agreed upon by Keynesians, Straussians, Market monetarists, and followers of other flavors of economic thought.

Even some apparently "fundamental" measurements can be changed - see the debate over microeconomic foundations for macro models or Scott Sumner's ongoing efforts to convince people to use NGDP targeting.

Assuming counterfactually that the proper policy response to a particular situation is universally acknowledged, there is the tendency of the world to not always act according the model - leading to further uncertainty on the part of the voter. Thus, for many issues it comes down to the quality of argumentation, and not necessarily which approach to governance is theoretically optimal.

Second, voters are presented with an asymmetric information problem related to politician's actions in office. While some aspects of governance are available for public scrutiny, many aspects are not. There is no guarantee that the public rhetoric matches the governance - and we know that many times, it does not. Therefore, a voter might rationally discount the rhetoric and focus instead on perceived "character" or "judgment" of the politician - which again devolves in most cases to the quality of argumentation.

Third, a voter might rationally weigh how much politicians and political parties really affect the economy. It is the nature of the political process to assign blame or to take credit, but it is an open question how much effect is directly driven by political leaders. Political leaders clearly have some effect on the economy, but the extent to which individual espoused policies drive macro changes is debatable at best.

Thus, an individually rational voter - well-informed or not - may reasonably decide to extrapolate from the current observed trajectory of the economy and vote for "more of the same," without debating too much as to which espoused policies may be implicated.

Decisive vs. Inclusive Leadership

I had two situations recently in which my goal was to lead a group of people to arrive at and act on a particular conclusion. Even though I achieved my goal in both situations, I acted with almost opposite strategies to do so. In one case I acted decisively, telling the group what to do, and in the other situation I held back and only tried to act like one member of the group.

In both cases it was messy, and I came under some criticism for how I acted, but I am not sure what I would have done differently.

The specifics of the two situations were different, but they were structurally similar:

  • Time pressure. In each case, the decision needed to be made and acted on within 24 hours, hopefully less.

  • Decision pressure. The results of the decision would have wide-ranging effects, beyond the scope of those making the decision. Many eyes were on the outcome.

  • Size of group. There was a group of 8-12 people that needed to come to the conclusion. Small enough to come to a conclusion; large enough to have a bunch of different opinions.

  • Dual goals. I mentioned that in each case I had the goal of provoking a specific, short-term action. In both cases, I also had a secondary, but still very important goal to empower and build up the group.

  • Both policy and tactical decisions. Both situations came out of a specific situation that was representative of a more general case. Both the long-term policy as well as the short-term course of action needed to be decided and reconciled.

So what was different between the two situations?

In the first situation, there was a fair amount of internal dissent as to the proper course of action. I frequently hang back from discussion and then weigh in a little more sparingly. When I did speak up, though, I stated what should be done and directly asked the others to help me implement it. A little surprisingly, everyone quickly agreed that this was the right way forward (despite substantial disagreement right before) and were happy with the outcome.

In the second situation, the immediate action was less controversial, but there was more debate about the proper long-term policy. In this situation I simply tried to express my opinion as one of the group, and try to keep the group focused on the immediate need for action. In the end, the desired action and policy were taken as a consensus decision.

In both cases I received criticism for the amount of back-and-forth needed to make the "simple" decision for action. The criticism, though, caused me to reflect on the two situations - how they were similar, and how they were different. I was acting on instinct and gut in both of these, so why did I act the way that I did?

I came to a couple conclusions:

  • The criticism was fair. In both cases it would have been easiest to simply make the decision and go forward. There was too much back-and-forth on too many irrelevant details. In the midst of the discussions, I was frustrated with the slowness of the process as well.

  • I had an implicit dual mandate that affected my actions. After thinking, I wasn't necessarily displeased. I think this is because I realized that I wasn't optimizing for just the one immediate outcome. I was also trying to build up and empower the group.

  • The difference of opinion on the immediate action was key. The first situation had more agreement as to policy and less as to what action was immediately needed. The second situation was reversed. Combined with the time pressure, it was probably this key difference that led to the difference in my own actions.

In the first situation, there was no consensus on what to do next, so a decision was needed to break the logjam. There was no natural leader for this action, so the artificial organizational leadership needed to be substituted and used.

In the second situation, I had more implicit confidence in the immediate outcome, so it was easier to hang back and let others have a chance to lead.

Even after reflection, though, I am not sure that what I did was best. Would it have been better to be more decisive, earlier? I really don't know.

In the first situation, it could be that it would have hastened the correct action - but it could also be that the group dynamics required the buildup of tension to allow decisive action to resolve it. Coming in earlier, even with the exact same words and the exact same actions, may not have been accepted as legitimate because the underlying fault lines had not been exposed.

In the second situation, I am not sure that a more decisive tone would have accomplished the secondary objective of empowering the group. Perhaps it would have been better, though, to explicitly separate the long-term policy discussion and the short-term action discussion into two separate timeframes so as to focus each discussion more effectively.