Slashdot Mirror
Has Linux Development Become Too Political?
1010011010 asks: "Has Linux development become too political, bottlenecked and ego-driven? Witness the recent exchange between Hans Reiser, of ReiserFS fame, and Alexander Viro (VFS maintainer) on Linux-Kernel; Hans, and others, were griping about Viro refusing patches and ideas on principle, and Viro keeps telling people to shut up and read the code. It's obvious that the kernel needs better documentation and fewer penis-size contests, but it also needs better 'roadmaps' and plans -- i.e., documentation in advance of changes. Does anyone have a current "org chart" for Linux kernel development? Is Linux Kernel Development sustaintable as a coalition of little feifdoms?" Such things are concerns, but sometimes it can be that very ego that drives a project. Behind technology, there are the politics of that technology. Being human, is there any way we can avoid this? Should we?
People who follow the kernel threads summary are well aware that this topic shows up there.
For instance look here for an example of Linus apologizing for his behaviour, and then there is Donald Becker's problems. Past complaints have shown up as well.
Unfortunately I cannot right now find the post I was most interested in pointing out that the confrontational atmosphere limits participation by people from different cultures. (Specifically Japan.)
OTOH let me wrap up with my all-time favorite discussion of design philosophy, which happens to (coincidentally?) show Linus' flaming abilities...
In short I think there is an issue. Can it be fixed? Should it be fixed? I don't rightly know...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
1.Why is there a big, ugly union in the VFS rather than having all filesystems use the generic pointer?
This is a big ugly wart that has to be fixed. But there's another way to handle it than forcing everything through the generic pointer: just include the length of the fs-specific data in the fs registration struct. Then all the nasty includes can be unwound. I proposed this a few months ago but didn't get any feedback one way or the other so I didn't code the patch. After getting some email about it later along the lines of "good idea, where's the patch?" I decided to do it after all, but by that time 2.4 was getting too close and this really isn't the kind of change you want to make when you're on the putting green. As soon as 2.5 comes out I'll do it and submit it, we'll see what happens. All the filesystems have to be changed at the same time (though trivially) so basically the patch has to be coded and submitted all on the same day. And if it doesn't get accepted the first time around (the likely case) the process will have to be repeated a couple of times.
This is by way of saying that I hope that that particular issue hasn't got long to live. (on to the next...)
--
Life's a bitch but somebody's gotta do it.
I do not intend to avoid Carma Whore allegations as I get blasted on casual basis anyway to make sure that my carma is down with no artificial assistance.
So summary (from all threads):
1. Al is not one of the most pleasant characters to deal with. As he himself says: "I am a BOFH, not a nurse". But he is usually right. And if you subtract the inflammatory tone so typical for *nix dicsussions he is right here as well. That is besides the fact that Al was not the only accused and at one point Reiser was throwing accusations left right and center.
2. I like what Hans does, but:
2.1. There is no common journaling API so his work, xfs work and ext3fs work cannot be converged. Especially at user space level. And this API is nowhere close.
2.2. As per Hans statement he has more than 6 more additional months of roadmap for features and cannot freeze. Kernel is in feature freeze right now. So ReiserFS should not go in. So if there is a problem with ReiserFS conforming to the current VFS layer then ReiserFS should be adapted.
2.3. There has been a flurry of new VFS level features. bind mounting, multiple mounting of partitions, devfs related stuff, etc. IMHO: these all have some very serious security implications that must be flushed all the way to userland. Before that VFS should not be modified at anyone's whim. That is besides the fact that kernel is in freeze and the discussion on modifications is moot.
3. Overall: IMHO in this case Hans p... is shorter. That is besides the fact that it is shorter by definition due to his licencing practices.
YetAnotherLinuxUser (and sometimes sysadmin).
P.S. This is not the only thread. There are few more.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Yeah, it seems from the discussions on linux-kernel that having a transaction filesystem
leading to problems with too many pages being
dirty because the vm system can't write out ones
that are required for a transaction, so some sort
of major modification is required to fix things.
NT has a similar write-throttling mechanism.
http://devlinux.com/projects/reiserfs/ - also,
Underhand.net's very own Kurt has a nice page
about converting your box to reiser, if you're interested,
at http://kurt.andover.net/Reiser-filesystem-HOWTO.h
Well, I use reiser on my x86 based squid at work,
and it's pretty damned nippy. It saves quite a bit
of space, gives me a 15% speedup on reads, and is
journalling. Of course, with journalling, unlinking is a little slow, but that's less
critical for me.
Of course, I don't like the three lines of ads on startup; I want to see
important messages about the health of my box, not spam for mp3.com, SuSe
and so forth. It didn't take long to knock that bit out, but it shouldn't
have been needed. When linux becomes spamware is when I choose to untrash
my FreeBSD boxes
It's a pretty nice fs, all in all. However, as much as I admire his work,
I can't condone Hans R's rather hotheaded behaivior, esp towards Viro.
The kernel guys have a lot of factors to juggle, and have to (in theory)
make changes based on the biggest potential upside. Where there are
disagreements, the maintainer makes the call, because he/she/it is the
maintainer.
I think we can do without fireworks in the kernel list. This filesystem
isn't really needed for endusers right now, it won't kill people if they
have to patch it in.
I know that Hans and others have put loads of very hard work into the code,
and I am sure we all applaud them for their efforts, and the quality of the
results. However if it's not right for the direction of the kernel, and
the vfs stuff etc, it's more than a little arrogant to expect the kernel
supertanker to be turned on a dime, just for one FS.
I genuinely suspect that the problem is as much in Hans' approach as the
code itself, and that if he were to cool down a little, there could be a way
to mesh a lot of the excellent work he's done into the kernel proper. Of
course, it would involve him losing a little face, but it's a question of
priorities. If he swallowed his pride, maybe he'd be better off, and hell,
the rest of us would too, since some of his work is absolutely first class.
Like I say, my work squid runs on his FS, it's not like I think it's utter carp- it runs like a dream..
It's not really appropriate to try and send the pugilistic villagers up the
hill to Castle Viro to burn the place down quite yet; he, and the other
kernel guys, are doing a sterling job- there's no reason to tear them to
bits because of one brilliant but misguided loose cannon. (There's a mixed metaphor for you)
Oh, and this 2.4.0-test2 kernel is doing pretty well so far, too
Just my two cents.. YMMV, etc.
Oh and my own spam for mp3.com, visit http://www.mp3.com/tib -it still sucks.
(Sorry about the cruddy formatting, bad hair day)
...but I know what's wrong.
Non-(kernel developers) should stay the heck out of this discussion. Political infighting is never helped by the uninformed butting in of outsiders.
Yeah, yeah "maybe we have a better view from the outside". But just imagine YOU are a coder working on a project with a bunch of people you know are competent but who don't agree with you. In comes a consultant to "help you out". How do you feel about the consultant? Now imagine that you were working on the project voluntarily and for no money. And further imagine that there is no "management" to appeal to make the coders listen to the consultant's ideas.
One of three things will happen:
1) Everyone will be rational and form a consensus.
2) Opinions will polarize and the project will fork.
3) Squabbling will continue.
Nope, I'll watch this one from the sidelines and I suggest you all do too.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
1) the VFS union has been around since early Linux, and was designed by Linus - this has nothing to do with Alexander Viro. Feel free to submit patches.
2) journaling will be what people submit. Right now ext3fs has a generic journalling subsystem, ie. any other filesystem can use the same transaction engine. Feel free to submit patches if you disagree.
3) feel free to submit patches that make the VFS stackable. Be wary of deadlock, recursion and generic complexity issues.
4) the answer is 'if done right then yes, sure.' Feel free to submit a patch.
5) Feel free to submit patches to Linus.
6) your observation does not match that of mine. As a matter of fact I dont have a vested interest in ReiserFS.
7) sure, feel free to submit patches.
I hope to not sound arrogant, but your VFS-related comments so far did not show a great deal of experience. Writing a filesystem does not necesserily mean you understand the VFS! Please make sure you understand what you are talking about - best way of learning is to post your comments to the linux-kernel and/or linux-fsdev mailing lists, not Slashdot.
Alexander Viro has brought alot of simplification to the 2.4 VFS: despite having 35% more filesystems, the total linecount of filesystem-specific code got 30% smaller. Alexander took lots of filesystems-specific hacks and made them a generic VFS feature. I dont think you want to argue with the fact that this makes the Linux filesystem architecture much more flexible. Ext2fs got only 12% smaller in 2.4, so it's mostly other filesystems that benefitted. (ext2fs got so much attention during the years due to its large 'user mindshare' that it was pretty clean already.)
--Coke
How come other filesystems have no 'problems' getting into the Linux kernel? How come that the number of filesystems in 2.4 is 35% more than in 2.2? Why is it that every kernel developer who contributes on a daily basis acknowledges Alexander Viro's hard work of cleaning up the VFS? Witness Mandrake and SuSE kernel developers defending Alexander Viro in the other thread, so it's ridiculous to shout 'Red Hat conspiracy'.
New filesystems in 2.4:
shmfs (a much bigger change to the VFS and MM layer than any journaling filesystem. Stephen Tweedie wrote a journaling ext3fs on almost-vanilla 2.2 VFS, so it's not rocket science.)
ramfs/cramfs. Features compressed file data - not a triviality either.
devfs. Despite Linus' reservations against devfs, it's in the 2.4 kernel.
This whole 'Reiserfs' argument is a red herring. Hans Reiser has to get his act together, and he should start contributing to the Linux codebase on a daily basis so that he can integrate potential extensions cleanly. Hans Reiser's problem could be rather that he financially depends on Reiserfs to succeed?
--Coke
While the very open style of development has been very succesful for Linux, it is not without it's flaws. Because it is open, people who maintain pieces of the code (such as VFS) actually have a lot of power over what happens to that code. In theory they don't, because people can always write their own code, but I don't think there is anybody who is willing to fork the kernel over this issue. Thus, egos and ego clashes get in the way of development. I'm sure this also occurs in the BSD development teams (considering the circumstances behind the split of NetBSD and FreeBSD) but is just less public due to the more closed nature of the development. Actually, I think such development problems are present in every large Open project simply because there is no management breathing down your neck to stop bickering and do something to further development. Given the fact that people will always have egos, and that nobody wants to close up Linux's development, I'm afraid there is probably nothing to be done, other than resolve issues on a case by case basis.
A deep unwavering belief is a sure sign you're missing something...
Actually, Al, I have been working with the VFS, and alot of the problems is the undocumented, unnanouced way in which the VFS gets changed. I try reading through linux-kernel, but the volume of messages is WAY too much to sort through daily. And linux-fsdev is a low volume list that rarely gets a post. So the way that i find out about changes is to have my filesystem break in some wierd way, and find the diffs for ext2, go through them, and see what changed. And i also haven't seen any reason for the symlink change, other than an "aesthetic". (If there are reasons, please feel free to direct me to them.) So one of the gripes that Reiser had that is valid -- that the changes to the VFS are kept opaque, and you end up having to read the source to ext2 to figure out what the hell is going on. Meanwhile, I am trying to write a filesystem, which is a rather mammoth task in itself.
And as another point, from a logistical issue, there have been a couple "feature freezes" announced for Linux 2.4. Which makes people really hesitent to send in patches since by all rights they will probably be ignored. Feature freeze to me ususally means bugfixes only. Yet the VFS has changed ENTIRE SEMANTICS for certian functions since the last two "feature freezes." This by itself is a little odd. Since you have name recognition with Linus, it's easier for you to get patches recognized than anyone new to the kernel team, yet the level of change is the same.
So as a polite request, could we utilize linux-fsdev more for the VFS traffic, and just keep good summaries of what VFS patches are going in? That by itself would help clear up alot of the debates.
Cult of Personality
Not a flame.
mav[LAG] thinks it's possible that anyone with a good enough grasp of the latest kernel and how it works is more than likely writing code rather than writing docs
I've known a lot of technical writers who have decided to focus their energies on English, and not C. They can understand how something works, and not be compelled to write more code on top of something that few people understand.
I've also known a few of these gifted technical writers who also have the knack of talking at length with programmers, asking the right questions and rephrasing things and asking again, thus forming a translator from "arrogant coder who expects everyone to read source code" speak into "interested technophile who wants to understand algorithms" speak.
As a matter of teaching people to program, I always insist that a person write out their algorithm in English, as comments, then each comment becomes a statement or two of real code. Then, importantly, leave the original comments in. It's all about the algorithms, people, not the reserved tokens and the use of operators. I wish more "advanced" programmers did this design-in-comments technique, because it (1) makes cleaner algorithms, (2) makes documentation for later readers, (3) makes it easier to port later.
Lastly, I know a LOT of programmers who would be a lot better if there were definitive 'state of the art' examples of source code, along with carefully written English discussions of what the source code is doing. If you don't know C, you don't know what while (*s) *d++ = *s++; does. If you're just learning C, it helps to see /* copy to the end of the source */ nearby.
[
I noticed the thread in the KC on Linux care and was kinda suprised to see some not so professional communication, as I read some of the response it became clear that the e-mail that started it was made out of frustration (you've spent years working on something and then you're told, it's not ready yet). I think initial responses had a little too much ego, but as they go on, they get down to business. I think this model will work in the long run, as long as people STAY OPEN MINDED, and are willing to listen and explain. Beware the darkside!
you're right bro! the kernel needs to be as flexible as possible and allow support for as many programs as possible.
That's why i think linus and alan cox should have a web browser integrated into the operating system so that you can't remove it. I want to see something like IE5 in there! yeah! that would be good!!
in all seriousness - the linux kernel, ironically, is the same thing as neo-mail....it was a free 'program' (if you'll allow me a little license here) - that Linus originally intended for himself because he didn't want to have to pay inordinately high prices for other *nix distributions. That being said, linus (and AC now) have pretty much absolute say over what goes into the kernel, and more importantly, what doesn't. - I think the politics of the kernel have little to do with what's going on around it. Up to now, Linus and AC have been very good about keeping cool heads. If this changes, maybe other people will use other operating systems...their choice.
Right now, I use linux because it's the best choice for me, if that changes, i'll use another OS, probably (Open|Free)BSD. This is exactly like the NeoMail example. If it's right for you, use it, if it isn't - don't. No skin off your back, no skin off the developer's back.
Linus hasn't made any money off linux (aside from the peripheral gains like fame, and he'll never have to pay for a buger when he's around John 'maddog' Hall) - So, who cares about ego so long as he's still building a good OS. Like i said, if that changes, people will move on.
When software pissing matches go to far....people don't need to talk about the consequences...they just happen. Look at MS - all people see coming out of Redmond now days is a big river of piss...and look where it's getting them. Bad software is bad software, regardless of the reasons. Maybe it's shitty code, maybe it's shitty managerial decisions (brought on by whatever reason). But either way, it's a natural process.
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
"It is seldom that liberty of any kind is lost all at once." -David Hume
Two developers arguing about the best way to do something is a crisis in Linux politics?
Gimme a break. The whole idea of open source is that (like some kind of chaotic genetic algorithm) it will weed out the best way to do things.
My criticism of Linux is that, in a case like the JFS, it fails to leverage the commercial entities who have a lot to offer -- SGI and IBM. It was just several months ago that SGI seemed strongly interested in moving it's JFS to Linux. IBM has made similar offerrings, as I recall.
Apache has done very well working with the com types, but Linux seems to prefer hiding in a cave, with a score of unrelenting primitives camped at the opening, shouting "Ugga Bugga!" at any which seek to enter, and poking them with a sharp stick.
Go ask Joerg Schilly(sp?) about scsi generic. Surely SGI, Sun, IBM or Adaptec could do something about the horrid state of CD Writing under Linux.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Again a CS 101'er... I do not believe a thing such as Linux VM system has no actual design behind it. Of course, there is. But why isn't there some readily available design-doc of all important parts of Linux on the Internet?
Maybe Linux development could be made two-layered: open-designed and open-sourced. In stead of leaving the design issues to a few, many could contribute ideas at higher level. Then we hopefully get what we all want: the best design combined with the best implementation.
Yes. And being software developers and not diplomats the language used is not always the most polite in the world - I personally think it is fully OK, but not everyone thinks so. I am not a kernel hacker, but I already have the experience of being flamed down by one of the gurus (well - he was right :-)), after which I responded by sitting down for a day and identifying a though bug in his code :-) Someone else might respond with "Fsck you" and never again read l-k.
The current discussion regarding ReiserFS is not very significant, although it would be sad if it ended with Hans giving up his high-quality work. What bothers me more is that IMHO we are approaching a limit where the current way of project management won't work in the long term and there is very little being done about it. Just a few points:
- There is no version control system - instead we play games with x.y.z-test-pre-ac-aa-whatever and if something goes wrong, we binary-search the exact version where it happened instead of getting clue from changelog.
- There is no issue tracking system (the TODO saga on the l-k is better than nothing, but...).
- The design papers are missing (even a separately archived and publicized relevant mail threads would help).
- There is no regression testing (no doubt the developers of the particular subsystem have something, but it is not readily available).
Some problems were identified and adressed - the big delay between 2.0 and 2.2 due to missing definition of the target feature set and (hopefully) the horrible state of 2.2.0 when it came out due to allowing non-bugfix changes in the last pre-versions. Alan Cox does a great job at integrating and testing the patches.I hope that when the 2.4.0 comes out, the core developers will look back and discuss what can work for next years and what cannot.
>A person who claims women have no egos and >agendas probably believes in the Tooth Fairy. or is a very cunning woman with an ego and an agenda.
==============================
http://www.geek-ware.co.uk
==============================
PROUD to be GEEK
In fact, stuff like this happens no matter what, whenever you bring a number of people together... some people are going to argue. Just with OSS, they end up doing it in public... for all the world to see.
You should accept it, expect it, hell... even enjoy it... but still realize that nothing has changed.
--
--
A PC without windows is like chocolate cake with no mustard.
Obviously, it is a good idea to avoid ego-involvement, or conflicts stemming from same, in coding as in other human endeavors. Can this be achieved in the free OS movement? Possibly, but not with current tools.
So, the open source movement clearly has two problems to solve if participants want to work together more effectively. First, it has no managers with these skills, since only techies are involved, and they (naturally) have to spend most of their time focussing on learning new technical skills. Second, really effective project management software for remote or diffuse projects doesn't yet exist.
Btw, more bandwidth won't solve the latter problem, because even perfect video conferencing doesn't allow the same kind of interaction that live meetings run by great managers achieve. For example, social researchers have determined that just the presence in a room of a mirror increases "objective self-awareness" (which generally inhibits free and creative exchanges). The mere presence of a tape recorder -- even if it's not turned on!-- has the same effect. So imagine what effect the recorders for video conferencing have....
That said, pro-active documentation (which I used to recommend when I managed documentation at Bear, Stearns in the early '80's) can certainly remove some of the potential conflicts,if nothing else by helping individuals who need to work alone choose areas not impinged on by others! The possible trade-off is that the strength of the open source movement is precisely a not-necessarily-scripted characteristic, its willingness to embrace a totally new (better or more comprehensive) answer or approach to already solved problems.
Start here.
(Posted anonymously to avoid karma whore allegations)
It's going to take more than just good documentation to keep Linux from developing out of control and spiralling down towards instability. Most non-trivial software heads in the general direction of loss of control as it grows, but operating systems are specially vulnerable to this syndrome because they are highly concurrent systems, and concurrency offers opportunity for problems to emerge with the greatest of ease.
For Linux to remain stable, one of two things are going to have to happen. Either extremely heavy-handed personal control by people with a supreme grasp of everything that's going on in the kernel and who won't be deflected from their straight and narrow path --- that's where we are now, so be careful not to throw the baby out with the bathwater when knocking it. Or, fight the problem with technology and abandon the single monolithic unprotected space approach and partition the kernel into a large number of interacting but separate domains using the MMU plus well-specified and relatively stable internal interfaces. Needless to say, the second of these approaches would result in an utterly different kernel altogether, but at least it would have a longer life expectancy.
The current kernel is as brilliant as it is because of the brilliance of the people that are keeping it from falling apart under force of change. But there is a limit to human intellect, at least in the current pre-nanotech timeframe. The current developers should accept that, and work towards a kernel design that reduces dependency on their brilliance by providing an effective assortment of hardware-assisted guarantees. Learn from the user-space design of Unix. It's a good model.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Truth is that in the heat of the email thread both sides wrote up some things that just weren't there. And after yesterday's invention of the "VFS flamefest" here on Slashdot, it seems logical that some of the people who weren't on linux-kernel but were on Slashdot yesterday get a bit worried.
Well, I guess this is how rumours come into existance :) Lets forget this whole thing and get back to coding like we always do...
Calling the kernel a "coalition of little feifdoms" is wildly inaccurate, because as the core systems of the kernel become more integrated with each other (think f.e. of the tangled web of interaction between VM/VFS/buffer cache/dcache/icache/swap cache/etc...), the "heads" of each work more and more cooperatively. Sure they still flame each other (time was, being called "pinhead" in linux-kernel was a mark of high esteem), but the amount of respect and degree of deference shown to each other's expertice is truly admirable.
Of course, politics show up every now and then... there are still people who think DevFS integration is the seventh sign of the coming of the antichrist. But even those who vehemently opposed it are now helping to make it really good by adapting the dcache and VFS to work better with it.
IMVHO, Hans made something of a spectacle of himself on the list. He ran around accusing everyone he could find of being corrupted by corporate influences (RedHat was his favorite target, since Alan and SCT of ext3 fame both work for them), while simultaneously admitting he had a strong financial incentive to get ReiserFS integrated with the kernel.
Of course, there are two sides to every story; Hans has been working on/with this thing for a long time, and has sunk a lot of his own blood, sweat, and tears into it, so I don't blame him for getting a little fanatical about it now and again. :-)
Making noise is one of the things that keeps the open source system healthy. I think that in general the Linux kernel has had good stewardship, and though I personally have not had direct interactions with Al Viro, I think that extends to him as well.
On the other hand, I think the system could be improved a lot. There are some annoyances. For example, there is little, if any, documentation available on the one of the most critical aspects of the kernel, namely the buffer cache component of the VFS. It seems that you are expected to either learn about it yourself by reading every post on Linux Kernel, and every line of code in the filesystem tree, plus all patched versions. If you get stuck, you can play 20 questions on the kernel list, trying not to appear too clueless and at the same time trying not to appear so clueful that you will get flamed on grounds that you should have figured it out yourself. If your post to the kernel is phrased correctly then one of the VFS gurus will answer it - usually clearly and accurately, but not necessarily completely. And the game goes on.
The good news is that you *can* get the information you need. The bad news is that you are expected to jump through a lot of hoops to get it, and the information seems to be dolled out as a kind of payment for playing the game correctly and politely.
I think this should change. I think that the design documentation we need should be readily available - it has to be posted somewhere where everybody can get at it, and contribute to it. There's already a place for it: kernel.org. Why isn't there more there than just kernels and patches?
(The Linux Doc project is a good source of documentation, but not for in-progress kernel work.)
There's no shortage of people who would be willing to do this kind of documentation work if they were able to. Right now there seem to be some roadblocks in the way.
--
Life's a bitch but somebody's gotta do it.
I'm the author of an open source project entitled NeoMail. As an aside -- yes, my real nick is Neo, not Bedemus, everyone started calling me that after I spent way too much on a Neo outfit for my work's halloween dress-up day and started wearing an ankle-length trenchcoat during the colder months -- I know, I'm a loser. :) When I set out to design NeoMail I had a certain audience in mind, essentially the same one as all open source authors when they start out -- myself.
Now, once I had something that worked pretty well for me (I had poured at least a month or so of effort into it at that point -- was taking on the project just to see if I could, teaching myself Perl in the process), I posted the code on the web and announced its release on Freshmeat. Immediately, the mails started pouring in -- some bug reports, which are always appreciated -- but more and more suggestions as to what people would like to see. Most of these suggestions were from non-programmers, and therefore included no patches or anything, just opinions as to where NeoMail should head.
I quickly realized that I'd better start narrowing the scope of NeoMail beforehand, otherwise I'd NEVER reach 1.0! A few things were decided up front:
- NeoMail would require no extra software be installed, aside from the necessary Perl 5 distribution and included modules, a web server, and an MTA.
- NeoMail would not be designed to do POP3, IMAP, etc. There were plenty of solutions doing this already, and it would have been easier to use Net::POP3 than to code local mbox spool handling myself, but it just wasn't the direction I wanted to head in. NeoMail served a certain niche quite well, and a chief benefit was that it didn't require users to even have access to a real system account for it to work.
- Plenty more -- you get the idea. I'd list everything here but how do I know people have even read this comment this far?
:)
Next, the arguments started."Why don't you use thus-and-such module to add thus-and-such feature?"
"Because NeoMail doesn't need that feature, and it'll make for a hairier install for admins having to hunt down additional modules to install."
"Yes it does need that feature."
"No it doesn't, and if it does, code it yourself -- that's why I made it open source!"
"But I don't code, why don't you add the feature and just make it an option so it doesn't increase system requirements?"
"Because I only have so much spare time, and after a while when you're dealing with an interpreted (yes, compiled before execution, but you know what I mean
"Fine, then I'll be forced to go elsewhere for my webmail solution." (This one always floored me! Made it sound like I had a commercial interest in them using my software!)
"That's your right, thanks for trying NeoMail anyway though."
"Wait, I was just kidding -- PLEASE won't you add this feature?"
And so on, ad nauseum.
Eventually, come arguments actually convinced me to add something, but only if I thought it would benefit the majority of users. I was writing a webmail solution for normal people, not geeks like me. :) When people started saying they wanted NeoMail to import and use their pine or mutt settings, I tried to explain that the vast majority of people that actually are using NeoMail aren't the admins installing NeoMail, but their users, who likely don't even know that pine's a mail client, not a tree. That's the problem when you release your work to a community of people like you -- eventually if you don't fight the urge to do it, your tool will become so big and complex that only people like you will be able to use it. That isn't always a good thing.
Now, I understand that filesystems are much more complicated than my humble webmail solution, but I think that what people need to realize is that just because someone is the maintainer of a piece of code that allows user contributions doesn't mean that the individual is morally obligated to include everything that comes across their desktops, no matter how well thought out or convincingly argued the matter is. The individual is, after all, the maintainer, and if you don't like it you're always free to add the feature for your own use -- that is, unless you're seeking to satisfy your own ego by getting your code included and a credit in the CHANGES file. The door swings both ways, you know.
I'd post more -- have a lot of thoughts on this -- but if I don't click "Submit" soon, I can almost guarantee nobody's going to read to the end of this little rant!
--
NeoMail - Webmail that doesn't suck... as much.
As for the "external pressure" - get a grip. Really. As far as I'm concerned this stuff is done on technical merits. You can't build a pressure sufficient to make me act against that. And I mean it - I consider self-respect more valuable than having a paid job. YMMV. You can't force anyone of us to do what you like. You can learn the kernel and start submitting patches that would be acceptable to Linus on their technical merits. That's how it works. I would be glad to see anyone joining the VFS/fs work. Learn it and go ahead. Or keep wanking - nobody can deprive you of that right.