I scour Planet Gnome and Planet KDE daily as part of my duties as official free software guy at $work. For months I've tried to answer several questions:
- Why do things appear to move so quickly?
- Why are there so many participants?
- Why do their projects and sub-projects get so much attention?
- What can we learn from them?
I realize that making comparisons is reasonably silly, but I can't shake these questions. Also, the easy answers ("People care more about shiny GUI applications than programming languages") are full of empty calories. The correct answer may even be "Your perception of their progress and the Perl world's lack of apparent progress is wrong."
I don't expect to have any answers soon. I just thought they were interesting questions.
my $opinion;
phaylon on 2007-01-03T22:32:58
I'd say it's a modified version of the first: "You can't compare applications and languages." Developers seem to tend to contribute more to application projects than languages. In fact, one of the things I like about the Perl way is that CPAN tends to smoothen the line separating both.
Yeah, apples and oranges
Simon on 2007-01-03T23:11:19
I'd agree that you can't compare. The major difference is that Perl activity is the sum of the people working in Perl and the people working on Perl, whereas with an application, you're just looking at the people working on it - not to mention that the people working in Perl are much more diverse and harder to measure. The total developer activity could well actually be about the same between Gnome/KDE and Perl.
GUIs
Ovid on 2007-01-03T22:33:56
I completely understand why GUIs attract so much attention. That's what initially attracted me to Web programming and is one of the reasons why Perl disappointed me when I first got into the language. GUIs are tremendously important, but serious programmers often dismiss them because so many GUI creators are so terribly bad at it that they produce pretty piles of junk. Those who appreciate the power of a GUI can produce tools that are tremendously productive, but they aren't as "sexy". For example, GUI representations of code paths can convey in just a few seconds data which can take an experienced programmer many hours of reading through code to divine, but it's still not as sexy as an mp3 sound visualizer.
People are more interested in the layers near them
Alias on 2007-01-04T07:52:13
I think it has to do with closeness.
People don't care in general about things they can't use directly. They do care about the things they use directly.
Case in point: PPI vs perlcritic
PPI is a generalised parsing module for Perl, perlcritic makes the actual judgement calls and provides the actual interface to users.
I think it would be a pretty fair call to say there's FAR more interest and excitement and debate about perlcritic than about PPI.
As a tool/component, PPI has a potential worldwide direct userbase of maybe 100 people
:)
I'm sure there's a lot of perlcritic users that know at some level PPI is providing a lot of the heavy lifting, but really don't care about it that much.
And this is as it should be.
I'm hoping that this year we'll start to see CPAN bridging the gap a lot more between components and applications. We're already seeing that start to happen, but I think we're really starting to hit critical mass where there's "enough" modules written and the barrier for people to write useful and exciting applications has been lowered sufficiently that we'll start to see some of them really shine.
KDE and Gnome glorious joyfullness dissatisfaction
scrottie on 2007-06-30T10:51:51
Hmm.
Speculating wildly...
Work done on related projects has a good chance (at least in the mind of the programmer) of being included with the main project provided they work hard enough and do a good enough job. I use this mini-law to explain Linux's popularity over BSD even though BSD was far more mature, stable, clean, and complete -- Linux actually benefited from needing work. It adopted programmers, so to speak, and then they became part of the family. Conversely, in Parrot, it's harder to imagine a small, bounded, finite side-project that could later be considered for mutual packaging. Working on your own code is a lot more fun than working on someone else's.
People are already using KDE and Gnome. It's alluring to contribute to a success project, especially one that is still gaining in popularity and is growing rapidly in actual useful and used features. I often think to myself, "I like Perl 5, I'm dubious about Parrot, I should just learn the Perl 5 core", but then the devil on the other shoulder pops up and says, "no, no one wants to teach you because they're all grumpy about having to maintain the best for too long, and the best road ahead really is just not breaking anything, as that's just the state of people's worn down ambitions, and any attempt to improve the situation will probably just make it worse, and the only bugs left right now are the really hard ones". If KDE or Gnome were in this state, it would be poison for them. I think the Windows people suffer from healthy doses of this poison. The point is, a project that's in production and has users but is still growing rapidly puts out a welcome mat for developers, but those not in production or that are leery of forward development make developers nervous.
Programming languages have a large "userland". It's hard to break out of the userland and into the core (interpreter, parser, compiler, etc). There's a lot of work put into keeping you from having to -- you *should* be able to do whatever you want just using the language as-is. Most first stabs at Parrot seem to be with PIL or whatever it is now -- essentially the userland. And if you do have to muck around in core, something just feels wrong, because you know this principle is being violated -- you feel like you're electing yourself president or something just by harboring thoughts of working on core. It raises alarm bells.
Jumping into a large codebase is hard. Pugs had a huge win of starting off tiny and getting a lot of people to look at it while it was still tiny. Besides the difficulty, you have indecision -- people think about it but don't actually lock themselves in a room away from everything else for a week and just do it. It's always maybe, maybe-not, maybe, maybe-not until it's happened without them realizing it. Active channels full of people eager to help give tours of the code with no commitment at all on the part of the touree is a huge win against this kind of indecision -- showing the code like you're showing a time share condo makes the sell.
Reverse psychology. Tell people they can't see the code, can't participate, only get releases, have to dig to get past the binaries, have no version control, have to talk to people to find out whether features are even being considered, etc. I'm thinking of MUD here, I think. The Gods did what the hell ever they wanted and the low level wizards got to write code using it, desperately wanted
/obj access, but couldn't have it.
When there's one of something, it's magical. When there are a whole bunch, they're annoying -- also drawing on MUD experience here. I watched people commit crimes to get their hands on early-ish MUD clones. You could count them on four hands, and being a wizard on one meant something. At the height of the thing, they infested the 'net like a cockroaches, and everyone was god of their own private MUD.
People must see the need themselves. Most of us have no idea what it's like to maintain Perl 5 (I have very little idea), but the primary necessity of Parrot stems from the needs of those maintaining Perl 5 -- the need to have a modern, lean, clean, extensible codebase on which to work. Those needs indirectly but not directly mirror those of the community, who would have been perfectly happy to accept 5.10 as Perl 6. It's telling that the features Parrot promises are touted so often (speed, multi-language support, etc) but the necessity of it isn't. Unless the necessity is at the forefront, and it's the whole community's necessity, developers will be drawn from a small pool.
Things happen on their own. Sit back and wait. Go on vacation for a month and a few things you wanted will get done. Hell, someone partially implemented vi in JavaScript -- I've been wanting that. Merry Xmas to me! It's tempting to just take a mental vacation, occupying yourself with trivialities and random amusements, and use whatever happens rather than making it happen yourself. The only trade off is being able to decide some of the fine points. For most Perl programmers, whether they wind up using Ruby 2 or Perl 6 next year is fairly moot -- either way, something has happened, and they're using and benefiting from someone else's work, and they still get to share in the buzz and excitement. That things have been happening so fast lately on the 'net further re-enforces this wait-and-see mindset. You and I know Ruby 2 and Perl 6 are very different beasts, but from the hype and excitement angle, there isn't much difference. I guess the KDE and Gnome analogy breaks down here so this is really drift from the main point, but I'm allowing it as I think it's significant.
Oh well.
Sorry for the flood in your blog. I promise I won't make it a habit. I'm usually far too busy to read about the progress of things (or upgrade KDE, if I even ran it, or closely watch what other languages are doing) but YAPC got me thinking that my life and my goals would be easier if I made use of some of the intelligence and work of other people will similar goals. Mostly jjore had that effect on me
;)
-scott
