Mark Surman, expert on collaboration, community building and social technology talks to us about how the Shuttleworth Foundation is kick starting South Africa's knowledge economy by using the principles that have made open source so successful.
Tell us about what you're doing in South Africa:
I currently have a fellowship the Shuttleworth Foundation which was founded by Mark Shuttleworth who's best known as the guy behind Ubuntu Linux. He made a significant amount of money when he sold thawte.com, an online security certificate company. He's South African, so one of the things he decided to do with his earningsâ€”in addition to taking on Microsoft and starting Ubuntu Linuxâ€”was start a foundation that is almost completely focused on work in South Africa. And while the Suttleworth Foundation is not particularly focused on open source development, it's certainly based on open source principles.
We do work in three main areas:
Educationâ€”figuring out how to innovate in education and use open principles to make it more effective.
Intellectual propertyâ€”a proper intellectual property framework is critical to turning South Africa into an innovation or knowledge economy. South Africa presently lacks such a framework, so we're working to build one.
Telecomâ€”we work on Telecom for the same reasons we work on IP issues, to help build South Africa's knowledge industry. South Africa, despite being the richest country in Africa has some of the the worst and most expensive internet and telephone connectivity in the world.
As for my work, I'm officially an "open philanthropy fellow," but I largely do internal management consulting as an advisor to the CEO on how we can use open source principles to run the foundation. We fund a lot of endeavors that work in accordance to open principles, but we seek also to run the foundation in a way that reflects those open principles. Almost no foundations are run this way, so my job is inventing how we do that, in some very basic ways and also in some more advanced ways. (Watch mark give his pitch on open philanthropy)
I also help the team that works on education and work as an international marketing and outreach guy, which is why I get to live in Toronto while everyone else is in Cape Town.
What are the basic open source principles that you're trying to employ within the foundation?
There are 5 principles we aspire to:
We try to bring open licensing into everything we do ourselves and everything we fund, which seems like it would be a no brainer. You would think every philanthropist would embrace open licensing, but nobody does it. Even we don't do it well, and we've been trying it for years! We've certainly fallen on our faces, as we haven't gotten the output out of it that we would have wanted.
I just wrote a case study which talks about how easy it is to say you're going to open up licensing, but how hard it is to keep track of everything and get people to agree on what open licenses will look like when you're giving them grants.
We push ourselves really hard to to work in a networked way. For instance, even though we'd already been working in the open education space for a while, we wanted to go bigger. We went through the trouble to map out who was working in open education and brought them all together to solicit their input on we call the Cape Town Declaration, which is essentially a manifesto about open education and its principles.
There was nothing to motivate us to do that in terms of our specific goals, but we knew that we'd run the risk of reinventing the wheel if we didn't devote a certain amount of money, energy, and brainpower into hooking everyone up. We don't want to risk reinventing the wheel or working in isolation without being able to pick up on the good work that others had already done.
Leverage is an essential component of how open source economics work. For instance, Mark Shuttleworth wouldn't have been able to build Ubuntu without leveraging the work that Linus Torvalds and thousands of others had done on Linux. He was able to leverage the foundation of Linux to build Ubuntu and take Linux to the masses.
There's a nice piece in the new Clay Shirky book which talks about how, if you look at the numbers of open source projects on Sourceforge, the vast vast majority of them never get downloaded by anyone, and then the next tier only get used by a few people, and it's only the smallest number of projects end up being really successful. This is actually a good thing because all of that "failure" ends up being a huge repository that can be leveraged or picked up and rolled into something else later on.
As long as things are open, it's not a waste if someone tries to do something that doesn't take off initially; their work can become successful later on. The ability to leverage such a huge body of work is essential to the success of open source projects. We try to build that idea of leveraging our past work into how we run the foundation as well.
Yeah, but doesn't that often make things more difficult? I mean why not just go ahead and build something instead of rooting around a massive pile of failed previous attempts? You might end up reinventing the wheel, but you're also not getting lost digging through past archives.
Well, this is why networking is so important. If you're in the game, and are aware of who's doing what, you're going to know to ask So-and-so about such-and-such project she was working on if you're about to embark on something similar. This is what intertwines the principles of leveraging and networking. You don't leverage stuff that you find on the street, but you leverage things that you see other people doing.
For instance, we have an open textbook project, in which we're creating open textbooks for all K-12 curricula in South Africa. To do this, we're leveraging the Connexions platform currently used to help university professors collaboratively develop curricula in the US and around the world.
Now, it's because of the connections we made for the Cape Town Declaration that we met the people working on that Connexions. We got to a point where we trusted each other enough to pick it up and use it. So, you have to network to be able to leverage effectively.
Also, another solution to the problem you're talking about is explained by the fourth open principle we hold:
4. Actively sharing and archiving
The other key to being able to leverage effectively is that the open work needs to be findable. The folks that are working on projects have the burden of documenting and sorting and storing their work in a way that makes it findable.
This is something else we need to get better at. There's plenty of work that we've created or funded that's simply gotten lost. You really need to pay attention to future findability if you believe in the high volume work ethic encouraged by open source developers. If you're going to open your work, and be willing to try and fail things, you have to document your work or else it's not going to be useful to the community.
5. Iterating, reflecting, and learning
A lot of foundations pay lip service to the ideal of continually iterating and learning from projects, but few are good at it, ourselves included. Nonetheless, we think we're poised to get much better at it because of the philosophical angle that we're coming from.
Our adherence to these principles forces us to involve ourselves much more than most other foundations. We can't just cut checks and walk away, but we have to get in the game as much as possibleâ€”much like an open source company will leverage a developer community but also get its hands dirty and do critical pieces of work itself. We fund many qualified people who are working throughout South Africa, but this textbook project that I mentioned is something that we've decided to get personally involved in and manage ourselves.
We also manage many of our projects in-house, including our project involving peer to peer learning of analytical skills and our free textbook work. These are actually our biggest investments and we take a direct lead on implementing them. We also get hands on through fellowships, where we bring in fellows who are leaders in a particular space and allow them to take initiative and make things happen in house.
Tell me more about how you've applied open licensing principles to your work in South Africa
Basically, back in 2003, we decided we should encourage anyone we worked with or funded to release their work, whether software or content, under an open license. We just assumed it would happen.
We assumed incorrectly. We ran into certain cases where it became clear that our message wasn't being heard or understood. In one instance, things were going badly with a certain education program for which we'd funded a lot of materials. The board said, "It's all open, so let's just take what they've produced so far and we'll fix it up and distribute it as we see fit." In another instance, someone from the board assumed we could take some work that we'd previously funded and roll it into a new endeavor. However, in both of these cases, we found that there are all kind of different barriers to taking advantage of what we thought was open.
Misunderstanding was one barrier. When it came time to take advantage of the open license, we'd find that people simply hadn't grasped what we were talking about and wouldn't agree to our terms. Other people simply said "No, you can't have it." We didn't have a solid contract to back ourselves up. We'd never had anyone sign anything that specified how their work was to be open.
Other cases have been complicated when groups agree to create open content but wrap copyrighted content within it. They've paid for rights to the copyrighted content, but including it in their "open" work prevents other people from appropriating the work and redistributing it or building upon it, which essentially closes it off. So there's a misunderstanding around IP issues that complicates the message.
Now we now have a much more explicit policy on open licensing that explains exactly what we mean when we say "open." And we have stronger contracts to enforce this, although we're working to make them better. Regardless, we've learned to be much more clear. Sometimes we leave the ownership of materials in the hands of the group we've funded to create the materials. However, in instances of works that have been created by large collaborative efforts, our foundation will retain ownership of the work as a steward, which is common practice that we've ported from the open source world. Just as Canonical acts as a steward of Linux by defending its openness against patent threats, we protect the openness of the educational material that we fund.
Another failure was not tracking things. We were funding work that simply got lost because we didn't have any consolidated search or storage systems. There's no sense of keeping our work open if we can't find it later. We're still in the process of figuring this out.
One one hand, you want to make sure that everyone has as much control and autonomy as possible, but you also need to make sure that their work is accessible and extensible once they've stopped working on it. This is particularly difficult in an organization that's trying to stay small, and doesn't have its own department of librarians.
But what about the people who are using the work? One of the fundamental ideas behind open source software is that it's built by people who use it. In the case of your textbooks, are you bringing teachers on board to carry on their development indefinitely? They're the ones who are going to need the books, so they've got to be the best people to maintain them.
We're talking about stuff that may never have the kind of user base of a Linux or an Apache, so our textbooks will likely have much smaller community support systems than the big open source projects. But, we still benefit by making sure that these things are out there and free and in the wild. Even without such a large base of people, someone will add to these materials for any number of reasons.
They might be writing a research paper or trying to get tenured. They might be in the business of delivering educational services, or they might just think it's something interesting to work on. Whatever their motivation, we want to make sure that whatever they leave behind is open to somebody else in the future. The beauty of this is that the motivations to add to these books can be much more diverse than what you might expect in a traditional open source software project.
I think the most concrete place that we are applying the open source principles is in the open textbook project. It's essentially a Wikipedia for the entire K-12 curriculum in South Africa. We're inviting teachers to write their own books, and so we hope they'll be ones to preserve the works. We're just trying to figure out the ownership.
If possible we'd like to leave ownership with the creators because they have the most reason to sustain it. But, when we have more complicated works that have been created by hundreds or thousands of people, we find that it's much easier to defend the IP and maintain the openness of that work if we consolidate ownership into one group.
But anyway, yes, the teachers are going to be the people to maintain the textbooks. In fact, we got into the project in the first place because we'd found a group of teachers who were already working on writing all of the math and science subject for grades 10-12. They came to us and we were able to cover a few of their costs. They ended up being successful enough that we took their leader and brought him in house to lead our overall free textbook project. So, we had evidence to show that teachers will do this in South Africa.
Then, the other thing that's happening is that you're starting to see teachers and other people who will organize themselves into "swap and share" circles in which they'll share information about how and what to teach. There simply aren't enough government curriculum advisors available in South Africa to help them take the national curriculum and translate it into the materials they need in the classroom.
This isn't just textbooks, but also handouts, lesson plans, and all those kinds of things. They're simply responding to a gap in the system. We figure that if we can help build an online system to encourage this kind of sharing and develop a clear open source licensing scheme to protect it, the other teachers around the country who haven't mobilized yet will be able to benefit later on. We're laying an open foundation so that, over time, we'll be able to bring more teachers on board.