The problems with copyright re-assignment

While I was in NYC (eating awesome food, riding my bike across the brooklyn bridge in the rain!), I spent time catching up with free software advocates. One issue that we talked about was copyright assignment. H Online recently published an article about this. Their description of the Linux kernel’s policy pretty much matches PostgreSQL’s policy:

Ownership of free software is a difficult area, and one that is resolved simply by the Linux kernel project. The code belongs to everyone and no-one, and the copyright for each individual piece of code belongs to the original coder, so that any future reassignment of the licence or the code for the Linux kernel requires the agreement of every other contributor.

I haven’t contributed code to projects other than PostgreSQL in a long time, but an important aspect of contribution that I used to not think very much about is copyright assignment. Now that I have spent a little time thinking about it, my preference is to contribute to projects which do not require copyright re-assignment.

Copyright came up in a conversation about dual-licensing, because it is the copyright assignment which provides the opportunity for a codebase to be re-licensed. But more important to me than the possibility of re-licensing, is the chilling effect copyright re-assignment agreements have on communities. The intent can be to be to hedge a company’s bets against contributor interference, and ultimately be able to assert complete control over a codebase. If we agree that the collaborative production of software is a social good, this type of hedging can only be seen as anti-social, and ultimately, destructive to a software community. In practice, I’ve seen projects which require contributor agreements effectively shun all non-corporate contributions, or actively engage in “ornamental sourcing“.

For a business owner who invests in free and open source software, this is an unsustainable position. The advantage of accessing source code is not just the code, but the people who know the code. And while I’m sure there are some exceptions, I doubt most people consider themselves experts in a codebase without having contributed significant patches to it.

Given all that, copyright assignment to the Free Software Foundation or to Canonical has been a contentious issue. But maybe if you have an organization which is committed in its charter to maintaining software freedom, then the copyright assignment serves a social good and gives an organization like the FSF the legal authority to pursue legal action if the terms of a license are violated.

FOSS resources and articles related to Africa

I spent a little time over the weekend gathering information about free and open source software in Africa, and found at least one active pan-African FOSS organization (FOSSFA), and several interesting articles about governments in Africa using FOSS to open data, and make government more accountable. It seems that the Shuttleworth Foundation sponsors projects, although it wasn’t clear to me whether that sponsorship was primarily for South African projects.

If you know of user groups, other active FOSS organizations in sub-Saharan Africa, or want to suggest interesting research or articles – please leave a comment!

I’ve collected everything as PDFs and uploaded it to drop.io/fossinafrica. I’m also going to link the original sources below.

Here are some articles about Microsoft Windows and Linux competition in Africa:

The most disturbing thing I found was a Wall Street Journal article from October 2008. The WSJ investigated reports that Microsoft had used relatives of government officials to try to get Windows onto government purchased laptops, and also chronicled the failure of a windows-based lab made of refurbished machines that was essentially abandoned, with only 1/3 of the promised computers installed and little or no training for the local staff to maintain the machines and software. Sad and frustrating story.

There’s also a recent blog post about Brazil and open source from the OSI. That report is anecdotal, so I’m taking it with a grain of salt. Still, it is disappointing.

If you are interested in sponsoring travel for an African government official to Open Source Bridge next year, please get in touch. I have met several technologists here in Nigeria who are interested in sharing their experiences implementing free and open source software in Africa. I am encouraging them to also attend open source events in West Africa, but as it turns out, travel inside of Africa is still quite difficult.

Inspiration to project

Kathy Sierra tweeted today about the transition from talking to doing in tech culture. We have Camps, but getting from the inspired conversation to actually producing something useful isn’t always easy. Kathy used the term ‘jam’ to describe what it is when people get together to create something, rather than just talk about it. Here in Portland we use the term ‘hackfest’ or ‘codesprint’. Both of those terms imply working with code that’s already out there. Jam seems like a better term when you’re making and playing from scratch.

I thought this could maybe be the start of our lifecycle:

inspiration/tweet -> *camp -> git init -> *jam -> project

I threw the revision control in there as a placeholder for grabbing a namespace and distributing code.

How do you think community-developed software gets created? How would you describe the process your own projects go through?

An opportunity for Postgres

I wrote up my thoughts on the opportunities for Postgres in light of the Oracle/Sun merger, and the response from our communities.

An excerpt:

As a developer and a sysadmin, my enthusiasm for Postgres comes directly from the people that work on the code. The love of their craft – developing beautiful, purpose-built code – is reflected in the product, the mailing lists and the individuals who make up our community.

When someone asks me why I choose Postgres, I have to first answer that it is because of the people I know who are involved in the project. I trust them, and believe that they make the best technology decisions when it comes to the core of the code.

I believe that there’s room for improvement in extending Postgres’ reach, and speaking to people who don’t already believe the same things that we believe: that conforming to the SQL standard is fundamentally a useful and important goal, that vertical scaling is an important design objective, and that consistency is just as important to excellent user experience as are verbose command names and syntactic sugar extensions.

Let me know what you think!

What works? Getting more women involved in open source.

Taking a break while digging a ditch

Taking a break while digging a ditch

When you have a community, and you notice that there’s an imperfect distribution in participation, what do you do?

How do you increase participation of a particular minority group? What should your goal be?

For example, if you have an open source project, and you need more programmers to contribute — what do you do? What I’ve observed is that the project advertises explicitly – they say, “Hey, we’d like more developers – interested?”

The leaders of the project call up their good friends, and ask those people to help out. Then they present at conferences, saying “Hey, look at our cool project. Want to join us?” They talk to individuals, they talk to groups. They say the same thing, “We’d really like you to join us. So, why don’t you download our code, ask me some questions, and contribute!”

Bottom line: they network, and they find the people that they are looking for.

So, I think this model works equally well for getting more women involved in open source projects. You say to your group of friends, “Hey, I’d like more women contributing to my open source project. Do you know any?” You go to conferences, and you say explicitly, “Hey you – would you like to participate in my project? What are you interested in? Can I help you find a project that is of interest to you?” You go to user groups, and you talk to the women who show up and find ways to keep them engaged in the group, and in the code.

All the hand-wringing over this problem that starts with “I don’t know what to do” can be solved by simply asking people to be involved. Politely, insistently and like you’re bringing them the best party you’ve thrown all year.

Invite them explicitly, rather than falling back on a “if we build it, they will come” mind-set. Sure, a laid-back approach works when you have a popular project, or the choice to contribute is easy. But otherwise, we need to ask for greater participation.

Take a moment, ask yourself — how many women do you know that write code? How many women do you know that contribute to open source in other ways? What can you do to expand your open source circle so that you invite at least one woman into our community? More than one? Maybe half a dozen?

Change yourself, and the whole community will change with you.

Fact is, open source software contribution is still kind of difficult. There are so many barriers to entry that community managers from huge corporations and extremely large open source projects are willing to meet with a group of five people at a 2000-person conference to explain the culture, the potential pitfalls, and the tremendous benefits of getting involved. And those same people are so convinced of the importance of this one-at-a-time contact, that they tell potential contributors, “If you have any questions, email me directly, and I will help you.”

We love our communities and the ideas that drive free and open source software so much that we want to talk to anyone who is interested. We think that it is worth it to convince people, one at a time, to contribute.

The same logic applies to getting women involved. The change won’t happen in a day. We convince people, one at a time, that what we work on – what we believe so much in – is worth contributing to.

And then, one person at a time, we will make it so that women are 50% of open source community.

(image courtesy of diamondmountain via Creative Commons license)

The future of free and open source support models

I attended the MySQL Conference all last week, and am feeling very excited about the future of open source databases. I had many interesting discussions and met a ton of Drizzle hackers I was lucky enough to spend Friday with, digging through code.

I was talking with Paul Vallée of the Pythian Group Thursday about Postgres and the future of enterprise support. And he showed me this great graph from indeed.com. It’s acceleration here, not the raw numbers – but still, a neat graph :)

We discussed the issues that enterprise customers with certain types of regulatory obligations encounter — such as contractual obligations for PCI-compliant credit card storage or outsourced management of sensitive data. The standard response developers might give for this is “read the spec, and make sure you implement it properly”. But the truth is, for larger companies, that may not be enough.

So, assuming for a moment that the Postgres community would even want to address this problem as a group — could it be possible for the Postgres community to provide the legal and financial assurances that an incredibly huge corporation (ahem – Sun/Oracle) can?

The short answer for Postgres right now is “no”.

Originally, I had thought just in term of liability, but Paul clarified:

The liability is just one component of what gives the guarantee meaning because there is a consequence to failed delivery. An SLA can also do this. As can a simple lucrative contract that can be lost, or canceled early if delivery does no take place. The key here is to ensure that the technology adopter can legitimately be confident that they are provably being responsible by adopting the platform. “I trusted” doesn’t cut it for many.

My view was that this type of agreement helps to determine who exactly is to blame (and who can be sued) in the event of a software failure. But, Paul said, “It’s more about assurance (with evidence) that obligations realistically will be met.”

I sometimes think that this system of liability and assurances is just ultimately broken. But it is a reality. So, would it be possible for us to come up with a new legal framework for community-driven software?

Paul brought up the idea of a cooperative, and that maybe such a legal entity could provide protection for individuals involved in supporting Postgres, and also shoulder some or all of the liability that a corporation using Postgres would want. I’m not sure that core developers of Postgres would join such a thing, or whether they would be allowed to given existing agreements they have with their own companies. But it is an interesting idea.

Creating a blueprint for this type of organization – hackers cooperatives – could be a way for truly community software to be developed across companies and among individuals in a sustainable, and “trustable” way. Maybe?

Continuing this train of thought – maybe these are non-governmental organizations, whose main purpose is to create and maintain infrastructure software for the good of the world.

Funding for mid-sized free and open source projects seems to be a consistent problem. Perhaps NGOs are a fair model for us.

I am curious about what effort may have already been made in this direction. My next step will be to contact Bradley Kuhn and see if there’s something out there that might address this.

Women Who Code – where are they?

[ I was working on a blog post about the Women In Open Source roundtable I ran, and then Brenda Wallace tweeted: "it seems reasonably easy 2 get women involved in opensource documentation, ui design, and even management. Why is it hard 2 get women coding?" Here's my longer response, mostly with ideas I got from the roundtable. ]

I ran a panel discussion about Women in Open Source at the PostgreSQL Conference East (last weekend). I talked about all the conference events that I’d seen in the last 1-2 years specific to women, and a pair of researchers talked about communication patterns among women on the KDE women’s list. Then we had a 2 hour discussion with the 10 people in attendance.

Three issues that stuck with me from the discussion were:

Continue reading