Monday Jan 12, 2009

It Starts in your Heart

Some nice bits in here about community from Chris Pirillo -- How Community Works: Past, Present, and Future. My two favorites: community starts in your heart (not in your tools) and leaders grow naturally from within the community (you don`t necessarily have to start out with leaders already in place).

Saturday Jan 03, 2009

Asserting Responsibility

Sink or swim: Haruka Nishimatsu, chief executive Japan Airlines: "Nishimatsu says that in the big picture, JAL's change process has to be much more than just talk - Asia's biggest airline needs to genuinely be overhauled. While some say his plan does not go far enough, particularly in terms of job cuts, Nishimatsu says pragmatism must be adhered to. He also insists that if his targets are not met that he will take full responsibility. 'If you were to ask is this the perfect, completely realisable cost-cutting plan, then that is a very difficult thing to declare,' he says. 'But if we don't achieve our targets, I do not intend to stay on.' "

A leader asserting ... responsibility? I find that especially shocking. Usually leaders spin, deflect, duck, attack, point fingers, lie, and steal. And they usually get away with it, too. I don`t see very many people leading by example these days, do you? And I don`t see very many leaders emerging from real communities of people engaged in direct action, do you? I`m talking about people who actually work not just talk. These people are obvious on every project. They are the leaders even though they don`t have the title and most times never get the title. That`s unfortunate. It seems to me that the era of the experts and special people spinning us like sheep should be over. Humor me. I can dream, can`t I? But is that happening at JAL? Can it happen in government too?

Tuesday Dec 30, 2008

Real Leadership Starts with Real Action

I find most conversations about "leadership" little more than meaningless chit-chat. A waste of time. Talk is cheap. Just ignore it. Action speaks clearly. With that in mind, watch this CNN clip of Japan Airlines CEO Haruka Nishimatsu's attempt to manage his company through tough times -- Evolving Excellence: $20 Billion Company CEO ... Takes the Bus. (Video: here, here,)

What do you think? I've watched the darn thing a dozen times. I can't get enough. It's an inspiration. Yet, it's so stupidly simple. And it speaks quite clearly about this guy's priorities and those of his company. Can you imagine in your wildest dreams business, labor, and political leaders in modern America following this reality of leadership? Yah, I doubt it too.

Now, some of this is cultural in that the distribution of wealth in Japan is not nearly as insane as it is in the United States, and the so-called "talent" market in Japan is nothing like it is in the West as well. The Japanese think very differently about individual talent and its value in relation to an overall organization. It's difficult to explain, but I see it everywhere around here. And I can see both good and bad in it as well. So, I'm not saying that the Japanese know best in all cases. They don't. Neither do we, actually, but we tend to not recognize that. But I do find it remarkable that this story in Japan is really not a big deal at all. Should it be? Regardless of the obvious cultural differences, the United States may be forced to make some cultural changes like these in the near future. It will be fascinating to see how the country deals with it. Is all that "talent" worth all that cash? If it is, so be it. I'm all for paying for the best. But if not, can we finally recognize it, please? Can this be any more obvious now? So far the solution is simply to raid the pockets of us regular people to save all the experts and billionaires with a never ending series of bailouts. How long that will last who knows. I suspect not for very long before people get really pissed, but what do I know. I'm nobody. I have no power. I'm not special in that system, and don't think for a minute that that doesn't get me very down at times. I know, I know ... Obama is going to save us. Right. Got it.

Oh, and by the way, when I travel throughout Asia for Sun, Japan Airlines is always an option for obvious reasons. They fly there a lot. And I generally choose based on times and prices, etc -- just like everyone else (well, everyone else who flies 3rd class, I mean). So, do you think knowing that JAL's CEO is taking the freaking bus to work hanging on to the damn strap like I do and making less money than his pilots will affect my decision to choose an airline? You can absolutely count on it. Never mind that the service on JAL (and most Asian airlines) is vastly superior to every single American and European carrier in the air, I'm talking this guy's plane because he's talking the bus. Period. And Nishimatsu didn't initiate this no-frills style of management when the U.S. fell off the financial cliff a few months ago. Nope. He started a couple of years ago. Anyway, I gotta calm down. Here are some related links talking about this issue. Good stuff. All worth a read if you are just a regular working stiff trying to figure out how to retire and put your kid through college.

Ah, one more thing before I forget. And this is a big deal. If you want to build community in this new era -- one where the people have more of a voice than ever before -- do what Nishimatsu-san does. It's required. How else would you have any credibility whatsoever?

Wednesday Dec 24, 2008

Building Community with Photography

I'm noticing more and more of my images showing up all over the web -- in blogs, on mailing lists, on news sites, in presentations, and inside multiple social networks. That's very cool. I tag my images with the Creative Commons license, so I specifically want people to use them in new and interesting ways.

Before I started taking photographs at community events a few years ago, I hadn't realized the power of an image to cut through language and cultural barriers. It's quite efficient, actually. Every time someone puts one of my images into a Chinese or Japanese or Spanish (or whatever) blog and links back to me it literally introduces me to that community in their native language. And, in many cases, I've met new people I would have never met before in countries I've never been to. All from an image. Now, this happens with text all the time, of course, since I've been communicating on one forum or another in multiple open communities for years now. But it's a very different experience with photography. Images are so much faster at making personal connections across barriers. You don't have to translate. It's easy. You just look. It's instant. In some ways, images actually transcend language while still communicating something of value. I'll have to take more pics and write fewer words.

Tuesday Oct 28, 2008

Small Improvements Leading to Big Results

The Open Secret of Success: "Instead of trying to throw long touchdown passes, as it were, Toyota moves down the field by means of short and steady gains. And so it rejects the idea that innovation is the province of an elect few; instead, it's taken to be an everyday task for which everyone is responsible." -- James Surowiecki, The New Yorker

There is so much to say about that quote. I think it's anti-intuitive for many people, which is probably why many miss it. But what I love is that it's just liberating. If this is true, and if much of Toyota's success is based on everyone being responsible for innovation, then I find that inspiring. Empowering. It means that innovation is not exclusive. It's not necessarily only locked inside the special people with big names, big titles, big brains, big megaphones, or big salaries. How utterly democratic. That's not at all how innovation is generally characterized, though. Be careful what you read.

So, will the American auto companies eventually get this? I think they will. It's cool to see Ford getting back into the quality game -- Ford gains on Toyota -- the Toyota way -- now so things may be changing. This bit about companies trying to leverage the Toyota manufacturing system is really interesting to me. It seems difficult to implement because it's such a different way of thinking, but extreme circumstances are also efficient focusing mechanisms. People get back to basics because they have no choice. That's where Toyota's system came from, actually -- a group of people who built a company during difficult times.

As soon as I read these new links (thanks for the pointers, Chris), I thought about how the Toyota production system is open source, basically, and how leading FOSS developers embrace the very same principles of incremental improvement. Just see Linus Torvalds here and here for one obvious and high profile example, but any reading of open source culture and software development methodologies will bubble up many interesting associations.

Everything tagged Toyota here.

Friday Oct 24, 2008

Running Successful OpenSolaris User Groups

I've been re-reading Eric Raymond's How To Become A Hacker, and one of his links in there points to Rick Moen's Recipe for a Successful Linux User Group. Both documents are excellent. So, I figured I'd scratch out a little "Recipe for Running a Successful OpenSolaris User Group" based on what these guys have said, my own experiences participating in some user groups, and also some observations about a long post I wrote a while back -- Building OpenSolaris Communities. I'll keep adding to this post over time. But for now, here are a few obvious items:
  1. Start: Just start. Decide that you want to form a little group and get going. Keep it simple. Don't do too much planning initially. Just get some guys and go to a local pub or coffee shop someplace and talk. That's a user group. Remember, this is a social exercise first, technical one second. Just my opinion.

  2. Infrastructure: Eventually you should have some sort of web presence to show your stuff and a mailing list to talk to people. If you want this infrastructure on, start here and we'll help you out. Or you can use Google/Yahoo if you like, and if you have some gear you can always build and host your own site. Also, you can leverage many of the social networking platforms out there, such as Facebook, LinkedIn, Ning.

  3. Meetings: Many people feel that to have a user group and attract new people they need technical meetings with well-known speakers right away and that these technical meetings have to occur every month. Why? Why not every other month? Or once a quarter for tech meetings with social meetings in between. Don't treat this as a job. Treat this as fun. Technical meetings naturally grow over time to fulfill a need, but you have to get together as people first to see what happens. Who's working on what? Who knows who? Who wants to collaborate on some projects? Who has some lessons learned to share? Who else lives in the area? Whatever. Don't force it. Talk on list and meet casually till things click, and over time the need for technical meetings will be obvious.

  4. Meeting Rooms: If your group does grow into having regular meetings with presenters and demos and such, you'll need a room. Check with the local universities in your area first. But also talk to the local tech companies. And maybe some members of your user group can offer access to their company's offices on a rotating basis on the weekend. Ping Sun, too, if we are around. We certainly have an interest in seeing OpenSolaris User Groups thrive, and many groups are hosted at Sun facilities worldwide anyway. And if you don't have any Sun employees in your group, this is a good way to get them involved.

  5. Joint Meetings: As your own meetings mature and as you reach out to other communities in your area, consider doing some joint meetings. Get the BSD guys together for a joint OpenSolaris/BSD session. Or an OpenSolaris/Linux meeting. Or go up the stack and talk to application developers and web developers. There are many other user groups and communities out there that you can hang out with to explore technical and personal relationships.

  6. Audio and Video: Some user groups I've been to or observed in the OpenSolaris community are recording their meetings to audio and/or video files for download. Others are streaming. Others offer conference call numbers for live phone participation. These communication techniques are very cool because they enable you to reach new people in your local area and around the world. I live in Japan, but I've called into meetings in China and the United States, and I've viewed online audio/video content from India and Prague and elsewhere. All this brings up another point: local user groups hanging out at local bar are now really international communities. This was always true to a point, but with easy and pervasive communication tools you are now local and global. That's cool.

  7. Size: Don't worry about growing big. Most user groups are initiated and maintained by a pretty small number of people. That's ok. Keep it small if you want. Or grow it large. There are no rules. You decide. But don't feel you have to be this way or that way to be a user group. You don't.

  8. Consistency: Although size is not that important, consistency is probably a bigger deal. Try to keep conversations flowing on list, and if you meet live, try to meet regularly. Some groups meeting monthly and others quarterly. You decide. The frequency of meetings is not as important as the consistency. Momentum and predictability are important for establishing trust and helping people get involved.

  9. Diversity: Try to encourage some diversity. Keep your group open to everyone in the area. You never know who is connected to who out there. Also, part of diversity is to reach out to other groups and other communities. I'm an OpenSolaris guy, but the Tokyo Linux User Group welcomed me to their meetings and on their list as soon as I contacted them. I use Linux, too, but that's not the point. They are open to everyone. And that's a big deal. This is open source. Be open. Same story with the Tokyo2Point0 community.

  10. Identity: Design a t-shirt. A logo. Etc. People love to identify with something bigger themselves, something doing good, something they love. Leverage this natural feeling and promote an identity for your group. You don't have to be aggressive about this, but just be aware that over time your group will develop a culture. Let it emerge naturally.

  11. Photography: The camera is one of the most powerful community-building devices I've ever experienced. It cuts cleanly through tough culture and language barriers, and the vast majority of people I've met love to see images of themselves hanging out with others. I've met thousands of people by taking pictures. So, take pictures.

  12. Leadership: Although most people like keeping things as casual and decentralized as possible, someone has to lead from time to time. Book a meeting room at a university or local company. Send out notices. Update web pages. Collect money at bars for drinks and food. These are all activities that require assertions. As your group grows bigger, the need for clearly identifiable leaders will grow as well. Do you want to lead? And if you are leading, consider rotating leaders at some point. Give other people a chance.

  13. Money: Chip in some of your own cash, but don't go wild. Over time as your group grows, maybe try to raise some money via auctions. The Tokyo Linux User Group does a great job of this. Also, poke the local tech companies for some sponsorship dollars. Hey, you never know. Ask. Use the money for hosting services, trips to conferences, t-shirts, or any other infrastructure costs. You're not running a business, though. You don't need lots of money.
That's it for now. Not complete but just some ideas to kick around. I'll update this from time to time as I think of stuff. Also, if you know of other lists of "how to run a user group" let me know. Until then, keep checking out for updates to the OpenSolaris User Group Community.

Tuesday Mar 25, 2008

Don't Feed the Trolls

"I think trolling in the broader sense has four causes. The most important is distance. People will say things in anonymous forums that they'd never dare say to someone's face." -- Paul Graham, Trolls, 2/08

The other three causes are good, too, but the first is key for me. Get together from time to time. A hand shake or bow and a beer can make all the difference in the world.

Monday Feb 04, 2008

Torvalds on Japan and OpenSolaris

Jim Zemlin released part two of his conversation with Linus Torvalds. I blogged about part one last month. Lots of interesting perspectives in the entire interview.

When asked to comment about OpenSolaris, Torvalds said, "It's generally hard to build a community around a commercial entity that also wants to be in control because everybody else around that commercial entity will always feel like they're at the mercy of Sun. And I'm not even going to go into OpenSolaris because, quite frankly, I don't even care." And there were a few more bits after that, but that's the gist of it. Following the comments of Torvalds about OpenSolaris has been interesting over the last few years. Sometimes supportive, sometimes negative, sometimes indifferent.

But more interesting were his thoughts about the Japanese and the value of incremental improvements: "But if you just incrementally improve on something, you will get there eventually. One analogy ... is the auto industry 40 years ago and how non-innovative Japanese companies that just plodded along, how they were looked down upon by the true innovators in the U.S. auto industry. And look -- who was it that actually ended up changing the auto industry?" Totally agree.

One of the things many Japanese are famous for is taking the long view. It's enough to drive the average westerner insane. But anyway. On OpenSolaris, very early on learned to embrace a long term perspective, and that came from dealing with many engineers at Sun who hold long term views of technology. So, I wonder, what happens if we just plod along, if we just keep improving OpenSolaris incrementally over time, if we keep learning from those who have gone before. I wonder what that perspective buys us?

Linus Torvalds - Part I | Linus Torvalds - Part II

Thursday Jan 10, 2008


Just watched the Google video to this poisonous people presentation. Very good suggestions. Some may be hard to implement, but you need to have at last some standards to encourage specific behaviors within any organization of people.

Friday Dec 21, 2007

Building OpenSolaris Communities

OpenSolaris is a community of communities, and building those communities takes time and effort. No way around it. Throwing code over the wall and walking away is a lost opportunity to engage developers and users around the world. Currently, the biggest OpenSolaris community lives on, but even that community is now made up of many smaller communities in the form of Community Groups, Projects, and User Groups. And then there are other nascent communities starting up with websites in emerging markets and even entire distributions that don't necessarily have direct connections to the operations on OpenSolaris is no longer monolithic and based on one geography. It's growing and diversifying globally.

As Sun moves closed development projects to the open on or just starts new projects from scratch in the open, many people ask, "How do we build a community?" and/or "Why should we build a community?" and/or "How do we grow?" Well, here's my shot at answering those questions from a non-technical perspective. The list of issues below is not necessarily comprehensive (and we don't necessarily do some of these things particularly well), but it's just a set of issues to consider if you want to build a community of people around your stuff.

Building a Community
  1. Planning & Building: The first thing to realize is that building a community is an active and cyclical process of planning and implementation. Some people balk at that notion. They believe communities ought to grow organically. But I suspect most communities actually grow based on active participants directly engaging new people and managing resources from diverse sources including corporate, foundation, and individual. Also, I believe the concept of community building is based largely on two simple principles: (1) open communications and (2) open development. Basically, working in the open and talking in the open. And if you really want to grow big, you'll need to do three things really well: (1) talk to a lot of people all the time, (2) include them in your work, and (3) provide ways for them to contribute back by creating and sharing their work with others. Then the process of working itself helps build community because it generates more communications and more work. And around you go. But active building starts with a plan. Write one. Then start building. Then update your plan. Repeat.

  2. Transparency: Get outside. You can't build a community from behind a firewall. Conversations, lists, source code, binaries, documentation, tools, people, infrastructure, artwork -- get it outside so everyone has a fair shot at engaging and contributing. If there is nothing to gather around, then no one will gather and you will not have a community. And if you are only talking inside, no one on the outside will know you even exist. This is the single biggest mistake people at Sun make. They try to live in two worlds. You can't. Decide. Are you open or not.

  3. Participation: Communities are about direct participation and the building of trust relationships. That means people earn their way based on their contributions, and there is an expectation of opportunity and openness. You can also look at this issue as the distinction between a community and a program. Most programs are one way -- usually going from a company to a market. But communities are two ways (many ways, actually), and involve just as much coming in as going out. Also, participation is really about doing, not talking. Those who do get to lead, and those are the people whose voice is heard above all others. You earn your credibility based on the work you contribute to the community, not the title you have from your company. If you want people to stick around, you will have to embrace this concept and enable them to participate.

  4. Contributions: Define the contributions you are looking for. Give general categories and specific examples and expect the community to offer more examples and things you hadn't even thought of (that's the goal, actually). Here is a list of contributions that OpenSolaris community members have been involved with -- code, scripts, tests, help, presentations, user groups, conference management, language portals, translations, university courses, graphics, ads, training materials, screencasts, videos, websites, wikis, evangelism, documentation, articles, blogs, podcasts, development process, tutorials, input methods, feedback, language compression tools, SCM tools, re-writing closed binaries, defect tracking system, shells, distributions, books, ports, governance. Etc. Although many of those items are technical, some are not, and most do not involve kernel code. In other words, think about a variety of contributions you want to encourage, and then let that list grow in the open. Then when things start coming in, point out the people who are contributing. You want to always call attention to contributions, but do so in an understated way. In most communities, everyone knows who is really contributing because work speaks louder than words, and the contributors are generally working with each other in the open. But it doesn't hurt to thank people once and a while.

  5. Presentations: The biggest problem with most technical presentations is that they are painfully long, and they focus too much on describing the technology itself. That's fine for a classroom or an interactive tutorial session. But the act of building a community is actually not about technology. It's about people. So, explain your technology, sure, but focus much more on how developers and users can get involved and contribute to the technology and community and how that benefits everyone. Most technical presentations have one slide at the end with a list of lists to join. That's not enough. It can't be an after thought. Make it core.

  6. Conferences: You have to go to conferences. Sun runs various conferences, but you need to go to non-Sun FOSS events as well. Both have value but both are different. Also, don't feel you have to always present at conferences. Participating in the sessions, hallway conversations, BOFs, and parties is just as important as presenting formal papers. Just being there is critical. You'll need a mix of face-to-face and online interactions to create a feeling of community. But don't miss the opportunity to do a rapid-fire lightning talk! Most good conferences offer these opportunities. And add user groups to your list of conferences. Go to them and/or start them. If you start a user group, do it in a bar or cafe or something. Start small and social, and let the technical presentations grow slowly as more people bring their own experiences to the group. And don't feel you have to always have a big technical presentation with a 100 people in the room each month. That's not realistic. Maybe try technical sessions quarterly but meet monthly in a bar for food and beer and then discuss things on a mailing list in between meetings. Start small and look for ways to build tradition through repeated experiences. Over time a little culture will soon develop, and that is the glue that will hold your user group together.

  7. Development Process and Infrastructure: If you are going to build a community, you ought to spend some time figuring out the physical infrastructure you'll need to support all the people you want. Will it scale? What development process is needed for accepting contributions? What testing is needed? Do you offer a sandbox for experimentation? What tools are necessary to host the project's artifacts? Who has access? This all depends if you want to host on or on another site, and whether you are running a community group, a user group, or a development project. The higher end code contributors will always be small in number, and those are the guys who have to figure out the tools they'll need. However, non-coders should be involved in these discussions at least partially, so that your infrastructure is built to accommodate a wide variety of contributions.

  8. Leadership, Governance, Culture: What are your community's values? What will the social structure look like? How will your community run itself? How will you make decisions? What is your leadership model? How will you call attention to contributors? How do you resolve conflicts? These are questions that need addressing whenever any large group of people comes together to collaborate around anything. When you are small, you can manage this easily in your head, but when you grow globally you need to document the behavior you want to encourage and set some rules around how to manage it all. It doesn't have to be all pervasive and bureaucratic, but people need to know what you stand for and what you expect. Perhaps a single strong leader is appropriate, but you may want to consider other options of distributed leadership mechanisms as well. Look at other communities such as Mozilla, Linux, Apache, Ruby, Java and the BSDs for examples. Actually, there are many others, but those are some of the bigger open source software communities.

  9. Universities: If you want to grow, you need to go back to school and hang out with young people. Get your project in front of students and professors at universities in emerging markets first. Start with India and China for obvious reasons. But don't neglect the established markets as well. University visits are probably the single best way to ensure that your project has a shot at surviving the future. Neglecting universities is not an option. It needs to be a top priority. By the way, this will probably be the most fun part of your community building operations.

  10. Global: Build your community with a global perspective in mind. Where are the developers who would be interested in your stuff? Go there. A lot. When you go global, though, you will run into all sorts of interesting language and cultural issues that will slow you down. Expect it. Look for people who can help build the community in a given location, and then work to connect multiple locations together. You will not have "one" community around the world, so don't expect everyone to just follow you (or even understand you). You will have many communities, and they will express their own independence quite differently. Your job is to encourage them to be as independent as necessary, but also to help them connect to other regions so they can participate in the meta community. This is not easy, by the way. But it's necessary. And it can be a source of really innovative contributions as emerging markets develop.

  11. Marketing: Get to know your marketing people. They can help publicize your project formally at conferences or within press/analyst operations or at customer meetings. And they can offer a perspective you may have not considered on important issues, such as trademarks, branding, launches, announcements, leaks, and market disruptions. You don't necessarily know what the press is saying about you, right? Would more exposure help? What are the competitive issues marketing sees that you don't? Also, participate in special programs Sun occasionally runs, such as coding contests and events. Sun has other developer programs and web sites that all welcome content and participation. Leverage the company's global resources this way. By the way, humility and honesty are the best techniques for doing effective open source marketing. Keep that in mind as you publicize your stuff.

  12. Advocacy: This is much bigger than marketing and it's somewhat different as well. This is not about specific marketing disciplines such as advertising, marketing, branding, PR, or AR. Instead, it's about direct, unfiltered engagement at a level that leads to active participation and contribution. It's about community building via open communications. Now, that includes marketing, sure, but it also includes engineering and project managers -- and anyone else who wants to get involved. Also, you are the best advocate for your work. So you need to assume the direct responsibility of communicating in your own way. You will be leveraging other resources for this, but ultimately you are responsible for your own bottom line -- which in this case means growing your community and advocating your technology. Don't just give this function to someone and walk away. Be involved.

  13. Legal Issues: This is mostly internal to Sun as you open previously closed code and tools. But even when you are open, you need to consider trademarks, copyright, contributor agreements, licensing, source analysis, etc. These things will not necessarily help your community grow, but they can certainly stop things jet fast if you don't consider them at all. Get to know your lawyers. Teach them about the needs of the community, and ask them to teach you the realities of the law. The education here should go both ways.

  14. Project Management: As your community grows, it will surely contain multiple engineering projects and user activities around the world. Who will run these complex operations? Who will manage the plan and keep the metrics and roadmaps updated? Who will alert you to the organizational politics that you will surely encounter? So, you may want to hunt around for a good project manager to help facilitate things. Just as engineers should build community in the open, so too should project managers. If you look at your project in the broadest possible context, you'll see that it touches many diverse disciplines both inside and outside the firewall, and that will affect how you build your community. 

  15. Have Fun: And finally, building a community is ultimately a social exercise, so people should have fun as they participate. You want to draw people to your community, right? You want to encourage people to stick around, right? Make it fun to hang out. Give people the opportunity to have fun and they will.

OpenSolaris References:

Constitution | Community Groups | Projects | Website lead reference | Contributing | Values | Development Process | Development Reference | Advocacy & User Groups | Code Contributors

Books on Open Source, Licensing, and Community Development:

The Cathedral and the Bazaar Eric Raymond | Innovation Happens Elsewhere Ron Goldman, Richard P. Gabriel | Open Source & Free Software Licensing Andrew M. St. Laurent | Open Source Licensing: Software Freedom & Intellectual Property Law Lawrence Rosen | Open Sources: Voices from the Open Source Revolution Oreilly | Open Sources 2.0 The Continuing Evolution Oreilly | Free as in Freedom Richard Stallman

Post updated: 12/26/07, 12/27/07, 4/28/08, 5/16/08

Monday Nov 26, 2007

Two Great Linus Quotes

Here are two Linus quotes from a recent article in Informationweek -- Torvalds On Where Linux Is Headed In 2008:
And not only do we tend to support many different models of virtualization, but one telling detail may be that I am personally so totally uninterested in it, that I am really happy that I have almost nothing to do with any of them.

And I mention that as a strong point of open source! Why? Because it actually is a great example of what open source results in: one person's (or company's) particular interests don't end up being dominant. The fact that I personally think that virtualization isn't all that exciting means next to nothing.


But in the end, a lot of this is just a huge amount of individually small changes that may not be even interesting on their own - what is then really stunning is how big a difference all those small not-so-interesting changes make when you put them all together.

In other words, I'm a huge believer in the "99 % perspiration, 1% inspiration" rule. It's a lot of hard -- but happily, mostly interesting -- work, and there is seldom, if ever, any single big silver bullet.

Even though I took these two quotes out of the context of the original article, they illustrate two points I agree with: (1) one person or company shouldn't control the entire community, and (2) the real value of community development comes over the long term and results from many small contributions, not one big one. To me, these are two issues facing the OpenSolaris community right now. The small things matter a lot. They add up. And I think we miss that many times because we are too focused on "Sun" in the community on the one hand and the so-called "lack of leadership" on the other. There are no silver bullets for OpenSolaris. And there's nothing to replace the perspiration of doing the hard -- but interesting -- work.

Tuesday Nov 20, 2007

Do. Don't Talk

Today Patrick Finch directed me toward a great open source community presentation from Ted Leung (blog, slides). I agree with many things in this preso, but slide 14 really jumps right out at me. The headline reads: "Build a talk-o-cracy not a do-ocracy." That's obviously what you should not do. Then the two bullets read: "Doing is more important than talking. Talker-not-doer's are a DOS against the community." That's so true. Doing is better than talking generally, and as long as you are transparent in your doing, it's simply the most effective way to get attention on OpenSolaris as well.

Wednesday Oct 03, 2007

Cutting Through Noise

Here's a jet quick way to cut through noise in any community: "Having your voice listened to is a privilege, not a right, and it's a privilege that's earned in proportion to the contribution level, not volume level." -- Alan Burlison. I rather like that concept. It may not get you listened to by the noisy ones, but it will surely connect you to other contributor-oriented people in a community. Those voices come through clearly. The other side of this concept is expressed by Bryan Cantrill, who talked about expressing ideas in code. Both tap into the notion that the talking comes after the doing. Or, perhaps more accurately, talking without any doing is meaningless. Something like that.

Monday Sep 24, 2007

Opening from Closed: 3 Quick Steps

Over the past four years I've been trying to boil down to just a few steps just exactly how we are building community on the OpenSolaris project. After all, we are opening a previously closed project that already had significant operations, so there has to be some sequence here, right? Well, it may not seem like it at times, but there is. And it's complex. But I think I can fit just about everything into one of these three big buckets right here:

3 Steps to Opening from Closed:

  1. Move your own operations outside in stages. Begin with the obvious stuff such as lists, people, and conversations. Then move to code and infrastructure and tools and such. Absolutely nothing will happen outside, however, unless you first start talking outside and building a body of content outside that everyone can see and participate in. It doesn't matter that there is no community yet. It will develop over time. Just close the internal lists, open external ones, and move yourself outside. You may have to keep some closed lists to discuss the proprietary stuff you haven't opened yet and you may have to live in two worlds for a while too. But this should be temporary.
  2. Engage external people as insiders. This is an attitude shift. You have to see external developers as your peers. They are not a market and you are not building a corporate program. They are your peers and you are building a community of equals. Everyone's an insider and everyone's an outsider. Next you start working and collaborating on the code and infrastructure you've been moving out as well. Over time, a new dynamic will form where you create stuff outside, but first just get the closed bits out there so you have something to work on together. You can talk forever. Eventually, you have to work on something.
  3. Build community and leadership. I've always believed that the building of community occurs as a result of talking outside and working outside. It's really very simple. You will attract people if you are open and if there's something for everyone to do. And you have to talk to each other to get anything done. Now, over time you will have to enable people to grow and lead projects and such, so you have to let go. You are no longer running a closed project or corporate program. You are now part of a community, and you have to earn your way just like everyone else under whatever system the community creates. This last step of letting go is just as importing as the first step of moving our own butt across the firewall. Without it, nothing happens.
What do you think? And better yet, how many more big details can you add to the three buckets? Each step has a million details, of course, and many steps happen simultaneously and repeatedly as you open -- especially on large projects involving millions of lines of code, thousands of people, and processes that would fill a library. It takes time. Get used to that idea right up front. It's not quick.

Monday Feb 19, 2007

A way of Thinking

Another interesting article on Toyota -- From 0 to 60 to World Domination. This is a really long piece, over 8,000 words, but it's really nicely done.

Toyota employees think long term. They invest heavily in R&D -- much more than their competitors. Goals of quality and efficiency pervade the organization in engineering and marketing and manufacturing and pretty much everywhere else. Serving customers and building great products while not simultaneously hurting the environment (or at least not making it any worse) don't seem contradictory to these guys. They skip the utterly obscene executive pay packages common in the U.S. Unions are not present, nor are the American-style health care costs. They value evolution, not revolution. They prefer long-lasting and well-researched yet flexible strategies over short term sprints based on fads or whims. Their engineers very clearly lead and do significant -- at times obsessive -- field research first hand behind the wheel all over the world. Marketing is both traditional and grass roots and apparently quite simple and effective. They learn from their mistakes. They are remarkably open about their processes, but they also keep secret some of their innovations just as any smart company would. They are a culture built on top of Japanese culture, for sure, but they are by no means exclusively Japanese. They evolved based on the personal experiences of a unique group of people who dealt with the challenges of a country destroyed by war in a particularly innovative way. They are not perfect and don't lead in every market, but they are certainly on a roll in the biggest market and are delivering one body blow after another to the U.S. auto industry. Very interesting story.

There are a lot of great quotes in this article, but this one just jumps off the page:

Toyota spends $20 million a day ... on research and factories. "They are outspending G.M. in R.&D., product development and capital spending," says Sean McAlinden, an economist at the Center for Automotive Research, a not-for-profit consulting firm in Ann Arbor. "If that trend continues, we're dead. The problem is, suppose we made a car" as good as a Toyota. "Then we only have a car as good as they do. It's not just about catching up, or getting into the game. You’ve got to get ahead somehow. But how?"

So, even though the Toyota Production System is open, and even though this article makes it clear that Toyota "has never really caught the Big Three by surprise," people are still asking "how" they do it. Fascinating. Just having access to an open process will only take you so far, I guess.

Further down in the article you'll find the bit that helps explain why so many miss this point:

Management theorists who study Toyota's production system tend to say that it is difficult to replicate, insofar as the company's methods are not simply a series of techniques but a way of thinking about teamwork, products and efficiency.

A way of thinking. That's tough to copy. Even Toyota formally teaches the system to employees now since the company is growing so rapidly outside Japan, and they are concerned about quality in some markets. I'd like to take that class, actually. Wouldn't you?

Saturday Dec 23, 2006

The Toyota Way and Open Source

More news of Toyota taking out GM -- Toyota’s Sales Projections Show It Surpassing G.M. And more analysts are pointing to the famous "Toyota Way" business processes the company uses as the critical factor. From the Times article:

Toyota’s rise would also prove a victory of sorts for its unique corporate culture, the so-called Toyota Way, which is rooted in an obsession with craftsmanship and constant improvement, or "kaizen." Analysts said the Toyota Way would likely become enshrined as the industry’s gold standard, and the model to mimic or surpass for new challengers from South Korea and China.

"Enshrined as the industry’s gold standard, and the model to mimic," eh? That sounds like open source coming to the auto industry. After all, Toyota's processes are open, aren't they? But the notion of simply mimicking someone else's processes sounds trivial. The implementation is just as important as the source or specification of any business process. And that's much more difficult to mimic because what makes an implementation special is buried deep within the culture of every person doing the implementing. It's not necessarily secret, but it's oftentimes incomprehensible.

Tuesday Sep 12, 2006

Toyota's (Open)TPS

Really long and comprehensive article in Baseline on Toyota -- What's Driving Toyota? Nice piece, actually. I don't know where to begin since so many bits in the article interest me. How about starting with some basic business assumptions and how the Toyota Production System is defined. To quote the article:

The engine behind its success, say insiders and outsiders alike, is the Toyota Production System (TPS), a set of principles, philosophies and business processes to enable the leanest manufacturing.

And behind TPS is information technology -- supporting and enabling the business processes that help Toyota eliminate waste, operate with virtually no inventory and continually improve production.

Technology does not drive business processes at Toyota. The Toyota Production System does. However, technology plays a critical role by supporting, enabling and bringing to life on a mass scale the processes derived by adhering to TPS.

"What strikes me about Toyota is, if you were to ask them if they have a technology strategy, they would probably say no, we have a business strategy," says Philip Evans, a senior vice president at the Boston Consulting Group who has studied Toyota. "They have a very clear understanding of the role technology plays in supporting the business."

This strikes me, too, because I'm so used to focusing on the technology that the business case sometimes gets lose or the technology ends up driving the business case or obfuscating the business case. The sequence, however, seems quite clear at Toyota. But reading only this far, I thought for sure that this TPS thing must certainly be based on Toyota proprietary IP, right? It appears not. Later in the article you'll find this:

Unlike the formulas to blend Coca-Cola or the latest blockbuster drug, there is no veil of secrecy behind the Toyota Production System. In fact, Toyota openly invites general visitors and competitors alike into its plants to observe its operations and manufacturing techniques.

In 1992, it opened the Toyota Supplier Support Center in Erlanger, Ky., about an hour's drive north of the Georgetown plant, to teach other companies the principles and concepts behind TPS and to help implement TPS in their own operations. To date, it has worked with more than 100 companies as varied as office furniture maker Herman Miller, seat manufacturer Trim Masters and several hospitals. The supplier center now operates as an independent consulting firm.

It even created a joint venture with GM in 1982, taking a plant that was to be closed in Fremont, Calif., and reengineering it into a lean manufacturing facility based on TPS. That plant, renamed New United Motor Manufacturing Inc. (NUMMI), quickly surpassed all of GM's plants in North America in productivity, quality and inventory turns. NUMMI became a living laboratory for hundreds of GM executives and now manufactures Corollas, Tacoma pickup trucks and the Pontiac Vibe.

Toyota is open with the strategy behind TPS because it wants to raise its North American suppliers up to its own level of efficiency and quality, Liker says. At the same time, it can afford to be open with its competitors because Toyota is constantly raising the bar. By the time they copy its current processes, Toyota will have moved on.

So, the business model comes first at Toyota, and technology supports the business model -- not the other way around. Then both are packaged and implemented via the TPS, which is open and enables others to benefit while Toyota profits and drives its thinking deeper into the market. And Toyota is not worried about opening up its production processes because the company is confident it can out innovate competitors and, actually, the company would like suppliers to come up to its standards. Talk about confidence. My goodness. I think I'm going to cite this example the next time someone is worried about opening their code. This has an open community dynamic to it of sharing as well as competing.

The article goes on to explain the core elements of the TPS: Just-in-Time, Jidoka, Kaizen, Andons, Poka Yokes, and Genchi Genbutsu. To me, that last one in the list is the most interesting. According to the article,

The literal translation of this term is, "Go and see for yourself." Rather than hear about a problem, Toyota requires its workers, team leaders and executives to go and see a problem directly and to work collectively on a solution.

Interesting. So, there seems to be a community dynamic occurring internally as well as externally. There are several other examples of this in the article. If Toyota were a software company, I bet they'd participate in open source, don't you think?

Back to the article ...

Together, the elements of TPS form the basis for a system of business process management that allows Toyota to continuously look for ways to optimize its operations and put thought into action. Sounds simple, but it requires a basic cultural change in an organization, and that, according to Gary Convis, can be the most difficult challenge. Convis, chairman of Toyota Motor Manufacturing Kentucky, oversees the company's manufacturing plant in Georgetown, Ky.

By the way, after his promotion, this guy Convis moved his office from the administrative building to the factory floor. The chairman. On the factory floor.

So, why can't the American car companies tap into a system like this? It obviously works pretty well since Toyota just picked off Ford and is on its way to taking down GM. Why are those guys doing so poorly while Toyota (and Honda as well) are doing so well? Especially, when at least Toyota opens its processes? I think I'm just now beginning to understand what the answer is and why Toyota isn't afraid of opening those processes. Ok, the answer is obviously massively complex -- especially when you consider American union, health care, pension issues, and missing market shifts - but perhaps a few of these elements are involved as well: (1) openness can help build markets, (2) those who open some of their stuff end up leading within those markets, (3) and the culture of pervasive quality is almost impossible to copy because it leads to unique value every time it's implemented. And by "culture" I don't necessarily mean Japanese vs American. Yes, I think the Japanese notion of quality and service is somewhat higher than what most Americans can even imagine, but it doesn't have to be that way and it wasn't always this way in the past.

Now, the article is not all rosy for Toyota. In fact, the company has actually had some tough times lately with re-calls and quality issues. But most analysts feel that things are turning around, they have confidence in the company, and they still put Toyota quality way above that of their competitors. Nevertheless, "[a]t a news conference in July, Toyota president Katsuaki Watanabe bowed deeply and apologized for the recall troubles. 'I take this seriously and see it as a crisis,' Watanabe said at the conference. 'I want to apologize deeply for the troubles we have caused.'"

Bowed deeply and apologized. So, perhaps I should add a touch of humility to my little list of elements to consider.

Saturday Jul 08, 2006

Connected Capitalism

I love the term "Connected Capitalism" coined by Simon Phipps to describe how "open source works by everyone contributing what they want without compulsion and using what they need without restriction -- as a counterpoint to people who try to call open source 'communism'. Think Benkler."

That's a jam packed Simon quote from a comment he left to a recent James Governor blog about press coverage on Simon's keynote at OSBC a couple of weeks back. Ben Rockwood also has some interesting and valuable thoughts on the subject. Ever since I tripped over open source here at Sun about six years ago, I've been fascinated -- mostly because the culture reminded me of things I had seen in the past but couldn't really fully participate in. There is so much to talk about, but I'll just carve out my favorite little bit from Simon's comment -- connected capitalism.

I see a nice consistency between capitalism and open source. If open source were really about communism, as some detractors assert, I'd dump it pretty quickly. Not because of any political belief (I don't waste time on such issues), but because it would be incapable of providing me enough value so I wouldn't want to contribute to it. I'm looking to earn a living with multiple and diverse streams of income but in a way that contributes to the community (whatever community), not detracts from the community like the robber barons of times past (and some present, I suppose). If I don't have the ability to get something out if it, I'm gone. It's that simple. Food is important. So is health insurance. I have a significant amount of experience with the medical community, and I'm determined to have enough money to pay for as many circumstances I can imagine. And a steady flow of cash well into retirement should come in handy as well. So, my perspective is especially economic and I'm getting more and more focused on that every day. It's my primary goal, in fact. But I've never been a believer in the zero sum game, either, so that's why I like the concept, culture, and dynamic of open source. It's the perfect solution.

As an economic system, capitalism has done a lot of good and certainly provides some pretty massive incentives for growth. It has some pretty big holes, though, and many people react negatively to the term. Perhaps because used alone it can sometimes connote "big" and "exclusive" and "exploitive" and the connections supporting it generally pervade insiders -- the special ones, the privileged ones, the rich ones, the ones who control things like Big Oil, Big Unions, Big Education, Big Agriculture, Big Banking, Big Construction, Big Shipping, Big Government, Big [insert your favorite big thing here]. So, if that's the reason someone doesn't like the term, I can understand it. And, for the most part, I agree. Those things bother me, too. Breaking into some of those entrenched industries without paying off the controlling parties is challenging. Those industries are not communities whose members openly welcome new contributors, that's for sure.

I tried to break into the construction industry in New York as a small business owner, and, boy, did I learn a lesson in, ah, capitalism. My goodness. It had nothing whatsoever to do with open competition or competing based on talent, better pricing, better service, better equipment, better ideas, or better innovation. Instead, it had everything to do with paying to play in a controlled market, and it represented an absolutely stunning destruction of innovation and inspiration. I had to pay to enter the kingdom of those who had gone before and who were carefully guarding the gate to their paradigm -- at all costs. The controllers viewed their game as zero sum for sure, and I didn't fit in very well at all. In my case, I ran into several powerful construction and trucking unions (I was non-union), dozens of well-connected contractors (I didn't have their money), many government agencies (I didn't have political connections), and a few other rather strange characters (I'd rather not talk about). At times, the lines supposedly separating these groups blended all too closely, which was confusing and unsettling at best. The experience was both disgusting and exhilarating, and everything I believe today about economics and politics I learned from those early battles in the construction business. Back then I worked with some well-meaning business people -- true entrepreneurs -- and I learned all about what creative, innovative, talented individuals could build and how easily a powerful, centralized, controlling group could take it all away -- sometimes violently -- because the leaders felt threatened. I came to believe that open competition terrified people who contributed so very little..

I've always wondered about this though. In capitalism, why can't the individual and the community (or company, government, or union, or school, etc) benefit simultaneously so the cycle is self referral? To me, open source goes a long way to solving this problem because the culture of that system openly welcomes new contributions from creative, innovative individuals anywhere -- and the more the better. This is not necessarily exclusive to open source software development; it's probably present in other engineering and scientific disciplines as well. I sure saw it at Tufts University where I worked for a few years with physicians, veterinarians, and a variety of researchers. Heck, I bet any true craftsman or artist in any field would get this concept of individual, contribution, community. In other words, the community benefits but so does the individual contributing. In fact, the more one contributes, the more one benefits. It's that whole "you get out of it what you put into it" thing, and it supports the notion of enlightened self interest, which Simon rightly explains can be a problematic term but one I have no problem with (other than the fact that I need to assert it much more often). So, you enrich the commons and all the individual people within the community managing the commons benefit as well, and those especially hard working people have a limitless opportunity at their fingertips. Opportunity is there for all but it's proportional to how hard one works and how much one contributes. And around it goes. Generally speaking, of course. And by "enrich" I don't necessarily mean only in pure monetary terms. Rich means many things to many people: money, reputation, connections, access to shared resources, conservation, safety, insurance, learning, skill development, contribution, feeling of well being, donations, participation, desire to help others, etc. Simon explains all this much better, of course, but I'm trying to understand it based on my past experiences and on my future plans.

Now, elements of this absolutely remind me of capitalism -- but a very, very special form of capitalism. It's called entrepreneurialism. Small capitalism, I guess. Capitalism for the little guy. Capitalism the way it should be. Capitalism where everyone is welcome to participate and dare and risk. Capitalism that the old capitalists and the old communists would both have a hard time dealing with. That's the kind of capitalism I like. I just call it entrepreneurialism because my perspective starts with an independent individual being able to take care of him/herself so as not to be a burden but to do so by being connected so contributions benefit all. I think small entrepreneurs understand this more than big capitalists do (yes I'm splitting hairs a bit here) because the entrepreneurs usually start small and depend heavily on connections to others for resources, whereas those big capitalists tend to rely more on buying their way around since they already have lots of resources. It's certainly not true in all cases, but that's what I've seen along my way.

So, when Simon puts "connected" in front of the term "capitalism" it gives the entire principle a new, de-centralized, individual, empowering feeling and that's something every entrepreneur can understand. Hard work, perseverance, talent, skill, opportunity, luck. Not for Big Enterprise, but for the individuals who can't help but dream of what's possible. In this context, the term "connected" is critically important because it implies rather directly that for all this to work one has to connect to the community and help manage the stuff in the commons. Connected also implies responsibility, and if you are connected to people rather than capital it's more important that you do the right thing, not necessarily the most profitable and selfish thing. It's the connection to the community that creates the opportunity to create individual value, and that's what has hooked me. It solves my problem. I can be entrepreneurial without being a robber baron. The elite wouldn't understand this because they are not connected to anyone other than elitists like themselves. Whatever economic system they use in whatever society they live tends to exploit the commons, not contribute to it, and over time that pisses people off on all sides of the political, economic, and social fence.

"Connected Capitalism" works well for me. And I've yet to see a more powerful expression of the entrepreneurial spirit than the dynamics of a thriving community. Have you?

Friday Sep 23, 2005

Community Reactions

Sometimes people ask me how they should interact with the OpenSolaris community and how I think the community will react to various issues. This is difficult to predict, as I've come to learn (and am still learning). Many times it's just a person who has worked internally and wants to get used to the free flow of an open community conversation. That's pretty easy. But the challenge comes when people internally need to make difficult decisions that they feel the community many not agree with. What to do about that?

First, there's no need to pre-judge the communities reaction because you really don't know unless you directly and personally engage. Second, we need to remember that Sun is part of the OpenSolaris community now. True, we are leading OpenSolaris and sponsoring the project, but the process of making decisions within a community is quite different than making decisions in a closed system. The process of opening should be to engage with the external community and consider their ideas and needs right along with ours here internally. Now, we're the ones doing the opening (and there's a lot to open), so a lot of the discussion internally is based around how to open our own processes, which is understandable. But in general, if we are serious about building a community -- and we are -- more and more of our decisions should be made by involving the community -- internal and external -- as much as possible. You can see this beginning to happen on multiple lists, and over time it will only increase as more of what's in Solaris is opened.

So, this is what I tell people ... if someone at Sun has to make a business, legal, or engineering decision that the "community out there" may not like, then that decision should be made after engaging in an open conversation on the project's lists. There are exceptions, of course, but that's the direction we're moving. I'm finding that open conversations can actually move faster than closed conversations because the group self selects and there's less politics.

In general, we are trying to publish documents early to engage more of the community at Sun and outside Sun. Some well meaning people internally are sometimes concerned that this may bind the company to something or mean the company has to adopt every change the community (internally or externally) wants. This is a legitimate concern but fairly easily addressed. My feeling is that documents are published as drafts intentionally, so community members can participate in the creation of those documents (or processes or decisions or whatever) as much as possible. So, it's a process of leading an open discussion to come to a better, more inclusive, more focused decision. People leading the discussion need respond to feedback, consider all reasonable opinions professionally, and actually engage in an iterative process. In other words, emails going back and forth on list for everyone to see. If you have to do something that may be unpopular even after this process, at least everyone was involved and had a say up front. In other words, you have to talk to people and consider their views and articulate yours. Hopefully, learning goes both ways when this works. You can't fake it, by the way. It's pretty easy to spot. But as a practical matter, what usually happens when you engage the community early is that the initial idea is flushed out more thoroughly and everyone wins because everyone participated.

We have early drafts of the Governance, Charter, and development process definitions, as well as various development meetings (here, here) out in the open for feedback and participation. Anyone in the community at Sun or outside Sun can comment and be heard. It's the only way to be heard on these issues, actually. Now, there's a great deal of work to do on these governance and development processes documents, but when they are completed and implemented, it will be the OpenSolaris community that was responsible for the decisions. That's what we are shooting for.

Saturday Jul 30, 2005

The Art of Managing Projects

Nice little podcast here with Scott Berkun, the author of The Art of Project Management. It's really short, so give it a listen if this stuff interests you.

What's nice about Scott's take on project management that it seems quite realistic. Which is refreshing. He takes things like politics, power, execs, and egos seriously when he talks about managing projects, developers, schedules, budgets, and everything else that comes into play. So much to learn. He's got some interesting stories from Microsoft, too. :)

Scott's web site is full of resources for project managers. I'm participating in his PM Clinic forum now. It's interesting to exchange ideas and information with other PMs across the industry.



« July 2016

No bookmarks in folder