Why Nonprofits (and Foundations) Should Care About Open Source

Posted on Published by Eugene Eric Kim

Why should nonprofit organizations care about Open Source? I’ve had an ongoing conversation about this with Katrin Verclas for a while now, and I thought it would be worth outlining the arguments here. I actually think philanthropic organizations should care a lot more about Open Source than nonprofits, and I’ll explain why below.    (KOD)

Forget, for a moment, the question of whether nonprofits should be investing in technology or what the long-term return on investment might be. That question is a bit of a red herring, because a lot of nonprofits have fundamental problems (poor management, under-resourced, etc.) that can’t be resolved with technology.    (KOE)

Instead, assume that there are specific needs that can be addressed by technology. The question is, what do nonprofit organizations need to leverage that technology? They need two things:    (KOF)

  • The tools themselves    (KOG)
  • Capacity — the ability to install, maintain, and use the tools    (KOH)

If there’s an affordable tool that meets your needs, and if you have the capacity to install, maintain, and use it, then it doesn’t matter whether the tool is proprietary or Open Source. Use it.    (KOI)

If there’s no tool that meets your exact needs, then that tool becomes a candidate for fundraising, and the conversation likely shifts from the nonprofit itself to foundations. If you’re a foundation and if you’re going to invest in the creation of a tool, there are all the reasons in the world to invest in Open Source.    (KOJ)

  • You get more for your money, because others can invest in the same codebase as well, and you can use what you develop across your entire portfolio. This is especially true if you’re investing in a project that already exists.    (KOK)
  • You decrease the likelihood of lock-in. This is a bit misleading, as the cost of switching technology is not necessarily lower if your software is Open Source. However, you avoid the problem of legacy, unsupported software where the supporting company disappears, because the source code is always available.    (KOL)

Most importantly, as a foundation (or nonprofit), you’re more likely to be skilled at connecting people than you are at developing software. And this is exactly what developers need to build better tools — a greater understanding of their users. Commercial companies aren’t likely to care about a market unless it is mature, and the needs of most nonprofits don’t fall into that category. But Open Source developers will care. Many Open Source developers share the same underlying “do good” attitude that folks in the nonprofit world have, and they’re more than happy to improve their tools for the nonprofit community. By focusing on connecting with a pre-existing software development community that is already predisposed to work for the social good, you are likely to get better tools sooner than you might from proprietary software companies.    (KOM)

More importantly, the process of connecting has a powerful side-effect: It helps build organizational capacity. When you connect your community to developers, you’re also connecting your community to each other. There will be some who will feed off the knowledge of developers, and that’s critical. Even more critical is what your community will absorb from each other. People are far more likely to learn from their peers — those they perceive are as lost as they are — then they are from authority figures.    (KON)

Stars Aligning, Ice Breaking

Posted on Published by Eugene Eric Kim

Jon Ramer had a great line this morning that really struck a chord. He said he felt like the stars were aligning and the ice was breaking. It’s a beautiful metaphor, because it describes in a nutshell what needs to happen in order for a self-organizing system to be successful. Catalyzing collaboration in a community consists of removing obstacles and prodding the system. In the end, however, your success still depends on whether or not the stars are aligned.    (KO4)

A lot of politicians saw Howard Dean‘s successful use of the Internet in 2004 and tried to replicate it with limited success. Similarly, a lot of organizations install Wikis thinking they’re going to have the next Wikipedia, or they Open Source their software, thinking they’re going to have the next Apache. It’s okay to think big, but it’s also important to recognize what you can and can’t control.    (KO5)

You can’t organize self-organization. Those who try are doomed to failure. Successfully catalyzing large-scale emergence requires understanding this fact and managing expectations accordingly.    (KO6)

The Story of Glormf: Lessons on Language and Naming

Posted on Published by Eugene Eric Kim

Jack Park recently asked about Link As You Think on the Blue Oxen Collaboration Collaboratory. I’ve written several blog posts on the matter, but there’s not much else out there. This was a great excuse for me to tell a few vignettes about Shared Language and the importance of names.    (KMO)

Glormf    (KMP)

This is Glormf, courtesy of the uber-talented cartoonist, Brian Narelle.    (KMQ)

(KMR)

Fen Labalme coined the term (originally spelled “glormph”) at an Identity Commons retreat in July 2003. We were strategizing about next steps, and we found that we were all struggling to describe what it was that we were all working on. Although we all had different views of the proverbial elephant, we were also convinced that we were talking about the same thing. In an inspired moment of clarity, Fen exclaimed, “It’s Glormf!” Much to our delight, Brian was listening to the conversation and drew Glormf for all of us to see.    (KMS)

Glormf’s birth lifted a huge burden off our shoulders. Even though Glormf was mucky, it was also real. We knew this, because it had a name and even a picture, and we could point to it and talk about it with ease. The name itself had no biases towards any particular view, which enabled all of us to use it comfortably. Each of us still had a hard time describing exactly what Glormf was, but if anyone challenged Glormf’s existence, any one of us could point to Glormf and say, “There it is.”    (KMT)

We had created Shared Language, although we hadn’t rigorously defined or agreed on what the term meant. And that was okay, because the mere existence of Shared Language allowed us to move the conversation forward.    (KMU)

Ingy’s Rule and Community Marks (KMV)

Ingy dot Net‘s first rule of starting a successful Open Source project is to come up with a cool name. I like to say that a startup isn’t real until it has a T-shirt.    (KMW)

Heather Newbold once told a wonderful story about how Matt Gonzalez’s mayoral campaign buttons galvanized the progressive community in San Francisco and almost won him the election. As people started wearing the green campaign buttons, she described the startling revelation that progressives in San Francisco had: There are others out there like me. A lot of them. I was amazed to hear her speak of the impact of this recognition, coming from a city that has traditionally been a hotbed of activism.    (KMX)

There’s a pattern in all of these rules and stories. I struggled to come up with a name for this pattern, and the best I could do for a long time was Stone Soup (courtesy of the participants in my 2004 Chili PLoP workshop). I loved the story associated with this name, the parable of how transformational self-awareness can be. But, it wasn’t quite concrete enough for my taste.    (KMY)

I think Chris Messina‘s term, “Community Mark“, is much better. Chris has actually fleshed out the legal implications of a Community Mark, which I recommend that folks read. Whether or not you agree with him on the details, the essence of Community Marks is indisputable: Effective communities have Community Marks. Community Marks make communities real, just as the term “Glormf” made a concept real. That’s the power of Shared Language.    (KMZ)

Pattern Languages and Wikis    (KN0)

Pattern Languages are all about Shared Language. Much of Christopher Alexander‘s classic, The Timeless Way of Building, is about the importance of names. In his book, Alexander devotes an entire chapter to describing this objective quality that all great buildings have. As you can imagine, his description is not entirely concrete, but he does manage to give it a name: “Quality Without A Name.” Call it a copout if you’d like, but if you use the term (or its acronym, “QWAN”) with anyone in the Pattern Language community, they will know what you’re talking about. Shared Language.    (KN1)

Ward Cunningham was one of the pioneers who brought Alexander’s work to the software engineering community. He created Wikis as a way for people to author and share patterns. Not surprisingly, an important principle underlying Wikis is the importance of names. Regardless of what you think about WikiWords, they have important affordances in this regard. They encourage you to think of word pairs to describe things, which encourages more precise names. They discourage long phrases, which also encourages precision as well as memorability. The more memorable a term, the more likely people will use it.    (KN2)

Ward often tells a story in his Wiki talks about using Class-Responsibility-Collaboration Cards to do software design. One of the things he noticed was that people would put blank cards somewhere on the table and talk about them as if there was something written there. The card and its placement made the concept real, and so the team could effectively discuss it, even though it didn’t have a name or description. (Ward has since formalized leaving CRC cards blank as long as possible as a best practice.) This observation helped him recognize the need and importance of Link As You Think, even if the concept (or Wiki page) did not already exist.    (KNG)

Open Source: Propagating Names    (KN3)

One of Blue Oxen‘s advisors, Christine Peterson, coined the term, “Open Source.” In February 1998, after Netscape had announced its plans to open source its browser, a few folks — Chris, Eric Raymond, Michael Tiemann, Ka-Ping Yee, and others — gathered at the Foresight Institute to strategize. At the meeting, Todd Anderson complained that the term, “Free Software,” was an impediment to wide-scale adoption. After the meeting, Christine called up Todd and suggested the term, “Open Source.” They both loved it. But, they didn’t know how to sell it.    (KN4)

So, they didn’t. At the followup meeting a few days later, Todd casually used the term without explanation. And others in the room naturally picked up on the term, to the point where they were all using it. At that point, they realized they had a good name, and they started evangelizing it to the rest of the community.    (KN5)

Names change the way we think about concepts, and so propagating names widely can shift the way people think about things. This is what happened with “Open Source.” This is what George Lakoff writes about in Moral Politics.    (KN6)

The mark of a good name is that people naturally start using it. A name can come from the top down, but it can’t generally be forced onto people.    (KN7)

Announcing the Hyperscope Project

Posted on Published by Eugene Eric Kim

One of the new projects I have the joy of being involved with this year is Doug Engelbart‘s Hyperscope. Doug recently got a bit of NSF funding to build an Open Source prototype of his vision for a Hyperscope, and Doug asked me to lead the project.    (KAT)

You can read more about the project on the project blog. In short, we’re replicating the original hypertext system’s (Augment) browsing (jumping) and viewing capabilities in Firefox.    (KAU)

Why is this significant? Because even though most of the world knows that Doug Engelbart built the first hypertext system in the 1960s, very few people have ever seen and experienced the system first-hand. And boy, is it a doozy. Doug continues to use the system every day, and it has capabilities that no other system has today.    (KAV)

We want the world to see these features, and we want the world to have the opportunity to learn from them and to integrate them into their own systems. We also want the world to realize that these are not features for features’ sake, but are part of a much larger vision of how society can (and must) get collectively smarter.    (KAW)

This project — and Doug’s larger vision — is about improving society’s ability to collaborate. And that’s why I’m involved. We’re not building code for code’s sake (although the code will kick ass). We are kicking off a larger community conversation about how we can improve collaboration, and how we can and should improve our tools to augment our capabilities.    (KAX)

Join The Community    (KAY)

We’ve got a fantastic core team in place. Brad Neuberg is our lead developer. I’ve written about Brad’s coworking efforts, but I haven’t written about how he’s a kick-butt developer who’s doing wild things with AJAX. More importantly, he’s also a deep thinker, which is an absolute requirement to be successful in this position, a leader in the Open Source community, and a lifetime Engelbart fan (not a requirement, but it didn’t hurt).    (KAZ)

Also joining us is Jonathan Cheyer. Jon’s a long-time member of the Collaboration Collaboratory, and he’s also the tech lead for the Computer History Museum‘s NLS/Augment Restoration Project. I’m pretty sure he’s the most proficient Augment user under 40, and I’m quite certain he knows more about Augment’s internals than anyone else under 40.    (KB0)

What makes the project even more fun is that we’ve been working with folks from Doug’s original lab. His daughter, Christina Engelbart, is program manager and is also sharing her insights into how the system was used as well as her knowledge of Doug’s larger vision. Jeff Rulifson and Charles Irby, the first software leads in Doug’s lab, have shared a lot of their knowledge with us, as have Harvey Lehtman and Raylene Pak. These gatherings have not only been extremely educational — stories galore — they have been tons of fun, and we want to encourage other ex-ARC folks to touch base with us and be part of this new community.    (KB1)

Some additional acknowledgements: Mark Finnern is one of Doug’s biggest supporters, and he has given Doug a valuable forum at Future Salon. He also hooked us up with Blake Ross and Joe Hewitt of Firefox fame, two very cool guys who spent some time with Doug and whom we hope will continually engage with this community. A big shout out also to Philip Gust, also of the NLS/Augment Restoration Project, Dorai Thodla, who experimented with an early prototype of the Hyperscope in Java, and Dave Thomas and his OpenAugment team.    (KB2)

Please join us! Subscribe to our mailing lists and blog (and weekly podcasts), and participate on our Wiki. I’ll mostly blog about the project on the project blog, but I’ll also occasionally discuss stuff here. Brad is also blogging about the project. We’ll also be at SuperHappyDevHouse this Saturday doing an Augment jam session.    (KB3)

Blue Oxen Associates    (KB4)

I’m involved with this project for personal and professional reasons. As I said earlier, this is not just about building a piece of code. It’s about engaging with the community at large and building a movement that falls squarely within the mission of my company. The Hyperscope project will help ground larger conversations about how we can and should improve tool interoperability and usability. More importantly, it will ground larger conversations about process and the bigger picture.    (KB5)

At a very concrete level, the Hyperscope falls well within our goal to bring these deeper ideas into existing tools. Not surprisingly, the Hyperscope should integrate very easily with PurpleWiki (as well as other Wikis), providing a new, slick and useful browsing capability. As the project progresses, I’m looking forward to evolving our tools, as well as seeing other folks evolve theirs.    (KB6)

On a personal level, Doug is why I’m in this business. I’ve never been happier with my work than I’ve been in the past three and a half years at Blue Oxen Associates. I bring people doing meaningful work together, I help them collaborate better, and I do it in an open way that hopefully has a much larger societal impact. It’s intellectually satisfying and emotionally fulfilling. And I wouldn’t be doing any of this had it not been for Doug, who’s been a mentor, a friend, and a cheerleader.    (KB7)

In a way, starting Blue Oxen Associates was my gift to him — a commitment on my part to carry out his larger vision. But working on the Hyperscope is a much more concrete way of returning the favor, and I look forward to doing this for him and for the community at large.    (KB8)

The Price of Openness

Posted on Published by Eugene Eric Kim

By many accounts, Mashup Camp was pretty cool. But there were elements of the event that were most definitely uncool.    (K83)

Ryan King, one of the instigators behind the original Bar Camp, said it best:    (K84)

On news.com.com.com.com today, there’s a pretty silly puff piece about the camp, focusing mainly on David Berlind, one of the organizers (who happens to work for the same company as the publication who published the article).    (K85)

The article talks about the unique nature of Mashup Camp, how it was somewhat free-form, where the attendees created the experience as the event unfolded, rather than having it all planned up front. And the article makes it sound as if David Berlind invented the concepts.    (K86)

That’s bullshit.    (K87)

It most certainly is. Other Bar Camp instigators, such as Chris Messina and Andy Smith, expressed similar sentiments.    (K88)

These folks have every right to feel annoyed. Hell, even I’m annoyed, and all I did was attend the first Bar Camp. But my annoyance is tempered by the following knowledge.    (K89)

First, you pay a price for openness. People often talk about how credit is currency in the Open Source world. That may be true, but there’s no guarantee that anyone gets paid.    (K8A)

For example, given the sudden interest in these so-called unconferences, you would think that Harrison Owen would be a household name. But he’s not. Who is Harrison? He invented Open Space, and rather than trademark it or try to own it in other ways, he gifted it to the world. Most of these gatherings are using some form of Open Space. Has Harrison gotten his due reward for this great gift?    (K8B)

Second, in the end, the cost of openness is worth it, because authenticity always wins.    (K8C)

I stayed away from Mashup Camp, because it didn’t feel authentic to me. That’s not to say that it wasn’t valuable, or that there weren’t great folks involved. Quite the opposite. They did a lot of the things that are critical for throwing great events. And if you examine the Wiki, they credit Bar Camp and Open Space. For all of that, I applaud them. And if other types of gatherings do the same, we will all be better for it.    (K8D)

But what most people fail to get is that you can’t just steal the name and the format, slap together a Wiki, and expect to replicate the spirit of the original event, just as you can’t just slap an Open Source license on a piece of software and expect the hacker community to shower you with love. You need to be authentic.    (K8E)

The original Bar Camp organizers were motivated by the beautiful things that happen when brilliant people gather to share their knowledge and passion, unencumbered by traditional boundaries and hierarchies. Not unexpectedly, some folks saw their success and saw dollar signs. Bully for them. That’s what the market system is all about, and I’m a capitalist through and through.    (K8F)

But retaining the original spirit can be a tricky thing, and it’s impossible if it’s just not in you. And if that spirit is not there, then you lose something critical. Maybe that’s not important to some, and in the short term, it may seem even less so. But in the end, authenticity always wins. For every Mashup Camp, there’s a RecentChangesCamp, gatherings that not only embrace the original spirit, but take it to new heights. If I were a betting man (and I am), I’d bet that the gatherings that capture that original spirit are the ones that will be around five, ten, twenty years from now, in some form or another.    (K8G)