In one of my previous posts, I'd commented off-hand that the Indian F/OSS community doesn't have enough rockstars. But that by itself blossomed out into a rather heated debate on #linux-india, mainly because we never got to hear lawgon's wisdom on what actually is lacking in India. The debate was more tilted towards the effects of the so called "rockstars" than their origins, causes and well ... mating habits (Freud made me do it !).
But before you actually read this blog entry, I'd advise you to watch Kathy Sierra's talk from LCA '07. You can download it from here [101 Mb]. I'll be borrowing some of her terms and ideas because they talk about how people get involved and become passionate users.
Burn Through the Zone: Success is often a matter of persistance. Most people hit the "Why Bother" phase in the first few weeks of trying something new. But what keeps the persistant folks going is the knowledge of an attainable goal, a sort of beautiful picture of "what could be". The so-called "rockstar" of the community is on such a pedestal of achievement. Bereft of such an example, there will be hundreds who hit their first snag and quit - people who are capable, but don't see it worth their effort. Or maybe they just ran into the "I suck" zone, in Kathy Sierra's words (or well, pictures).
The rewards for being good at something have to be obvious and evident for people to try their best - therefore they work hard and succeed - which is a circular argument from the outside. After all only an idiot would set himself on a mission with no goal and idiots aren't our target audience here.
Emulation Mode: The biggest problem people have with this concept is that a rockstar lends hiself to emulation, producing fad-followers rather than future leaders. But the whole basis of human culture and learning has been mankind's ability to recognize a good thing when it sees it and of course, to imitate by whatever means available. You learn more by doing than seeing and the obvious way to gap that bridge is to attempt what the other idiot/genius is doing.
The right people will split out of pure emulation mode very quickly, as they realize their innate urge to do their own thing. And in any case, people who can follow in a clear (albeit beaten) path are still valuable to any community. I personally prefer them over the self-propelled idiots :)
"Coolness" factor: During the formative years of your life, for a large number of reasons, you do what's cool. The urge to stand out or blend in, as the need be, is something which primeval and probably the conflict of which is the essential misery of man. The effect of the rockstar (who by definiton is cool), is to add an aura of coolness to the act of contributing to something. But for some strange reason, coolness is unacheivable in a group of peers.
The rockstar himself is part of the coolness ying-yang as well. In the real world, without a suitable audience to shower admiration, the hacker has nothing to aspire to but some obscure achievement in a world of peers who would rather play down your work compared to theirs. I think jace had called it the Great Wall of 'So What ?' - where anything you did can be dismissed by these two magic words.
The hard part of being a rockstar is not to put up such walls when someone new comes into the community. Trivializing someone's work is hardly a great way to welcome someone into a group and can be perceived as an outright dismissal of someone's hard work. And indeed it does happen to every other developer, at some point or the other.
Honestly, half the "Because I can" people are into it because it's cool ;)
Beacons: In a community with an insanely large number of potential contributors, it is nearly idiotic to try to seperate the chaff from the grain by brute-force. A rockstar by this definition is an evangelist by action and a touch-point by reaction. A prominent figure outside his or her area of action attracts a lot of potential talent who can then be nudged towards potential mentors who have the time & talent, but not the visibility.
Such rockstars, who inspire/guide/find contributors are required for any community. They are the glue that holds together the gears that drive the community (oh, I kid ... I kid). They are like tiger in the jungle, their visibility & influence indirectly showcases the community - to those outside the community.
Communities grow anchored to such people - their visibility and the ease with which they can handle that is a valuable asset to the community. But it is possible to overdo it as well - you know the examples ...
--The key to building a superstar is to keep their mouth shut.
-- - Bob Ezrin, rock music producer
posted at: 06:40 | path: /observations | permalink |
APC 3.0.14 (code named "A bigger boy made me do it, sir") went out a couple of days ago - read the release announcements. The major things in the release is a fair bit of performance improvements for those don't use threads. Also I've figured out a quick way to limit memory fragmentation when APC user cache (apc_fetch/_store) is heavily used - the new fraglimit fixes should solve all the small fragment issues with 3.0.13. And following my recent obsession with drawing pretty graphs for everything, here's how the old version looks compared to the latest code (requests per second for an include_once benchmark).
To get to such levels of performance, the code has some configuration parameters that can be set. The apc.localcache creates a process (yes, not thread) specific lockless cache which is basically a layered shadow cache ontop of the same shm data. The apc.include_override_once is also now usable because of the appropriate checks put in to reduce the overhead of include_once. And now, when you enable apc.stat there's a bit of code which pre-computes the path of the included file so that it can be effective for includes with relative paths or from include_path dirs.
The release is hopefully stable enough to provide someone with enough ramp-up time to get started, if I stop working full-time on APC. I've spent a fair bit of time stabilizing basic functionality and have kept most of these optimisations optional, to be able to look at other work for a while.
--Periods of productive stability, interrupted by bursts of test-bed change is much less disruptive than constant ripples of change.
-- Fred Brooks Jr, "The Mythical Man Month"