Posts Tagged ‘community’
The latest drama sweeping across the open-source world is Canonical’s decision to redirect affiliate profits from music bought in the Banshee music player from 100% GNOME to a 25%/75% split (with Canonical receiving the majority). Nearly everyone has come out against this, but I disagree with parts of their argument. Also, everything I’ve seen has involved verbal wrist-slapping instead of concrete action, so I’m going to propose some possibilities.
“Open source” doesn’t mean “open source until someone makes a change you don’t like.” The whole premise of open source is that anyone can make any changes they want, they have the freedom to fork, and nothing restricts their actions besides copyright. Do we have a right to be angry at people who take advantage of the freedoms we’ve offered them? I don’t think so, but I see where people could disagree.
But what options does that leave anyone who wants to change the situation? Here’s a couple:
- Banshee has a trademark; enforce it. Make Ubuntu change the name of its music player to something else. This would involve talking to lawyers and definitely takes this confrontation to the next level. If Banshee doesn’t already have legal contacts, its developers might contact the GNOME Foundation and work through them, or get in touch with SFLC or another legal team of their choice. If you want your code used in Ubuntu, maybe the name change is enough. But you’ll obviously lose the name recognition.
- Banshee developers could treat Ubuntu as an unsupported configuration and refuse to work with affected users. For this to have any chance of working well for Banshee, it must require its developers to consistently place the blame on Canonical every time problems get reported, to preserve Banshee’s reputation. However, if you don’t support Ubuntu or its users, remember that most bugs aren’t specific to Ubuntu so you’re also hurting yourself. Furthermore, this could provoke Canonical to drop Banshee altogether and switch to a different player. I’d expect Canonical’s decisions to be based on a combination of usability, access to upstream support, and revenue, so its choices will likely try to find a balance of those factors.
- Banshee developers could use rational approaches to convince Canonical its existing terms are inconsistent with the broader software world. OpenSUSE community manager Jos Poortvliet made a great point: “Even Apple doesn’t take more than a 30% cut from people who ship applications through their App Store.” However, this is the next level beyond that; Apple’s recent move to take a 30% cut of subscriptions, books, etc sold via App Store applications is far more equivalent. And this move, even by Apple, is seen as largely negative, but they’re staying the course much like Canonical. If I were Canonical, I’d ask myself how much my users love me compared to how much Apple users love Apple, and adjust my portion of the Banshee revenue accordingly.
I favor the third approach, but you should always keep in mind the best alternative to negotiation, so everyone on both sides of the conflict knows what will happen if negotiation fails.
Similarly, you need to quickly build the same level of trust with our community. Do you have the tools it takes to hack into the code? and do you know how to use them? When a contributor uploads a patch to our mailing list or to our tracker (preferred, but to make sure you get noticed please post a link on the mailing list too) he builds instantaneously the same level of trust that the unknown cab driver builds with every new customer: he implicitly shows that he has the tools (hardware, operating system, internet connection, coding environment, repository access) and that he can use them for basic operations.
I think you should fire this person immediately. Okay, maybe give him exactly one warning.
You’ll find someone else who really knows this stuff. No doubt about it. And firing one intransigent bully is a lot less painful than shutting down an entire division next year because he paralyzed your decision-making.
Deep technical competency is overrated compared with the ability to make excellent decisions and to create a culture where forward motion is valued and personal initiative is rewarded.
The good news is that the bully knows this, and the only reason he gets away with being a bully is that he thinks he’s got you bluffed. Call his bluff and odds are you’ll have a much more cooperative team, top to bottom.
I wrote an LWN article called “Google’s Summer of Code: Past and Future.” In it, you’ll learn:
- Why your project should apply to the program
- How big the program is likely to be this year
- A major change for the 2009 session, and
- A pointer to a valuable resource for mentors.
LWN is my favorite source for the best Linux and open-source news. They write original articles and also spend a lot of time searching all over the Internet for all the latest news so that all I have to do is read it. The reader community is fantastic, too. Subscribe to LWN today!
Invariably, groups that had the bad apple would perform worse. And this despite the fact that were people in some groups that were very talented, very smart, very likeable. Felps found that the bad apple’s behavior had a profound effect — groups with bad apples performed 30 to 40 percent worse than other groups. On teams with the bad apple, people would argue and fight, they didn’t share relevant information, they communicated less.
Even worse, other team members began to take on the bad apple’s characteristics. When the bad apple was a jerk, other team members would begin acting like a jerk. When he was a slacker, they began to slack, too. And they wouldn’t act this way just in response to the bad apple. They’d act this way to each other, in sort of a spillover effect.
Lots of good stuff, including this gem:
Firing people isn’t just about saving money, or petty things like that. It’s the difference between a great organization and a failure. Ineffective people drag everyone else down to their level. They make it so that you can’t take pride in what you’re doing, so that you dread going into work in the morning, so that you can’t rely on the other pieces of the project getting done. And assholes, no matter how talented they may be, are even worse. Conversely, there are few things more fun than working hard with a really nice, talented group of people.
I laid out part of a framework for improving Gentoo in my last post. As many of you kindly noted, I explained what I wanted to do but did a poor job of convincing you why it needs to happen. That’s what I’m going to begin doing in this post.
As this post’s title says, when you develop code, you generally want it to be the best code possible. You also want to improve it over time if it’s not yet up to the highest standards. This holds doubly true when you’re doing this for free in an open-source project. First, there’s no time pressure to pound out minimally working code, so you can take the time to make it beautiful. Second, everyone else can look at your work, so you can’t hide ugly code in a dusty corner somewhere as you might be able to in proprietary software.
These same concepts hold true for you, not just your code. When you’re contributing to an open-source project, everyone sees what you do and how you do it. Strive to make yourself beautiful in the context of open-source development. What’s that mean? Always challenge yourself, grow as a person, and learn new skills. Just as beautiful code perfectly suits its purpose, beautiful developers perfectly suit their purpose. Their skills and actions exemplify how open-source developers should act.
If you’re optimizing code, you know that you can’t optimize what you can’t measure. That’s why profilers and other methods of instrumentation exist. This concept has a parallel in your personal development. Your instrumentation is goals, and what you’re measuring is your performance against your own goals. The purpose of this, as with code, is to optimize performance for your relevant metrics. How do you know whether you’ve improved unless you’re profiling yourself? What you’re left with if you don’t set goals and track progress against them is that frustrating comment people always say, “It just feels faster.”