Slashdot Mirror
Free Software Leadership
GroundBounce writes: "An article at Advogato uses the recent resignation of Christoph Pfister from the Fink project to analyze and highlight the ways in which the free software community often alienates its leaders, and the differences between the Mac shareware and the greater free software communities."
I think one of the secrets of staying sane in Open Source is learning how to ignore people! Just ignore them, you're right, you have NO OBLIGATION TO THEM. You DON'T have to cater to everyone's silly little whim. Learn to use the D key when people are e-mailing you personally and not the support mailing lists and news groups like they should if they had 1/4 of a brain!
Man, if you can't ignore people you're in the wrong community. And if you're not writing the software for yourself... then what the hell are you doing?
Chris, thanks for all the hard work and all, but you'll hear no violins from me.
Luck favors the prepared, darling.
Muuuuhhhaaaaahahahah.
Not to trivialize it, but from most accounts it sounded like the "Fink dude" was in a "Funk".
He needed a break, so for however long is needed;
"Run fast, run far" and return when you are ready.
If it is not on fire, it is a software problem.
In general, most successful open source developers have similar fairly similar strategies (point the clueless to documentation, ignore the worst offenders), and pet peeves (people who don't know th first thing about the system and ask idiotic questions about picky details, people who complain about a bug publicly but don't report it to the developer). My experience as a long-time clueless newbie has been that documentation in free software projects is almost impossible to understand, usually starts about half-way through, presuming a good deal of understanding of the system, instead of at the beginning. Documentation is especially a problem for Mac users who are used to getting the documentation through the help menu on the application itself rather than by using man or reading README. Also reporting bugs is very intimidating when the only way to report is often to send an email to the lead developer who is likely to ignore you if you don't use the right terminology. OSX Unix developers should post readmes and man pages very prominently on the dowload websites, and install bugzilla to make reporting bugs less traumatic.
This is not an issue that plagues OSS, it is one that has been present in every workplace in the world. Who has ever worked in an environment where everyone agreed all the time? I personally left a company after disagreeing with some of the stances taken by a manager of mine, and that was in the closed source, commercial world.
The only difference I see is that given the nature of OSS the players tend to have some very strong feelings about the subject material or they wouldn't have started the project to begin with. No one would undertake a project for zero pay, long hours, and constant hand (and brain) cramps just out of the good nature of their heart. They start they projects because they feel they need the tool at hand. When others join the cause, the goals of the project migrate with the masses; which is not always the exact direction the founder may have envisioned.
Given the founders original vision of the project, and the nature of OSS being so visable and publicized today, any falling out amoungst the developers is going to be louder than a closed source model.
But to sum it up; this happens everywhere, it is just that it is more visable for public projects!
You're not alone. I want to produce goods.
I don't care to play games with lawyers.
"Intellectual property" is a ludicrous oxymoron.
Pretending otherwise just makes you a liar.
-I like my women like I like my tea: green-
A GPL-ed open source app [nographer.com] that I wrote has so far had >1200 downloads in 2 months, yet only six people have fed anything back (five of them were complementary). Admittedly this is on Windows, where maybe there are cultural differences.
It's not just Windows. The big secret of Open Source, the one Eric Raymond doesn't want to talk about, is that most users, even of Linux, are not programmers. With that in mind, most of the OSS philosophy is set on its ear.
Perhaps the problem is that the de-facto leader of the project is the person who initiated it; they might be a good developer but maybe they don't have the organizational/managerial/basic people skills to keep things going smoothly. This is one area (IMO) in which the traditional "corporate" system of separate management and development teams (at least potentially) has an advantage on the OSS model.
From reading the first bunch of posts here, one would get the impression that leading an Open-Source project is miserable work. In case anyone cares, I'd like to submit a success story
A while back I posted a little code on the net. It was a tiny driver for my Matrox Marvel video capture card. I figured there might be SOMEONE out there who'd find it useful. Well, people grabbed it, started working with it (I only have one video capture card, so there were apparently problems on other people's sysems) and improving it. We set up a CVS server and a mailing list and more people got involved.
After a while, I got kind of tired of the project. The driver has worked for me since day one, and I really didn't have much motivation to do any more coding or "lead" the project. Besides, several people that joined the project knew more about the code than me, so I figured I might as well quietly step away. The project's been going great and continues to grow. I still read the mailing list, but I haven't committed code in months.
I guess the moral of the story is: There may come a time where you are tired of heading up a project, and the best thing to do is to let go of it, and leave it to the more capable (and more enthusiastic) people on the mailing list.
Sometimes I am wondering about the role of leadership in open source software. In a way, at least from my point of view, the leader is typically the chief developer. But isn't there a better way to do it?
You might disagree, which is understandable, but I really think that the open source community could gain a bit by looking some more at the coporate model. (Yes, it does have its flaws, I'll be the first to admit. But there are some good things.)
For example, you might want a project architect. His job isn't to write the code, but to establish the framework and overall direction of the project. The architect gives clear direction on which way the software is going and provides a blueprint for the design.
Or, for example, someone who represents the user community. In contrast to the architect, this representative speaks for the users in terms of what features are most desired, and what bugs need to be squashed the most. And it shields developers from the maddening and schizophrenic voices of the community.
An architect could take the requests of the users, and combine it into the overall vision of the project.
I'm kind of making this up as I go here, but I see some value in the role of a software architect (who understands programming but does not churn code), and a single representative of the user community to deal with developers.
Is this too insane, or niave?
This is a GOOD thing. The majority of people should not be let near a programming language as they don't have the ability to think logically and break down problems into their components in order to write functioning programs.
The GNOME, KDE, Apache, and Linux projects seem to be doing well despite most of their users not being programmers.
Yes, yes, yes, but you both missed the point. Someone was complaining because he didn't get much feedback on his code; only a few people submitted improvements. The point is that this is to be expected, because the great majority of computer users are not programmers.
OSS advocates routinely bring up points about how millions of eyes look for bugs, and how if you don't like something then you can just fix it. Those points are bogus, because they are assuming that the intended audience is not only made up of programmers, but that those programmers are bored enough that they decide to going spelunking around hundreds of thousands of lines of code they don't understand. And that they have the gall to think they can make seat of the pants fixes without a clear picture of the overall architecture.
Do I get to see the code? With some freeware programs, yes. Others, no. But then, my coding skills lie more toward Web programming and Java, so I'm not sure I'd be able to do that much with the code, and here's a nasty little truth: neither do most people in the Linux community.
The fact that you have a use or not for the source is secondary to availability. You might not have the skill to correct a bug in a software you use but somebody else probably does. If we take your image converter as an a exemple, what happen if the maintainer [die | loose interest | sellout | etc] ? The software is still useful as-is, but a new filter could not be added to the package. With OSS, as long as there is a user community big enough to carry a few developper, update and new feature can happen. Often it does not, but with binary software it NEVER does.
About the instinctiveness of the UI, this is a slippery slope but let me make a shot. Use of an UI is an acquired skill. There is no instinct involved. What you find instinctive the next guy may find confusing. I personnally find MacOS 8 (the only one I used) confusing. But again, if I would have used it for a couple a week it would have become second nature to me, like Windoze and most Linux WM are.
Rereading myself, there is nothing imaginative in this post. The code availability argument is one the pillar of OSS advocacy and the UI stuff had been beaten to death multiple time in the past. In fact, it is so old that quote of flamewar from the beginning of the 90's are part of my fortune file. Hope it won't start another one.
:wq