Wouldn't it be nice ...

People were so busy complaining about my pie chart that most of them apparently didn't have a chance to think about the meaning of the actual data. To try helping people look at the information rather than its presentation, here's a bar chart of the same information:

I don't recommend looking at it because you may go blind, but I've made available the (extremely ugly) script that created this.

I ran a quick, informal poll on the internal Gentoo developers' list last week, and tonight I began analyzing the results. 50 developers responded to my 9-question survey, and I'm going to post the results of 1 question at a time.

First question: What are the top 3 issues facing Gentoo?



Technical issues are way down on the list. Developers' top 5 issues are manpower, publicity, goals, developer friction, and leadership. It's good to see that we've been addressing at least a couple of them with the newly energized public relations project and work on the Code of Conduct. Other issues that have been ongoing for quite a while now are the lack of distro-wide vision and goals. The Council could provide those by increased activity and taking stronger stands in particular directions, and that's part of the reason I did this survey—to figure out which directions our developers care about. I think part of the problem is that nobody sits around pondering directions and ideas. Everybody's busy working in their own little areas and not thinking about the big picture. Manpower, or lack of it, is another issue I'm indirectly addressing in my push for greatness, which I'm going to post more about at some point (I promise!).

To create this chart, I used Google's excellent chart API. The neat part about the API is that it's simply a URL, so you can construct it with any language. I used a shell script since I was already fiddling around with awk. Any answer with less than 4 respondants was grouped into Other to make the rest of the chart readable.

This won't be a long post, because I'm tired. Sorry for the dearth of posts on here, but I've been busy writing other things—see below.

For anyone who hasn't heard, I took over as lead of Gentoo's public relations efforts a little over two weeks ago. Three days earlier, I wrote an LWN article concluding that Gentoo isn't falling apart, but it's totally failing to communicate. After writing that article, I realized that somebody had to step up to deal with this problem—who better than me?

My focus right now is showing people that Gentoo development is just as alive as it's ever been. I'm doing this by opening windows into development through more frequent news postings, with links to discussion forums to respond to the posts. Doing this, combined with writing to people ("You will") rather than about them (saying "Users will..."), will help build better relationships with our users.

Another part of improving the perception of a lively, active community is updating the look of our website. The old website redesign never made it to fruition, so a few of us have begun taking a look at how far it got, what happened, and what to do now. At a minimum, I'd like to make some slight changes to give our site a face lift. The design hasn't changed for 6 years now, and it shows.

One major, easily fixable problem with our website is that there's no obvious place to go for users who want to contribute. There should be a big "Get involved!" or "Help Gentoo!" link right up at the top of the page, next to "Get Gentoo!" All this requires is a little webpage that describes all the ways people can help. In fact, the whole website isn't task-oriented enough. This needs to change.

In the future, I'm going to begin improving the "press" aspect of PR, based on my notes from an excellent talk by Josh Berkus at OSCON 2006 on public relations for OSS projects. The main ideas here are providing a press kit for reporters with all the basic info they want, building relationships with local reporters by using local Gentoo contacts, putting together some case studies of people and businesses using Gentoo in interesting ways, and improving our process for creating and posting news and press releases.

Finally, any Gentoo users can help improve Gentoo by simply advocating it to Linux users you know, giving demos and talks at Linux user group meetings or conferences, promoting it in articles, or writing in your blog about something Gentoo does really well.

That's a question a lot of people have been asking lately, with the news about the nonprofit foundation, the lack of news updates on the homepage, and the canceled release. I answer it in a short LWN article.

Gentoo is good. How do we make it great?

Over the past year or so, I've read a few books, and I want to use those ideas to build a better Gentoo. The books:

• Good to Great, by Jim Collins


• The Five Dysfunctions of a Team, by Patrick Lencioni


• The Art of Project Management, by Scott Berkun


• The Power of Focus, by Jack Canfield, Mark Victor Hansen and Les Hewitt

I plan to write a short series of posts discussing the lessons in these books and how to apply them to Gentoo. In this post, I'm going to summarize the concepts of "Good to Great." I'll discuss how we can apply them to Gentoo in a later post. The book explains what it takes to transform a good company into a great one. It's a comparison of companies that made a transition from good to great (thus the title) with companies that remained merely good. Jim Collins and his group reduced the differences to a remarkably small set:

• Level 5 leadership: The leaders of great companies aren't charismatic, big-name CEOs. They're humble, and their ambition is for the company, not for themselves.


• First, get the right people: Before you decide what to do and where to go, get the right people in the right spots. Otherwise, you've got the wrong people creating the wrong vision, strategy, etc., which the right people are then forced to implement. Concrete implementations:
  
  
  
  • "When in doubt, don't hire—keep looking. (Corollary: A company should limit its growth based on its ability to attract enough of the right people.)"
  
  
  • "When you know you need to make a people change, act. (Corollary: First be sure you don't simply have someone in the wrong seat.)"
  
  
  • "Put your best people on your biggest opportunities, not your biggest problems. (Corollary: If you sell off your problems, don't sell off your best people.)"
  
  
  
  The right people have the right innate abilities and character traits, not necessarily the specific knowledge and skills. For example, look for work ethic, dedication, and problem-solving ability, not ebuild-writing skills and knowledge of bash.
  


• Confront the brutal facts: Don't deny reality, or you can't make the right decisions. To do this, create an environment where everyone can be heard, so the truth can come out. Don't lose faith that you will win eventually, but accept the reality of now.


• The Hedgehog Concept: Only do things that overlap in the three circles:
  
  
  
  • You're passionate about it
  
  
  • You can be the best in the world at it
  
  
  • It drives your resource engine
  
  
  
  The resource engine is a combination of time (how well we attract contributors), money and brand (how well we create a community), drawn from an accompanying monograph for the social sectors.
  


• Build a culture of discipline: Create a culture of self-disciplined people who are "fanatically consistent with the three circles." Bureaucracy arises to compensate for incompetence and poor discipline due to having the wrong people. If you've got the right people, you don't need the bureaucracy.


• Technology accelerators: If a new technology fits into your Hedgehog Concept, become a pioneer. If not, settle for decent, or drop it altogether if you can.


• The flywheel and the doom loop: Transforming from good to great is not quick. It's a flywheel, slowly building momentum. From outside, all people see is the breakthrough, but from inside there's a prior buildup. Merely good companies couldn't build momentum—they jumped around from focus to focus, never getting anywhere with any of them. You don't need to spend effort getting people behind your idea. Show them the results, and they'll follow you.

That's my ranking in the "Top Linux blogs," according to Don Marti. I'm a little confused how that happened, given how rarely I've blogged lately. Perhaps he knew I had some more good ideas in the pipeline. =)

I recently posted about making Gentoo a better tool. A requirement for being a good tool is being a tool that doesn't break—thus, we need to improve our quality to a more reliable level. I'm going to mention a few ideas to start this discussion, which I hope the rest of our community will participate in.

First, we essentially have no code review. About the only time any code in Gentoo is reviewed is before and during a developer's training, with a notable exception being the requirement to post eclasses to the gentoo-dev list. Increasing our code review ought to result in an increase in quality, in ability to justify code in words, and in a stronger community of contributors.

How do we increase code review? One idea is to require reviewer approval prior to committing, but this isn't the best answer for Gentoo. We've always been a pretty open community. Developers aren't prohibited by ACL from committing anywhere in our ebuild repository, so I don't think they would accept additional requirements that increased the burden of contributing.

Instead, let's create a gentoo-commits mailing list or RSS feed(s), with full diffs. We should use this tool in many different ways.

• Each team should use it internally to review all commits to its packages.


• Mentors should continue to follow their mentees' commits well after they're granted commit access (6 months minimum, and I recommend forever).


• Mentees should also review their mentors' commits, first to learn and later to review.


• Every developer should have at least one reviewer and review at least one other developer. This should be formal and documented to ensure it's happening.

These uses will require that the commit diffs be easily filterable by both committer and files affected. RSS feeds could be made available based on developer or herd, and e-mail lists could contain the information in e-mail subjects or headers.

Second, we should improve our unit testing, where the units are individual packages. This can be both automated and performed by developers and arch testers. Although a number of packages have a useful, working test suite, most lack one. For these packages, we should attempt to provide something automatable in src_test() even when a test suite is absent. Failing that, we should print out a checklist in src_test() of tests to perform before stabilizing a package. There should never be an empty src_test().

Another package-level testing approach is to create solid, automated tinderboxes. This remains unrealistic for our entire database of 10,000+ packages, but we should at least get this going for our "system" set and perhaps for some of the most common sets of packages for servers and desktops. Exactly how to set this up remains a question, since there's a lot of tinderbox code floating around. Bonsaikitten has some almost-working code based on swegener's work; Catalyst has some tinderboxing capability; or we could look into using Mozilla's tinderbox.

Third, we should improve our integration testing, on the entire repository level. Our main source of testing here will be our users, because they have infinitely more combinations of build options and hardware than we can reproduce on Gentoo infrastructure. But how can we take advantage of this testing to improve our quality? By creating an additional, time-lagged set of rsync mirrors with additional QA checks, we could allow users who want to test the latest and greatest software to help those who want stable and solid software.

We already have keywords for ~arch and arch, but they're still too mixed. A problem in ~arch ebuilds can break the entire tree for all users. They really need a stronger separation. Perhaps the separate repositories should be ~arch versus stable. But another way to do it is to add a delay to the second set of repos, anywhere from 24 hours to a week. This delay allows us time to encounter major problems in the fast-sync repos, fix them, and carry the fixes over to the slow-sync repo. But we'll need a way to make this really easy to do. It feels like branching with periodic merges, along with cherry picks of major bugfixes, is the right way to do this. Unfortunately, CVS sucks at this. We may need to migrate to a more capable version-control system before this option becomes realistic. In addition to the user testing, we could add a tinderbox into the slow-sync repos to require that they build with the most common configurations.

To sum up, I want to increase code review, unit testing, and integration testing. These three things will strengthen Gentoo's quality, reputation, and community.

Reading the PressThink blog, I came across a couple quotes that apply well to open-source projects:

I kept thinking about a famous passage from Christopher Lasch, the great social critic and historian who died in 1994— before the rise of the Web. In the Revolt of the Elites, he said we learn more from argument than from information, not because opinions are weighter than facts, but because to argue for your ideas (in public) puts those ideas at risk. And that is how we learn. ...

Lasch in his book:

If we insist on argument as the essence of education, we will defend democracy not as the most efficient but as the most educational form of government, one that extends the circle of debate as widely as possible and thus forces all citizens to articulate their views, to put their views at risk, and to cultivate the virtues of eloquence, clarity of thought and expression, and sound judgment… small communities are the classic locus of democracy— not because they are “self-contained,” however, but simply because they allow everyone to take part in public debates. Instead of dismissing direct democracy is irrelevant to modern conditions, we need to re-create it on a large scale.

If any of you are LWN readers and would really like to see coverage of any specific sessions or topics at OSCON, please leave a comment on here and I'll see what I can do.

I'm giving a short talk at OSCON next week on Gentoo's progress in the past year. So please comment on my blog to let me know areas you want me to cover. I'm open to any and all ideas.

Thanks!

BTW: Anybody living near Portland got a couch I could crash on Tuesday, Wednesday, or Thursday of next week (July 24-26, 2007)?

Gentoo is a metadistribution, meaning you're supposed to built whatever you want with it. And we provide some of the tools to make that a reality, but we stop short. We still make it too hard to do what you want with Gentoo. Here's some of the ideas I want to explore over the next year:

• Increased binary package support: We already have an experimental tinderbox setup to build packages for a variety of architectures. I want to investigate increasing our collection of binary packages to make a fairly complete installation possible using only binaries.


• Repositories for user-created distributions: We have tools like Catalyst to create basic installations with stage3 or stage4 tarballs, but it's still hard to get what you want with them. We should make a repository of Catalyst spec files for a variety of purposes, and we should also add an accompanying mirror of the created tarballs so anyone can use them. We could also revive the Seeds project to create not just vanilla stage4 tarballs but fully fledged, preconfigured installations customized for specific purposes like LAMP servers, development machines, various cluster nodes, GNOME/KDE/Xfce desktops, etc. We already have the possibilities; we need to share our tools.


• Creating the Gentoo metacommunity: In addition to letting you create your own distribution from Gentoo, I want Gentoo's community to be what you want it to be. We're in the middle of adding a few new mailing lists because our primary development list is drowning in noise. We made gentoo-project for non-technical general talk and gentoo-dev-announce for development-related information so developers don't need to slog through gentoo-dev. I want to take that a step further by forming stronger Gentoo microcommunities around specific areas and moving discussion about those areas to their IRC channels and mailing lists. Our development community has grown too big to keep everything on a general development list. Everyone tries to chip into every discussion, even if they have no relation to it or are unaffected by it.


• Excellence: Gentoo's QA is not the greatest. What can we do to improve this? Some automated tools exist for pre-commit checking; can we add anything server-side? Can we add some build servers for critical system packages, so they don't make it to users before building in a predefined set of common configurations? Can we improve our developer recruitment or add new training for existing developers? How can we renew and strengthen our commitment to excellence? You can't create a tool with Gentoo if it's broken.


• New tools for new places: This is more of an exploratory idea. I'd like a team of contributors to research all the places people use Gentoo, and put together a collection of tools we're missing. Further, we need to do more extensive research on other distributions to see what sorts of tools they have that we lack. I have no symptoms of NIH syndrome, so I'm happy to pull in working tools written for other distributions; I already did this for many of Fedora's system-config-* tools last year.


• Resolving the meta vs. specificity conflict: Gentoo's status as a metadistribution sometimes produces conflicts between the goals of various projects and teams within Gentoo. Sometimes a person simply needs to make a decision of how to deal with it: pick one, or find a way to do both? Many people remarked over the past couple of years that we're lacking strong leadership and overarching goals, which would give us some consistent way to decide which projects will "win." As Seemant has said, Gentoo is a framework, a metadistribution, not a place that forces people to go a certain way. We should strive to enable contributors to follow whichever path beckons to them. But where is Gentoo going, and where should it go? You decide. The innovators and leaders can only suggest places for it to go, so the rest of the community has to follow them to our destination.

Scientific American has a superb Web site, and I've been subscribed to its weekly updates for quite some time. Today's update included a story called "The science of team success" that talks a lot about what can make teams fail or succeed. It references a branch of psychology called organizational psych., which is pretty much all about this. Can anyone suggest more reading on the topic?

I facilitated this discussion, which is why my notes may suck more than usual.

Accountability

Online consensus?

Structures?
- Hierarchy (org charts)
- Total democracy, or representative
- Dictator, active or inactive

Effect of using a distributed SCM on governance?

Respect is critical to being listened to ...

The importance of people who are catalysts (why? no clue, but they make things work). What motivation do they have to volunteer? The gratitude of others.

How to keep communities close-knit as they grow?
- Manifesto saying what's acceptable, with an enforcer!
- Create smaller communities
- People to connect these communities
- One person can ruin an entire team: vetting new community members
- A "boot camp" for new members to intensively indoctrinate them to the social norms
- The buddy system: mentorship

Book: The Tipping Point

Dunbar's number: maximum number of people who can work together. 150 to 300, depending on how strictly they're indoctrinated

How do you tell whether someone's really indoctrinated to the social norms? What criteria?

Much smaller group this time ... about 15. People from 2-person startups, Microsoft and anywhere in between. Some from tech, some from biz, some consultants ... I'm here to think about what it takes to start my own business (not now, but who knows?).

Issues: growth, fundraising

How do you decide where to take your business? Where do you get the info?
- Personal experience of making and watching mistakes, not so much market research
- Customer surveys, combined with a newsletter asking for feedback and building community
- Build community so customers do marketing for them
- Tiny percentage responded to newsletter, 15-50 of 4000
- Targeted survey to 150 users (of 4000) got about 50% response rate
- How do you connect others' business experience with your business?
- Enterpreneurs' forum
- CEO roundtable: get small biz owners together over meals
- Successful people in business meet, swap ideas that worked, discuss biz plans & needs
- Business Enterprise Center: incubator provides space, mentorship
- Bring in various experts in legal issues, accounting, etc to talk
- Choosing to build a business around yourself and your reputation vs a company reputation
- Even the name of your company depends on this
- Lifestyle business (you can leave whenever you want) vs having employees, etc.
- The people are the value, when they leave there's no value left
- Small companies working with small companies or big companies?
- How do you build a consulting business that isn't a lifestyle business?
- Growing without relying on just your personal reputation
- Locking into models
- If the model requires a certain technology, it can't last forever
- Flexibility
- Do what you're good at
- Outsource finances, etc. Time vs money
- Your time is best spent on your expertise
- You drop way too much time on things you're unfamiliar with
- In the same way, use the tools you're familiar with
- CFOs from big businesses can run small biz into the ground
- They don't understand the urgency of time and the shortness of money
- Online database of information and experience from other owners?
- Trust issues
- My thought: show me the data, and I can draw my own conclusions (i.e. Fred Brooks)
- Ratings? Wiki-like model?
- What questions do you need to ask for a business plan? A list ... inspires thought

Dawn Foster, one of the BarCamp PDX organizers, is facilitating this discussion. She's interested in how people build communities.

How is collaboration changing within communities? Moving from mailing lists, newsgroups to blogs, wikis, forums ...

Face to face (F2F) interactions build more trust than you get online.

How to bring non-technologists into online communities? Knitting is one of the biggest of these.

People treat each other differently F2F than online. Educating newer generations in social norms, cultural differences, etc all play a role.

How do you find forums moderators, e.g.? Let people who might want to contribute know where you need help. Not just technical but someone to set the expectations for community norms. Important to create a sub-community for the moderators.

Communities self-organize their structures more than being placed into a hierarchy.

Network weaving: intentionally creating tighter and more connections within groups. People apparently do this for a living?

Building a strong community, from a corporate standpoint (or any project), means that people have got your backs when bad PR comes up. Give trust to your community, and they'll reciprocate. Companies have done this forever as product advisory councils, which also provides a beta testbed.

Building an internal corporate community is required before you can build a strong external community. And letting your internal engineers or whatever hear real customers firsthand sometimes makes the difference. Connect the creators to the users.

Business models move more toward ecosystems and away from your traditional corporate structure. Away from a two-state system and toward a spectrum -- no longer just producer vs consumer.

When do bloggers become marketers? Are they still impartial if some company pays them to blog about its products? Does it matter?

More stuff. Funny relevant comic at http://xkcd.com/c256.html

I'm going to post my notes from the BarCamp Portland sessions here.

Packed room. We started out brainstorming one word each that's related to the user experience. Ideas include: results, easy, story, predictable, relevant.

Startups: Don't be afraid to throw some UI paradigm away. Your users may hate it, however much you love it.

Does gradually changing the UI work, or piss people off? No consensus.

Techies are really bad at pretending to be the naive users, so test it on real users!

Accessible interfaces as secondary UIs are different and need to be tested as such.

User personas are caricatures of reality and don't model true users well.

And then we ran out of time...

I just posted this to the Gentoo development list, but I thought other projects could use a similar idea so I decided to add it to my blog.

Hi all,

I'm sure I'm not the only one with a number of projects I'll never get to, but I'd really like them to happen anyway. I suggest we create some sort of page that aggregates all of these personal projects together, so anyone can browse through them and look for stuff that sounds fun.

The goal is to increase contributions from outside by giving them a ready list of projects of all sizes and difficulty levels to work on, projects that go beyond what happens at Bugday. Further, it could also help current Gentoo developers who are bored or have lost interest in what they're doing by helping them to find somewhere new to contribute.

A prototype with just my projects is at http://dev.gentoo.org/~dberkholz/proj/

Thanks for your comments!
Donnie

Remember when I posted about searching techniques? A blog I read with news ideas for tomorrow's paper taught me about a search site called ChaCha, where you can actually search with the help of a human guide. Very cool way to take advantage of the experts to help those who aren't so expert.

The deadline for proposing ideas for OSCON talks was Monday at 11:59 p.m. Naturally I clicked Submit for the final time not long before then, at 11:56 p.m. Note I said "final time," implying more than one—I decided to go all-out and submit three ideas, in hopes that at least one will slip through. For the curious, they are

• Design and publish beautifully and professionally: How to create a professional-looking document, using Scribus and Inkscape. Many people who read this probably don't realize I spent four years working as a page designer and copy editor at newspapers. I continue that interest today as editor of a newsletter about open-source activity for the Open Source Educational Laboratory at Oregon State.


• Community dynamics in a large open-source project: Problems, solutions and conundrums in Gentoo. The funniest (and saddest) part is when the same things begin to repeat themselves, and nobody else remembers last time it happened.


• Open-source software in the biosciences: Where we are and what we learned on the voyage: The cruel joke of scientists as programmers. As a grad student in biochemistry at OSU, I've had to deal with more ugly software than many of you can imagine. But at least more of it is open source now, right?

Anyone else submit proposals? I'd be interested to hear what they're about.

I've been reading a series of posts about sensemaking on the Creating Passionate Users blog, and part of it (perhaps the part on intuition) reminded me of IQ tests. Why, you ask? Because every one of those quicky IQ tests I've taken that you can find online or at the bookstore has basically two components: a weird amount of trivia knowledge (vocabulary, etc) and pattern recognition. Is that really intelligence?

In my experience, a large part of being able to recognize a pattern is experience, or seeing something like it in the past. In the same way, past experience influences my searching strategy. I'm the guy people ask when they're trying to find something online, because I do a better job of finding what they want than anyone else around. I think the only reason I do this is because of my experience—I recognize the kinds of phrases people would use, and I tie together fragments of remembered knowledge. For example, instead of searching for what people ask me about, I search for what I think they're actually looking for. See any parallels to stuff like UI design? Jon Udell blogged about trying to teach people how to become a good finder by following his thought process. But I think that's impossible, because nobody possesses the same skill set and the same knowledge.

In summary: past experience determines future success.