Become a fan of Slashdot on Facebook


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×
Programming IT Technology

Shortcomings Of OSS? 124

King_B writes: "Interesting perspective on the OSS development model. Is anybody working on a new text editor?" It's an interesting article talking about the development of open source projects, and who joins them, and who starts new projects. Makes one think about the "scratching the itch" comment that's often heard.
This discussion has been archived. No new comments can be posted.

Shortcomings of OSS?

Comments Filter:
  • I _really_ don't think we need YATE!!!
    I could spark a holy war here by asying all you need is vi, but I like the diversity out there.
    Nope, where OSS fails is where no programmer has an itch to scratch. The only way around this is when forward looking business approaches OSS programmers and pays them to write the code.
    Can any /.'ers think of anything that needs writing, but nobody wants to?

    Strong data typing is for those with weak minds.

  • by apm ( 212573 ) on Tuesday October 17, 2000 @11:26PM (#697698)
    The logical conclusion of the argument is that we should have one program that does everything. Oh, wait, that's Emacs. I guess OSS does work then.
  • Can any /.'ers think of anything that needs writing, but nobody wants to?

    Yes, comments in code and man files and that stuff. SCNR
  • by luckykaa ( 134517 ) on Tuesday October 17, 2000 @11:29PM (#697700)
    People want to write text editors. Why? Because it means you learn something. Text editors are fairly simple, but not trivial. For Example, how do you handle data? An array? Not really good for insertion. A linked list? No. So to find out, you write an editor. Once its written, you magically know!

    Once you have a trivial thing with the usual cut/copy/paste/delete/search/replace operations then its about as good as all the others. Adding extra features to your own code is a lot easier than adding other features to everyone elses.n
  • I really don't see how having a lot of projects that do the same thing is bad as long as some of them produce good results. When people do something because they enjoy it, being "cost-effective" is not a valid criterium. And I think that once all those people have noticed that their own pet project doesn't get much attention (and maybe become better coders in the process), many of them will flock to big, famous projects and be content with being only one of many to contribute to something big.
  • by heikkile ( 111814 ) on Tuesday October 17, 2000 @11:37PM (#697702) Homepage
    I've personally had a few such experiences where I've submitted diffs for a program that someone else has written. A response comes back form the lead developer saying something along the lines of, "Thanks, but I've been planning on implementing these features on my own in a few months." The question remains, if no external help will be accepted, why bother even releasing the code under an open source license

    Even here Open Source shines. If you had a commercial closed system, all you could do was to submit a request, and in best case get the same reply. Now you can at least make the change for yourself, and use the improved program. You can also publish the patch on your web page or some related mailing list, and hope that enough people will notice, and talk to the lead developer, who may change his mind. In the worst case you can fork the project, start friendly competition, and perhaps prove to be better maintainer for the project. Sooner or later you can either join the forked versions, or one of them will end up as the winner, getting most patches and developers and features and everything. The other one will be quickly forgotten...

  • Just because there are a lot of similar software projects doesn't mean that the oss model does not work.
    A lot of these software projects have the same goal ...but they do things in a different way.
    At the end people look at the finished products and choose the best one for their needs.
    So lots of similar software doesn't mean we don't get any quality software, it means we get more choice of quality software.
  • Can any /.'ers think of anything that needs writing, but nobody wants to?

    a tool that scans freshmeat and slashdot and figures out what needs to be written, but where nobody wants to do it.
  • I is a one-armed man with mad itchin' on the wrong side of my back.
  • A summary of the author's chain of logic:
    • open source developers tend to create many new projects instead of adding features to a single project;
    • maintainers of open source projects are rejecting useful code from other participants due to political agendas
    Replace the phrase "open source" with the word "commercial software," and the assertions are just as true.

    Whether open source or commercial, software creation takes place in a social context of intelligent male primates who fight for supremacy using lines of code instead of rocks and stones.

    This doesn't mean open source has a fatal flaw, but that it's not a magic bullet for mitigating the distortions of politics.

  • by dragonfly_blue ( 101697 ) on Tuesday October 17, 2000 @11:46PM (#697707) Homepage
    Can any /.'ers think of anything that needs writing, but nobody wants to?

    Well, I'm always hearing about how XFree86 is just a huge kluge; is there a way to start a new project with 100% clean code, aimed towards more modern video card standards? Probably not... lol.

    About the article: it makes a few good points, including the unwillingness of many programmers to accept outside help (which is simply a microcosm of the "not invented here" xenophobia, manifest), and the duplication of effort on a broad scale.

    I think the author is overreacting, however. Let's face it; many of the programmers on Sourceforge and Freshmeat are fairly new to open source; it will probably take them a stagnated project or two before they "get it", and decide to consolidate their efforts with other programmers. This is a very normal step in the maturation of a community, and nothing to be too worried about.

    There have really only been a handful of people so far who have had a clear knack for garnering support for their open source projects. I think many programmers succomb to the ego, and don't realize that what Linus was really good at wasn't simply kernel hacking, but also helping to guide other people's talents in the right directions.

    Even the most amazing programmers in the world can be overwhelmed by the scope of projects these days, and it is difficult to accept that they may be better off handing the ship off to a different helmsman from time to time.

    I've personally found several really useful projects up on Sourceforge. The majority of projects they host don't seem to take off in any real way, but there are the occasional gems, including the engine running underneath my web site. (It's using the Thatware engine, great code.) You can find really nice stuff there, but you've got to be willing to wade through some muck.

  • "Is anyone gonna make another text editor" you say. The very existence of the opensource movement has given us choices.. a means to choose what I need, over what I am given to accept. A zillion text editors, all won't have the same features, efficiency and robustness. emacs may be good for some tasks, and vi may be good for others. I find a utility for Apache and I find a utility for other static-page web servers like khttpd. And with so many available, I can pick exactly what I need. This is an end-user point of view.
  • I think even though the author takes a bit of liberty regarding the motivating philosophy of OSS, he's on the money when he writes, "The only way for this revolution to continue is by contributing to it rather than creating separate paths."

    I've been alarmed by the shere number of projects posted to sites like freshmeat and sourceforge, etc... Something needs to change, but that change can't come from outside of the community, and it can't happen until the community sees the way things are as a problem.
  • by Cuthalion ( 65550 ) on Tuesday October 17, 2000 @11:50PM (#697710) Homepage
    I've railed against this attitude before but here we go again (I think I have something to say this time that I didn't last time)...

    The point of writing open source software is not really to solve all the world's software problems. There are several reasons to do it.
    • To solve a SINGLE user (the programmer's)problem.
    • To dink around with code, which is fun.
    • To learn stuff, which is fun.
    I'm working on a project which I GPL'd a few days ago*.. I realize that there are probably other apps do something similar to what I am writing. However I get personal gratification out of writing software. It's a creative process, and I feel better when I make stuff that seems cool to me than when I don't.

    I also do not feel that I should hide the source code that I developed for fun. If anyone else can have fun with it, that's great too. If anyone else can have fun with AND make it better at the same time, that's even better!

    I think this article says that I should not work on stuff if there is already something which I could modify towards my ends. But my goal is not conservation of work, it's to write something cool (note: this is NOT the same as "add a small feature to an existing cool thing" or "fix bugs in something cool"). The only other choice is "only a few hobbyist written programmes should be GPL'd, so there aren't too many", and that's just dumb.

    In my opinion, the reason Open Source Software works is because it's not coordinated at all. If I want to write something I can do so without really thinking about bigger projects, without thinking about other people's licenses, their coding conventions, et cetera. I can just dive in. None of these were really written by the community. They're written by invidividuals. That's why it all works.

    *It's still pre-alpha, and I'm not linking to it until it works.
  • Yeah, but why do we need competition in developing the same program? That's the problem Serge sees:

    We have over a hundred text editors, merely all doing the same job. No engineer is crazy enough to reinvent the wheel, or are any out there?

    If a head developer does not accept patches for new features from others, why does he than allow to do so? (Just think of the old QT Licencse: the source were free, but you weren't allowed to change them and redstribute the changed sources). Every programmer that gets such a mail "Thanks, but I plan to implement that by myself" really must feel dumb: Is my code this bad, that he has to completly rewrite it? That things are bad for OSS, in my eyes.

    What we need is competetition between different approches to a problem: one wants to create a lean text editor for use over low bandwidth network connections, to do remote administration, the other one wants an editor that can do almost everything (hey, btw: is there a lisp package to access coffee machines ;) ), and there should be competition between these two ideas, and not between two editors that do exactly the same job.
  • I was recently faced with that same choice, to join an open source project or start my own from scratch. I decided to join the project [] rather than start my own.

    I really do like the idea of having total control of "my" source, knowing every byte of the code inside and out. But in the end, I realized it was just going to be too much work. It would have been really fun, sure, but what really made the decision not to start my own project was time. I didn't have the time to devote to coding for hours a day for weeks or months on end to get somewhere close to where the project I joined [] already was.

    Before I did join them, though, I spent quite some time talking to the other developers as well as looking through the source. They all went out of their way to make me feel welcome, and since I've submitted code, they treat me as their peer in the project, complete with write access to CVS...

    It's actually been exciting working with other developers, all of whom live in different states or even different countries. Apparently the author of this article had a very different experience with some project or another, or perhaps he's just talking out of his ass.

    I don't know if my experience with joining an open source project is typical or not. Being an optimist, I'd certainly like to think that's how a project should run.

  • So he says all those people coding as a hobby don't always produce useful, new stuff. And? It's a hobby, right? He's basically attacking people who are doing something for fun at home, for their bad production figures...

    Man, be happy you can now run a complete great system with free open source software, but don't go thinking that everyone must contribute or that you have some right to have your diff accepted. If he doesn't want it, he doesn't want it. OSS is not some sort of collectice where everyone must obey the rules.

    If you want someone to code things that you think are useful, you *pay* them.
  • by Cuthalion ( 65550 ) on Tuesday October 17, 2000 @11:53PM (#697714) Homepage
    Well, I'm always hearing about how XFree86 is just a huge kluge; is there a way to start a new project with 100% clean code, aimed towards more modern video card standards? Probably not... lol.

    That's what Berlin [] is all about.
  • This article assumes that the total time spent developing Free Software is a limited resource, and that it is being squandered by using some of it on redundant applications.

    I would prefer to think that the people he's complaining about were going to want total control over their code base no matter what license they chose, and the fact that they chose Free Software licenses means that if they come up with a particularly good idea it can be easily adopted by other Free Software authors.

    If you make this second assumption then the main effect these authors will have is positive.

    OK, so it's a pain trying to find out which text editor one should use, because the choice is so wide and there is a fair amount of alpha software around, but I take the fact that we can make such a complaint as proof that Free Software is in an extremely healthy.

  • I try to find som arguments for the point that people start new projects instead of building on someone elses code
    • Don' underestimate the difficulty of digging in someone elses code. Every coder has sort of his/her:) own coding style. (maybe not the case for all languages). Developing companies nowadays try to put some developing standards on paper, so that each developer can continue another developers work. In open source projects, certainly those single programer cases without discussion groups, there can be total lack of this.
    • In most cases the code is fairly not documented. Theres a big risk that existing routines are used for what they are not ment for. personaly I had several cases that people report me a bug, but when I look at it, I find some dll that they picked out of another application and then misused for something completely different.
    • As an individual doing it for your hobby, it's maybe more fun to claim the whole thing for yourself. Don't underestimate this psychological satisfaction.
  • Wow, right on. And to think, if it weren't for you, I'd be forced to run off and start my own project... ;-)
  • by heikkile ( 111814 ) on Tuesday October 17, 2000 @11:56PM (#697718) Homepage
    Currently at, there are 179 console-based text editing utilities. How many do we really need? Can't all of the functionality of the 179 be combined into say, half a dozen?

    There is nothing wrong with 179 text editors. Only (say) half a dozen are commonly used, and enjoy the support of a large and active development team. Does that mean that the remaining 173 are harmful? No, they are the undergrowth from where the seventh Great Text Editor will come from. This is where new ideas and features grow, mutate, combine, fight, and die in the best Darwinian evolution. This is also where younger programmers can try their hand on contributing to small projects, taking charge of small parts of small projects, and maybe even managing a whole small project. Once they've spent their apprenticeship here, they will be so much more valuable in the "Great" projects, even if all their little exercises will be forgotten.

    For it does take a lot of effort to join one of the "Great" projects. You need to get an overview of a complex architecture, of a complex social structure, and of the styles and personalities of many key people. You need to study some (tens? hundreds? of) thousands of lines of code just to find where your little fix will fit in. You need to code, comment, and document it in a consistent style, and present it the right way to the right person. Yes, this is a problem with large projects, but how could it be different?

  • I have yet to see a text editor open source or closed, that doesn't suck. Maybe that's why people keep trying to write them.
  • Can any /.'ers think of anything that needs writing, but nobody wants to?

    Bug-free Windows?
  • The basic problem is that people are human. Everyone wants to say "I wrote that program that everyone is using". I started the revolution and the rest of you are just riding my coat tails. Personally, I think that we have too many ICQ clones. How many ways can you make it work? And with good skin coding, you can get any look and feel you want.

    As for text editors, that is a holy war that I won't get into, but I personally use about a dozen different ones depending on the platform (win or linux) and what I am editing at the moment.
  • It seems that the specialized/smaller applications are failing simply because there is no titan and new ones may be simpler to write then screw with the old one. Who wants to go write Apache or Linux? Heh, well probably some, but the point is it would be nutz amount of work.

    A good solution might be a text editor or similar specialized apps built around a very flexible GUI skinning system. Also, something that kept necessary application/setting info in an easy to access spot would help.

    Then if coder x wants a feature he can easily extend this existing program.

    The basic point is maybe we should create open source projects with the _central_ idea that they are _not_ cathedral projects. Incorporate the idea of multi user editing/extension as one of the primary design criterea(sp?). All parts of the program divided up into components. Ideally, interchangable as much as possible.

    If many of these existing projects were easy to extend or there was a common project of each type that was 'known' to be be good, then I doubt as many people would be interested in re-duplicating efforts.

    If you write a text editor that I can easily add features to, I am going to work on that one.
  • OSS Projects are like memes or genes aka Richard Dawkins. Throughout their lifetime they compete for scarce resources: developer time, computational resources and user adaptation. Succcessful ones obtain a lot of resources and prosper, they reproduce and even mutate (code fork). The death of any individual project does not mean the death of that OSS meme, if it's a good meme it adopted by other projects.

    This evolutionary nature is the strength of OSS, the fittest survive and the unfit whither and die (lose developers and user interest). In evolution and in OSS diversity is a good thing. Expecting OSS to only produce one text editor is like expecting evolution to only make one type of insect: after all they are so similiar why do we need 6 million species of insects?
  • Concerning ICQ I think that the reason should be seen commercialy. Claim the whole project and get the money. The cases where there is no commercial or marketing advantage, I still have some respect for the people wanting to be the hero.
  • I agree! Not because I like what you're doing. It's of NO use to me :P The author of the article should just take the source and add his diffs if he wants. Thats one of the uses of GPL. If the master doesn't want to add your diff. 1.make it available or 2.split development. not such a big problem.
  • No engineer is crazy enough to reinvent the wheel, or are any out there?

    No, but most engineer students solve the same problems year after year.

    As has already pointed out, cost effectiveness is not an issue when the cost is zero, since amateurs do by definition enjoy what they do.

    I do agree with you that getting a patch rejected is not a nice experience, I have tried that a few times. There are good and bad ways to reject a patch, as there are good and bad team leaders. Meybe we'd need some sort of tool, a public forum where patches could be submitted and analyzed, commented, and moderated, so as to give more feedback to the submitters? A combination of /. CVS, bugzilla, and automake? Any takers?

  • There has always been massive duplication in amateur software development for personal computers. This isn't some magical new phenomenon of Open Source / Free Software. I can remember the huge redundancy of apps as far back as when I used to get those "fish" shareware collections (or whatever they were called) for my Amiga. Believe it or not, this is a good thing. Why?
    <p><em>It gives people a place to learn.</em>
    <p>Very few coders could walk into a room and immediately start making a difference on a program as complicated as Apache, or emacs. People will always reinvent the wheel, because it's often only by reinventing the wheel that you can teach yourself how wheels work. <em>Then</em> you'll be able to contribute to the super-wheel project.
    <p>In the past, these tiny projects would be not released, or end up on an obscure website, or on a shareware disk. Now, they end up on sourceforge. No big deal.
    <p><em>We can never predict what will be the Next Big Thing.</em>
    <p>Bob's Editor #179 is just another text editor. Cool. And Linux was just another Unix clone. Bring 'em on, and let natural selection sort them out. Those that are well designed, well managed, and fulfil a real need will be adopted.
    <p>There seems to be this myth that programming talent is this finite response, and because Bob is working on project A, that means that project B is missing a developer. (You hear this argument a lot about people writing add-ons for Mozilla, for example.) The truth is that while project B might really do with Bob's eyeballs, there's only a small number of "high involvement" developers that a project can stand before it gets top-heavy and falls over. So Bob isn't really going to waste. And who knows, if he learns something cool writing his own editor, his eyeballs will be useful the next time he upgrades his copy of GnomeNotepad++ and finds an annoying bug in it.
  • This means that you should not code....
  • Okay. Things to do when I get home - write a patch for slashcode that allows people to edit their own posts (provided they have no follow-ups or moderation).

    Smeg, smeg, smeg.

    Charles Miller

  • The author seems to be arguing that since OSS is *too* successful, it doesn't work. Didn't he get the hint when he found out about the *TWO* major OSS desktop environments, with all their corresponding programs?

    I agree that there is a lot of redundancy in Open Source projects, but so what? You don't have to use them all, just try out the top five or so. For text editors, of course there is vi and emacs, and you can use them all day. But if you don't want to, you could use joe or pico, or for that matter, ed or dd+sh! I like nano (an improved pico) and RHIDE (a Borland-style IDE), but I haven't used them much lately...

    However, just to make these people happy, I think we should build a Unix distribution that only allows you to have ONE of each kind of application. I suggest X, twm, mail and ed to start with, and if they don't like that, they can build a distribution that only has mwm, CDE, Z-Mail and Visual Slickedit; then, if they don't like that, they can use only Enlightenment, StarOffice, and nedit; then...

    Personally, I'll just install it all instead, and use what I want. Somehow, that doesn't bother me.

    pb Reply or e-mail; don't vaguely moderate [].
  • another viewpoint: his article is open and public, and people can anticipate and change ideas on it. Its not source, but open ;)
  • i KNOW that open source is the future. (ok, given what i know, i have a really strong feeling that it is.)

    However, there's nothing forcing coders to contribute to open source efforts.

    I feel that it's a good idea to force those learning the trade (schoolkids and cs undergrads) to attempt projects that will contribute to the pool of code that we have. Instead of doing the same old algorythm every year (that allows educators to easily grade the code, and learners to copy previous attempts) do something new. It'll be great training and will contribute to the betterment of society as a whole. It'll also help programmers learn how (not) to write code that can be used by others for tweaking. Because in time, instead of writing code from the ground up, most programmers will be modifying existing "works"

    Students can demo their code or tweaks to code to potential employers to make themselves more marketable.

    so there still is some room for the os movement :)

  • I think this author is uncomfortable with the notion of "wide spectrum of choice", and instead prefers "limited, clearly defined choices".

    And to be fair, it could be argued that his real beef is about misallocations of resources...why work on all of these choices when the collective time could be more constructively spent on fewer choices?

    And trying really hard to be fair, he has an implicit assumption that "reinventing the wheel" is a Bad Thing; we are left to infer his heavy bias against code forking, since this as well would represent a misallocation of resources.

    Open Source is not meant to be efficient. I'd rather have several serious contentders rise from hundreds of choices rather than a couple rise from several choices.

    As for maintainers running fiefdoms, not accepting patches...well fine, that's what the big stick of forking can cure in an instant. Implement the changes that they were planning on adding, give it a new name, and see what happens.

    Diversity of choice is better than limited choice. This might not be the best allocation of the programmer energy pool, but there is a hidden benefit: every line of code that is written represents a learning process for the coder who wrote it. You get a far larger pool of coders with experience under their belt if you let them reinvent the wheel from time to time. Consider it a training exercise. And reap the results, for you can only benefit in the long run.

  • Glasscode [] does it :)

  • When I wanted to hack on (name omitted to protect the innocent) I found no documentation, no design drafts, no flowcharts, no class diagrams, no api-docs, no nuttin'!

    It is not easy to grasp a project with no documentation whatsoever. I think this is a problem with most one-person hacks/projects. It is often easier to do it yourself, than to dig into some unreadable kludge with no documentation.

  • Yes, exactly.
    His point is not that Open Source has this flaw which Closed Software hasn't, it is indeed precisely that Open Source, in this regard, does not improve upon the Closed Source model. At the end of the day, it's still about the politics ! And this despite the nice theories put forward by the gurus, the zealots, the GPL loving crowds.

    So what he says is that despite all those hallelujahs, OSS is in a large way as closed as true Closed Software. You didn't counter him, you supported him :)

    I also hear what he's saying from experience.. It's only in the largest projects that code is accepted on the basis of code merit, quality, usefulness. Which is basically why those projects have become large; 90% of the projects out there are led by people who are just in it for the learning experience. Their code is not too amazing, they don't accept patches, and they manage their projects as badly as they code, so they stay small. That's fine for them, but it's not exactly the Bazaar model. That's all the article says, really.

  • Replace the phrase "open source" with the word "commercial software," and the assertions are just as true.

    They may be just as true, but they're not desirable, and free software means that things don't have to be this way.

    There seems to be a really sharp line between the kind of quality, robust software that a lot of us made the switch away from Windows for, and the bits and pieces of junk that we have to use for other tasks. I have a stable OS, a stable windowing system and window manager, a stable text editor, all full of the features I need to get stuff done. But I have an ICQ client and a Napster client which are maybe 50 to 75 per cent of the way along, and these are the best of breed. I've tried them all. The feeling of "It Just Works" that I once had whenever I needed software to do some new thing is all gone! Who does it serve for coders to release buggy, crashy, badly-written, undocumented code? If you're writing for public release, write well, make it stable, and accept patches. If you're writing YATE as a way of learning to code, keep that code in your pants! Freshmeat doesn't need you to submit console editor number 180. The world at large doesn't benefit from your "My First C" style coding job. So decide what your aims are. If you want to learn to code, certainly start a little project, but don't clutter the world with it unless it's actually release-quality. If you want to add to the pool of programs that people use, get involved with an existing project. That's how you add the most. It doesn't matter how brilliant your new editing feature is if it's been added to YATE that only you and some guy from Sweden are ever going to use.

  • I think this problem is actually worse than some people here seem to believe, not because it kills anybody to have the semi-mythical 179 text editors, but because it tends to build on itself.

    Say you want a program that does 'x' and you go out looking and find 3 at 0.0.1alpha that do 'x/10' and crash or don't even compile on your machine. Which do you choose to work on? Will the maintainer accept or even respond to your patches? Will the project wither away despite your attempt to help? Faced with the prospect of forking the code or giving up on it, a lot of people probably just decide to start their own. Now there are 15 that do varying degrees of 'x'!

  • No, he's not saying they can't code, he's saying that there's no point in releasing those hobby projects as open source; coz, if you decided to write it all again from scratch, then why would anybody not do the same and ignore your efforts ?

    That's a line of thought that's blatantly missing from the cheering descriptions of the bazaar model, it was about time somebody wrote it down.

  • by Anonymous Coward
    A tip: Next time you want to add something to an OSS project mail the "team leader" telling her/him; - Why you need this feature. - How you where going to approach the problem. - When you expect to be finished. Then wait for her/his reply, my guess is that she/he will be more friendly then since you actually bothered to check with them first before implementing and delivering your patch. It's human nature to protect what you believe is your own.
  • by Bert Peers ( 120166 ) on Wednesday October 18, 2000 @01:03AM (#697741) Homepage
    Yeah right. In theory, sure. In practice.. come on. If you submit a perfectly valid patch to a project the size of, say, Apache, and it is refused for obvious political reasons, will you fork ? Ofcourse not;
    • Such projects have a whole team behind them, so you would need at least an equally sized team to take over. Assembled based on what, "they rejected my patch" ? Don't think so
    • Until you take over, all patches and other work will continue to flow to the "real" project. Will you monitor all diffs and apply them to your fork ? Will you update and redistribute diffs that interfere with the changes your fork has made (which might get exponentially worse in time) ?
    For any project worth your time, a code fork is a huge effort, so in practice, a rejected patch means Game Over. Forget all that mumbo jumbo about "taking over" and "Darwinistic environments" (other posts)...
  • Hi, I made my MSc in evolutionary biology, and right now I am doing my PhD in genomics and molecular genetics. I think your metaphore is partly correct, and it would be an interesting subject for discussion, although I'm not sure whether the outcome of this discussion would show OSS in a better light.

    Some food for thought (remember, I am not discussing OSS itself, but rather your metaphore about OSS):

    1. Memes. This is a nice idea, and nothing more. Only very little real research has been done, and there aren't really any models making interesting or falsifiable predictions. To be more precise: natural selection is a mechanism (not a theory, theory of natural selection is another story) acting on entities called replicators. Genes are replicators, and so are certain computer programs. Memes haven't been shown to be replicators, so we really don't know wheter NS acts upon them. Just skip this point.

    2. Theory of natural selection -- briefly, it proposes that the mechanism of natural selection is responsible for evolutionary events: changes of gene proportions in populations, new species being born and other become extinct, and so on. Even if we show that OSS projects are a subject to natural selection, can we generalize as far as that?

    2. Natural selection.. As anyone who ever touched the subject can tell you, natural selection, the driving force of evolution, is "blind" -- it often produces sub-optimal and inefficient designs, and is strongly subjected to historical constraints. There are countless examples for this. How can you be sure that natural selection of OSS projects will (a) act faster than the standard development approach (b) lead to optimal solutions? As an example of sub-optimal design I would propose (i) sendmail (ii) the fact that the majority of Linux daemons are not in chroot jail (iii) from commercial world, Windows, as hampered by historical constraints (downward compatibility at each development stage)

    4. Survival of the fittest. Natural selection is not about survival of the fittest, as the survival is only one of the components of fitness. What matters is the propagation ratio, which can be independent from what really matters for us. Example from the commercial world: bad software with much publicity will propagate quicker than a better one lacking this reproductive ability; therefore, Windows is fitter then OS/2. Can OSS avoid this trap, and if yes, how?

    5. Reproductive ability. Let me stress again: it may have nothing at all in common with ability to efficiently support humans in solving their tasks. A good example for me (but probably a controversive for you) is KDE, an eye-candy, easy to program (I was told), cute. On the other hand: bloated, memory-hog, hard-disk hog, inefficient and really not providing much more functionality than the icewm manager I use on my 486 laptop. When I first installed Linux, I needed something like 40 MB of disk space. This is much less than is needed for a basic KDE installation. How much functionality have I, a simple, biology-oriented user gained? Not much. You call that optimal? To me, it seems more like one of those arm-races the Nature is full of: over-sized dinosaurs, birds with useless tails (handicap principle), trees that are growing three stores high because of the arm-race, instead using the energy for "making love", for example, and so on.

    Closing remark: "aka" means, as far as I know, "also known as". This is the first time I read that genes are "also known as" Richard Dawkins. By the way, although Richard Dawkins coined the phrase "selfish gene", he merely popularised something evolutionary biologists were aware of since Fisher, Haldane and Hamilton.

    Best regards,


  • What's even worse is finding commented source code you can't understand.

    One piece of old broken code I looked at was full of unfathomable abbreviations, both in the comments and debug code. One of the developers was a native French speaker, another spoke a Eastern European language, whilst another spoke english. The abbreviations came from one of the first two languages, but I wasn't sure which one. None of the developers responded via email. The code was a mess, and needed a re-write to get it to compile on my current system. I just couldn't work out what was supposedly going on to get this re-write to work.

    Eventually someone else picked up the code and slowly got it to compile and then work, but by that time my needs had changed.

  • Good coke, high quality coke, the good stuff only your rich father's money can buy!
  • by viktor ( 11866 ) on Wednesday October 18, 2000 @01:47AM (#697745) Homepage
    The author has a point in that many people do the same thing over and over.

    I have, like just about everybody else at some point in their programmer's lives, begun writing a text editor. So, why make the 180th text editing utility? Let's have a look at possible reasons for starting it.

    First, although there are 179 editors, about 177 of them have the same user interface - emacs's. 177 people have thought that the only really good thing about emacs is it's user interface. I, for one, do not agree. I think emacs's strength is the ability to extend it, a feature which almost all the 177 have removed while retaining the user interface.

    So that is a reason to start a new project. All the others have the same user interface, and I happen to think that e.g. Boxer or even MS-DOS 'edit' are friendlier. I like the idea of menus, even in console apps. And I like the idea of them being the main interface to various tasks.

    Second is extendibility. Emacs has it, but unfortunately in a language with which I'm not best friends. Reading emacs's documentation says, basically, "the only way to write a new major mode is to take one that somebody else has written and modify it". The code of all major modes I've seen is very close to unreadable. Understanding them would take an eternity. Learing all 10000 builtin emacs functions would take two.

    So, why not write a small editor in C, extendable through shared objects? Surely somebody must have thought of that. Looking through freshmeat and searching google, it seems that those who have, never released their code.

    The third, and most important reason, is that almost no single programmer in this world seems to document their programs. Sure I can download an editor. But how does it work? Use the source, Luke, 'cause there ain't a single line of documentation. Comments in the code perhaps, but hardly anybody takes the time to write a clear description of how everything fits together, which function does what and how they interact, which standards (if any...) have been used in naming the functions, which data structures there are and how they work, etc.

    The result? It takes about as long time (or so it feels) to write it from scratch as it would take to read and understand the pre-existing code.

    The main reasons behind my futile attempt at yet another text editing utility are therefore:

    1. This editor will not have emacs's or vi's interface, but will be similar to Boxer, something about two or three of the 179 existing editors have.
    2. This editor will be extendable through shared objects. You just compile your .so and load it to get a new mode/whatever.
    3. This editor will have documented code. All functions and their interactions will be documented, even at a high level. There will even be code documentation outside of .c-files.
    4. I will learn a lot writing it, especially the .so parts.
    If there is already an editor with those features, I couldn't find it. Trust me, I looked. Writing curses code to manage console-mode menus isn't exactly my idea of fun. :-) I would gladly have taken an editor that worked like I liked and then extended it with the .so functionality.

    Perhaps my reasons are valid, perhaps I'm just trying to enhance my ego similarly to what has been suggested. Who knows.


  • Actually the comparason to "X and Gnome/KDE/*" would be "GGI [] and Berlin []".

    I think.

  • Well, there are a lot of text editors that is based on the shareware concepts though. And freeware concepts. There are also a lot of commerical text editors (some disguise as word processors). So the commerical, freeware and shareware models all fails too?
  • No engineer is crazy enough to reinvent the wheel, or are any out there?

    I don't know of any software engineers who reinvent text editors either!! And we do have so many different types of wheels too!!
  • It's not that there are a lot of redundant apps trying to be the 'in' program of the day, because that existed before the OSS craze too. It was called 'freeware' and the great ugly 'shareware', where you would be asked to pay $10 for a piece-of-sh*t program (archiver binary front-ends, for example).

    The great thing about Open Source is that the source is open . You don't have to buy a textbook on how to write a text editor, you don't have to completely re-invent the wheel. You can look at how other people did it. And you can even take the bits you like from their implementation!

    I'm all for lots of small projects as well as the huge ones; small projects are far easier for an outsider to read and understand.
  • by DeadSea ( 69598 ) on Wednesday October 18, 2000 @02:13AM (#697750) Homepage Journal
    Why do you start your own project?

    Most open source projects are written with a very specific goal in mind. I'll bet that most people who write a basic text editor, do it as a programming exercise and so they have an editor with a specific feature. Most people who write a text editor don't realize that it is actually a hard problem until after they get started.

    But why is writing a text editor a hard problem? It really should be just connecting a bunch of components. Do these components exist? Rather than write my own text editor, I write some libraries that other programmers should be able to use, such as my syntax highlighting [] package. Rather than start your own project, I encourage everybody to write a blackbox library. The most successful, reusable, able to be modified OSS projects I've seen are libraries. Take a look at the GD image library for example. Its used all over the place. When a programmer wants to be able to save a png, they don't take apart Gimp to see how it is done, they use GD.

    We won't get anywhere unless OSS programmers start writing better black boxes. Black boxes are easy to reuse. Large programs are hard to modif

  • They're releasing them because maybe there is someone out there who wants to see/use the code. If there isn't, no harm done.
  • If you keep rebuilding on old code that someone else did, you get Y2k all over again. Not only that, it's harder for the developer to maintain if he/she doesn't understand it.

    In response to the question posed, there are several neat, new text editors out there that seek to accomplish a variety of goals. But if one editor had all the features of all this software combined, you get emacs, a 40-50MB "text editor". I think that if OSS works the way this guy thinks it should, we would have a kernel, init, a shell, and emacs. That's it.

    Examples of text editors: nano, free pico clone with extra features; jed, editor with hilighted C/C++ syntax; joe; ae; and more. Each of these has its own style to suit its own target, for example nano and ae are not for people who like to memorize lots of control keystrokes.
  • Hmm, as far as I know all the big Open Source projects are coordinates VERY well... You say Open Source works because it is not coordinated? Well I don't agree... Python is coordinated. And it would not succeed if it wasn't. Linux is coordinated. My own project Crystal Space is coordinated. These projects can only work because there is a management team making sure that all contributions are consistant and follow the general strategy of the project.


  • I write code JUST to see my name at Freshmeat. Whata crock of poo. Go away Serge Egelman, and leave us open source programmers alone. I think I'll start working on a new text edit for linux, called the Egelman Editor (EE). It'll have the exact SAME functions as every other editor out there. (except notepad).
  • by jilles ( 20976 ) on Wednesday October 18, 2000 @02:48AM (#697755) Homepage
    Open Source is a method of licensing software, not a way of creating software. Of course there are a few advantages of having your software open sourced:
    - peer review, anyone can look at your software and help find bugs
    - free development, if your product is interesting enough, people will contribute to it

    However, you still need:
    - a plan. This can be a design, a roadmap. Just dumping 8 million lines of code into the community, as Sun did last week, has no short term advantages because it takes time to grasp what it is doing.
    - a process. Large open source projects all have some sort of management/programmer elite that manage the project
    - people, people will not just start working on your product. There has to be some advantage. In all open source projects I know of there is some form of mutual interest. Open sourcing your propietary system designed for internal use will probably not attract many outsiders.

    There are disadvantages as well:
    - if your software contains some innovative solution for a problem, your direct competitors will benefit as soon as you open source your stuff and you may lose your competitive edge.
    - you are not in control (though you can have a strong influence through active participation in development) of the software .
    - you may run into legal trouble if you decide to use commercial components. So you may have to spend time reinventing the wheel

    That's all I can think of. Think of open source as resource sharing. The idea is that you use less resources if you share.
  • I agree.

    Out of curiousity, what are the features you are missing from text editors?

    I think the likes of UltraEdit, TextPad, and maybe JEdit fail to suck. But there are many features I'd have to see all in the same editor before I would call that editor 'good':
    • antialiased fonts - easyier to read, and can be smaller if required.
    • smooth scrolling - so you can read the text and you scroll down, none of this line-at-a-time crap scrolling.
    • syntax highlighting inside strings - a neat feature I saw in kedit, but not yet any other editor.
    • line indenting ala tab in emacs in C/C++ mode - personal pref, but it would be nice to have the option.
    • windows style tab controls for buffers
    (That's not all of them either)

    I'm not holding my breath on seeing an editor with all those that also has the basics (hex mode, syntax highlighting, regular expression searches, unlimited undo etc etc), and I have on numerous occasions thought of writing my own - but I think adding features to JEdit might be the best way to go, just that smooth scrolling (in combination with some other features I have in mind) may need architecture designed to accommodate them from the ground up.
  • In many cases the itch you want to scratch isn't a particular feature but rather an architectural issue. It can either be a technical architecture issue, a social architecture issue or both. Even if a particular piece of software you'd like to extend is "Open Source", it's very possible that you don't have adequate freedom to do so, or that the licensing of the existing project doesn't protect against your code being taken, enhanced, moved into a closed source project and not returned to you. Sometimes another programmer has achieved a feature set you'd like to expand but the technical architecture of the software makes the enhancements you have in mind impossible, so you have to start from scratch. Even though starting from scratch is sometimes necessary with "Open Source" software, the situation is still better than with closed source. You get a sample implementation of a program which you have the option of either extending or using as a learning tool for creating your own from scratch. Looks like a win for the open-source model to me :-)
  • Ideally, it's a "natural selection" sort of process. Lots of offspring (individually written text editors) that go out into the big hostile environment (the internet/geekdom, etc.). Those that survive produce more offspring (contributions from other coders), gradually changing and mutating to better fill their niche or even branching off to give rise to new offspring. You don't structure or control a process like this. Quite properly, the focus should be on contributing to diversity rather than limiting it.
  • Gnu Emacs vs. XEmacs.

    Xemacs was born from a problem enhancing GNU Emacs, and although it *is* a shame to have two versions of a very similar program, it is also good to have the choice.

    I guess sometimes a fork is good (especially eating peas)

  • Whether open source or commercial, software creation takes place in a social context of intelligent male primates who fight for supremacy using lines of code instead of rocks and stones

    Yeah, but mine is smaller than yours.
  • Of course there will be many variations on applications, and that's all right. Imagine what the world would be like if someone had decided that Hamlet was the perfect tragedy, and left it at that.

  • by arcade ( 16638 ) on Wednesday October 18, 2000 @03:29AM (#697762) Homepage
    I see a lot of good reasons to start out a project on your own. If I want to hack on a text editor, its because I want to learn. Actually, I did try to hack on an editor several years ago. I thought it sucked, and deleted my code. Just as well, it was sucky.

    Some people get satisfied with their code. They get proud of it, and want to share it. I've coded some hobby projects and been proud of the code I produced. That was fun. I never gpl'ed the code though (This was 5 years ago, I was still using DOS, and had never read much about the GPL).

    I fully understand those who program something as a test. They program something for themselves, and try things out. When it works, why not share the code? Maybe its not the best out there, but its yours. You want to share it. And why not GPL it when you're at it?

    Another thing. There are needs for more editors. personally I use vi. Its not bloated, its easy to use when you've learned it, and so forth. emacspeople always make fun of me, but i don't really care. I use emacs from time to time too - but its a bit to memoryconsuming for me most of the time.

    I also enjoy the powers of pico, joe, midtnight commanders internal editor, and so forth. Fun to play around with.

    About the rejected diffs. Maybe the author had thought of something similiar, but didn't like this ones implementation. Perhaps he thought the code looked ugly. Perhaps the code didn't abstract the way the maintainer wanted. Who knows?

    The best way to submitt diffs is not just to code something up, if its actively maintained code. Its to ask the author on how he wants it coded, and code it that way. That may be "off-putting" for some, but I for sure wouldn't want to put code that ruined my plans, into my project.

    Hmf. Maybe that's why I can't attract enough people to be bothered starting with my current dream (of the last 3 years). I want a database-driven newsserver/mailing-list/webboard/bbs. That is, I want a database to contain all the articles and logins/passwords, the newsserver should serve all that. Mailinglists for those that don't like news, and webboards to attract the intelligent but computer illerates. BBS-style would be cool too, so that people could remember the good old days :)

    ohwell. :D This got a bit long, and shurely not helt onto one topic throughout, but .. :D

  • Good question. This is a guess since I'm one of the few coders in the world not to have written a text editor. I'd probably start with a 256 byte array for each line of text.

    Then we need a data structure of line pointers. Linked lists are too slow to search. A tree could be used except it would suck. Most lines are added at the bottom giving an unbalanced tree turning it into a linked list. This points to a balancing tree. Something which I hate because they're fiddly to debug.
  • The author makes the observation that there are a lot of folks out there suffering from the same outlook as those who used to mock Ford.

    He never denies how rewarding it is to build something from the ground up.

    He knows that, eventually, the newbies will long for something more rewarding than what a one man show can provide.

    (As a rock is not moved by wind or rain, is a wise man unswayed by praise or censure. -Confucious)
  • Sure there are lots of text editors, but you cant walk unless you crawl. Its all about experience, learning and becoming expert at programming.

    I imagine that the number of programs is inversely proportional to the difficulty. As it gets more difficult, you get less programs.


    (P.S Cheers to all those people at the GreenGate Hotel in Killara, whos alcohol has made this commment possible!)

  • A good solution might be a text editor or similar specialized apps built around a very flexible GUI skinning system. Also, something that kept necessary application/setting info in an easy to access spot would help.

    Except from the GUI part, you are talking about emacs. Everyone can extend emacs without writing a new editor from scratch. That is the reason why emacs is so succesful.

    The problem with an editor like emacs is that the extensions are written by people that allready know the program by heart. They don't care if it ends up being somewhat difficult to use. I don't think you can get extendability alongside with userfriendliness. Somehow you have to choose

  • The key point is that real systems are too big for one person to build, either because there's too much code to write or too much to debug. OSS seems to produce higher quality large products. A basic text editor is at the low end of the zone where software quality is hard to ensure. This issue is not restricted to software--see Christopher Alexander's books on design quality in building.
  • What do we need 179 text editors for when we have ed, the STANDARD UNIX text editor??

    Granted, all 179 are easier to use, but does that mean they're the standard?


  • From the article.

    Just "merely" working for money ehh??

    Never mind that I make 60,000 dollars I am merely working for money that gives me food, puts a roof over my head and SUPPORTS my off the clock coding habits.

    Oh but im "merely working for money" as if that pales in importance to tooling around with OSS software like its going to pay your bills and put food in your refrigerator.

    Oh a few lucky folks get to work on the linux kernel or perl, but lets see peopl were asking for donations just so they could hire one of the most talented perl developers anywhere for 55K / year???

    Wow as much as I love OSS I dont see where we are all going to live on salaries like I make right now.

    (My opinon: Closed software does have a place, paying the bills.), Now you may wonder where the sentiment "OSS is just toys" comes from well this authors attitude really doesnt help its just a shade under zealotry even if thats not his main point.

  • Several times I've been in situations in the commercial sector where entire projects were in need of rewriting for the simple reasons that they were never really designed in the first place and had been through so many iterations of being changed that the code was completely unmaintainable. Some of them started out unmaintainable, like the company that apparently had no UNIX experience and did their design work and initial coding to Borland C++ and DOS, planning to port the code to a muli-process UNIX environment later.

    On the OSS side I tend to reimplement things to learn how a process is done. Reading someone else's code isn't nearly as educational as going through the design process yourself and working out how to do something for yourself.

  • by Izaak ( 31329 ) on Wednesday October 18, 2000 @04:52AM (#697771) Homepage Journal
    The author of the article misses the point of one of the greatest strengths of open source development, instead identifying it as a weakness. Multiple projects working on the same problem means there is a greater chance one of the projects will yield unique and interesting results. Over time, that project will gain a larger following and larger developer base, eventually crawling from the genetic stew of proto-projects to take its place as a land walking *real* open source project. :)


  • I agree...when I search through sourceforge, I must see 15-20 projects in any category which all aim to do *essentially the same thing*. It's like the developers are somehow lost in their own world and don't realize just one click away is a project which is virtually identical to theirs. And most of them are in pre-alpha, planning, etc. stages - we won't see fruits from those projects for months if not years. Sure, I believe in that scratch your own itch thing, but hell, if somebody else has a better itch-scratcher, couldn't you just use and improve that one?

    People are going to say "choice is great"...choice this, choice that. Choices are only great if they each can *do* something for you. 20 pre-alpha projects is not "choice". I think one of the great benefits of Free/Open Source Software is that somebody can *reuse* work that has already been done. But instead, everybody seems to be wanting to start from scratch for the glory of it. Sure, I see some reasons to do this (like Subversion, and that "just-good-nuff" quagmire called "cvs"), but in major catagories of applications, there are often tens (maybe hundreds) of different efforts which are only subtley different. That's just ridiculous.

    Now, I speak as a user when I say I would rather have X *decent* choices than 10*X worthless choices. I speak as a developer when I say I'm sick of putting a year's worth of work into a project to get nowhere because everybody else is doing the same with their *own* pet project which does the same thing.

    Hey: "Come together, right now!..."
  • I am an unashamed XEmacs advocate, but sometimes I need an unbloated editor in a hurry. Vi is good, I can drive it, but sometimes I can't switch my mindset. I need an unbloated Emacs.

    I came across MicroEmacs for Linux, at more or less the same version as used on my Atari ST ten years ago (I used it then for writing my own text editor from scratch, as a learning exercise, and as a model of how to do things right). There's a derived version Linus was involved in, with minimal bug fixes over about five years.

    My point being you have to admire the MicroEmacs developers for achieving both usefulness and long term stability.

  • I like SCiTE/Scintilla [], which is a very simple editor on top of a high-quality text editing control (which can I believe be used as a drop-in replacement for RichEdit on Win32, as well as working on GTK).

    It fits in with my software philosophy - small, fast, works well, looks nice, EASILY configurable (contrast with [X]Emacs), cleanly implemented in a reasonably modern language (C++), no restrictive licencing (ie. not GPL).

    Take a look. []
  • the logical conclusion of the argument is that we should have one program that does everything.

    Except that one-tool-does-all solution is seldom the best solution for a single problem. It's like using a pocket knife for felling instead of chainsaw - it works but it's not the best way. It's the same thing with emacs: you can play games, write mail and read slashdot with it. However, I find it more sensible to use special programs for all of those.

    What I'm currently missing is a small cross-platform text editor with a good interface. Sorry, emacs is out - I want *small* editor with *good interface* you remember? The problem is that it's that hard to make such a thing that those who have tried have found it easier to accustom themselves to use emacs. Unfortunately.

  • A friend of mine is working on a Java text editor for programmers called Jext.

    So there.

  • by big.ears ( 136789 ) on Wednesday October 18, 2000 @05:21AM (#697777) Homepage
    It seems to me that the people writing crappy OSS text editors today are the same ilk who were writing crappy shareware text editors and such 10-15 years ago. Almost nobody made any money off them (with a few notable exceptions), and they probably got the biggest kick out of the dozen or so souls who sent them a $25 check for some game they spent 1000s of hours writing. They aren't being paid for their time, but it is fun nonetheless. This is the same mentality as OSS developers, but nowadays, we've given up the illusion of getting rich off writing a text editor. Everything that the article's author said about OSS is doubly true for shareware, but shareware has played a large role in putting Microsoft where it is today.

    The large number of Windows shareware apps out there adds to the applications count, which at least has an impact in marketing terms: right now, you have to show a CEO a chart that shows Windows as having 50,000 applications, but Linux as having 10,000. (numbers are made up) Where do the extra ~40,000 come from? Crappy shareware games, text editors, disk monitors, and inhouse stuff nobody will ever see, etc. Maybe someone can write a perl script that generates OSS text editor projects, and let it run overnight.

  • Yeah.. im guilty of not documenting home projects..

    At work we do a lot of documenting and user help files (work with editors *ugh*) But it pays off at the user level for their experience. It also pays off at the programming level for our coding ease..

    But I do not miss the impotance of documentation.

  • by Masem ( 1171 ) on Wednesday October 18, 2000 @05:31AM (#697779)
    Text editors are probably the worst example to try to extend the rest of the virtues of OSS to the world. Any intermediate linux user, and *any* programmer, will probably spend 50%+ of their time in a text editing environment. Because of this, and the 'customizability' of linux and OSS in general, these users want that environment to work *exactly* like they want it to. If they don't like how the cntl-A key is bound, they'll rewrite code to change the binding. Of course, the obvious answer here is to use a scriptable/programmable text editor, but as you start adding such features, you start adding bloat, which may result in poor performance. So the reason why there are so many text editors is NOT that ppl want to see their name in lights -- they wrote it to scratch their own itch, and hoping that it helps others scratch theres.

    Compare this to something like web servers. You don't work *in* the web server environment for any significant amount of time, you simply interface with it, either by config files or using standard interface calls like CGI and make sure it performs as expected. The differences between the various servers are mostly various tradeoffs in size and speed vs configurability. And as long as they live up to their expectations to work with all standards they proport to be compliant with, we don't care what else they do. Therefore, others have already scratched that itch, and therefore there's no more work that needs to be done with it.

  • While the author of the article has hit some valid points - such as there being a lot of programs being out there that do similar and even near-identical things - a large portion of the point is missed.

    Granted, if these projects were merged, you'd get a more stable application, but you'd lose a lot of features. I personally use several different editors on regular basis - VIm, gvim, nedit, and gnp. There are different aspects about each that I like for certain purposes. I don't generally like using VIm in X, because I can use my mouse with gvim. nedit doesn't have the same syntax highlighting, and I like it a lot more for quick and dirty editing. gnp (gnotepad+) is nice for opening my config files all at once (for enlightenment) and making modifications that way. It would be fundamentally impossible to combine them into a single editor and still maintain and semblance of usability. There's no way you could combine vi and pico or emacs - they've got different design philosophies and entirely different functionality.

    Let's take AIM clients, as another example. There are X clients and console clients, and designing them as one would be pointless if all you're going to use is console.

    Another aspect to look at is, it's quite possible that a lot of the excess programs, so to speak, are written by people just learning to code, or just getting on their feet with UNIX-type environments. It's an extremely possitive and important thing for them to learn about all the entire framework of a system, coding the program from the ground up - if it will help them on future projects, producing better projects later on. Everyone needs a stepping stone.


  • It seems like the writer of this article thinks that everyone writing GPL'd code wants to create the ultimate operating system to bring down Microsoft (or whoever we're supposed to be competing with). In reality, most of us are writing code because we *like* to, we're not trying to be part of someone's master plan. Personally, I don't plan on being a part of anyone's 'plan' for linux.

  • It probably depends on the scope of the project. Open Source doesn't inherently need to be controlled, but perhaps big projects do. At least until we figure out a better way.

    Caution: Now approaching the (technological) singularity.
  • What I'm currently missing is a small cross-platform text editor with a good interface.

    Try FTE [] You can compile it for DOS, Win32, OS/2 and Linux. It is highly configurable and has syntax highlighting. I've used it for years and know that I've only scratched the surface as far as its capabilities go. One of these days I'm gonna take the time to sit down and learn about all the features I'm not currently using...
    You think being a MIB is all voodoo mind control? You should see the paperwork!
  • Last year about this time I set out writing the heck hex editor because none of the other hex editors did exactally what I wanted them to do. I have had thoughts about morphing it into a text editor. My point is that people work on these things when they see a need. (I'm sure most of you already knew that.)
  • After looking at freshmeat, it is difficult to not accept the authors conclusions. There is a fundamental difference between oss and comercial software. Comercial software is made because other people want it. If no one wants the software, they don't buy it, and the whole thing ends. Oss is made by one individual to scratch their itch. This means that the end product will be different, since the motivations are different. If I want to solve a problem that I see in a oss project, I want to solve it yes, but I also want to do the fun parts too. So why not start from scratch. Still if you take a look at all the software that is available, you can put a linux distribution together that will probably be "what people want" like Red Hat does, or Suse, or ....
  • There are some shortcomings with the open source movement, but I feel that these will be erased shortly as small professional firms become involved by writing customized OSS for the enterprise sector. Take Helix Code for example. They have helped to make GNOME more than just another set of promising technologies. OSS has a lot to offer the commercial world, especially the large server manufacturers like IBM (makes AIX), Compaq (Tru64), etc. These companies can severely cut R and D costs by assisting the development of Linux. According to the IDC, Unix market share of enterprise servers is declining with Netware, while NT is holding steady. Linux is the only NOS which is gaining in this market share (growing at 4 times the rate of NOSs in general). OSS holds tremendous potential, but this is something that will only truly flower when companies find that it makes them money (which it does).
  • I've found from a majority of OSS projects that people just don't know how to design a program. They hardcode to many variables and data, they don't know common design principles and patterns. Most of all, they don't know how write modular code. Most people just put all the code into one big file. When they want to add a new feature, they just keep adding it into the one file a few lines at a time. Eventually the source gets so big and bloated with all these little features getting added. If anyone tries to add anything to this source, they have to wade through all the source to try and figure out what is going on where and how to change the source to do what they want.

    When someone wants to add something to an OSS project, they shouldn't have to edit multiple sections of code, opening different files to modify them all to perform one basic new task, they should simple open one file, modify the functions or objects they want and that's it.

  • I took an Organizational Behavior class once. For the most part it was straight out of Dilbert. But the first day, the professor said, "If you learn nothing else here, remember this. If people aren't doing what you want them to do, look at the reward system." I've found that one idea to have been worth entire semester of writing stupid papers about personality types.

    Here's what the "Open-Source Movement" rewards:

    • Fronting up a prominent project
    • Advocacy

    Here's what people do:

    • Write hundreds of CD player apps
    • Post to Slashdot about how the guy saying ext2 has some weaknesses is obviously a "Micro$hit astroturfer"

    If the Linux media would cover the people who added a crucial new feature to an existing project or the people who write and translate documentation the way they fawn over "Miguel says reusing code is good!" or "Bruce Perens denounces someone who may have inadvertently violated the GPL!" we'd have a lot more documenttion and new features.


  • When I wrote my Tk NotePad a few years ago. -Tkl []

    It is in Tcl/Tk, and soe don't like that. It works on Windows, Mac and *nux. I got several requests from people to add this or that and some even submitted patches.

    The OS model works, but it is hard to find who is doing what. Also it is sometimes hard to follow others code. There really should be coding standards for OSS but some people are into writing code that is not readable.

    Personally I am thinking of merging some of my code from another thing I am working on with another project at

    I don't want a lot, I just want it all!
    Flame away, I have a hose!

  • This second system should produce far better software than the first company. Someone who's doing something as a hobby should be more involved than someone who's working merely for money.

    Is there any empirical evidence to support this claim? It's one of the things I see parrotted all over the place, but that I've never seen backed up.

    And frankly, I take offense at the claim that since I am a professional programmer, I'm "working merely for money". It's sad if that's the only thing that makes you show up in the morning. Also, how is it that since I get paid to make a product, my product is inherently inferior? Does anyone think that this logic applies to anything else ("I don't like the food there -- they pay their chef")?

  • So the newbie is temporarily paralyzed by the whole wide wonderful world of choices he has available. Let him get over it and learn how to make choices. It's good for him, and will make him a better person. I mean, for heaven's sake, if he can't decide on which text editor to use, how's he going to learn to make important decisions, like which clothes to put on in the morning?
  • I've been alarmed by the shere number of projects posted to sites like freshmeat and sourceforge, etc.

    Many of those "projects" are empty. The SourceForge people need to do a purge once in a while. If a project doesn't attract some minimal level of activity, it ought to be purged, or at least moved to archive. "deadmeat", maybe.

  • This second system should produce far better software than the first company. Someone who's doing something as a hobby should be more involved than someone who's working merely for money.

    Merely for money! You make it sound as if earning a living were a bad thing. Of course, the best job in the world is one where you get paid for doing what you would do anyway, but that's no reason to disparage those who hire out their development skills.

    The results of hobbyist development are due more to the fact that hobbyists don't have timetables, can choose their projects, concentrate on the features they like, etc. It has nothing to do with the fact they are more involved. Many commercial developers are equally involved, and dearly love the projects they are working on.

    If there is a problem with hobbyist development, it is because there is a dearth of hobbyist tech writers and hobbyist quality assurance.

    With more people getting involved with writing OSS software, individual applications result without people willing to contribute to other people's work.

    The number of people involved has nothing to do with it. Certainly there are some now that release their works as OSS/FS simply because they think they are supposed to, rather than because they want to, but the typical OSS/FS developer has not changed since day one. Who cares of joe and nedit developers are working on each others' projects? I don't recall vi and emacs developers cross contributing much years ago.

    They seem to want to write everything themselves from scratch. This is how software development works on the commercial level, which is exactly the opposite of what the OSS movement is trying to accomplish.

    How do you know what OSS is trying to accomplish? I'll let you in on a clue... There is no OSS or FS you can point to. All you can find are individuals with indvidual goals and ideals. We are cats! Don't try to herd us! Don't tell me that my project isn't true OSS because I'm not meeting your goals.

    Instead of contributing to existing applications lacking a particular feature or with a certain bug, we're getting hundreds of coders starting brand new projects that differ only slightly from existing ones.

    I think this is great! It's a sign that the coders are free people, that they have the liberty of choosing their own projects rather than being forced into one by some self-appointed potentate. It seems that nary a week goes by that someone here on Slashdot urges either KDE or GNOME to abandon their project and go work on the other. These guys have no clue to what the freedom they claim to espouse even means.

    What would you do? Lobby Algor or Dubya into appointing you OSS Czar so you could have the authority of armies and navies to force people to work on the project you want them to work on? And what would you do when you found some renegade writing Yet Another Text Editor? Lock them away? Shoot them if they resist?

    Currently at, there are 179 console-based text editing utilities. How many do we really need?

    We need each and every one of them dammit!

    I've personally had a few such experiences where I've submitted diffs for a program that someone else has written. A response comes back form the lead developer saying something along the lines of, "Thanks, but I've been planning on implementing these features on my own in a few months."

    So, you're telling me that you submitted diffs for *features* without also submitting plans on how these features fit into the overall architecture of the project, and without taking into account any plans of the project members? I'm hardly surprised that the diffs were rejected.
  • bravo, but some things are just not cost effective and if it wasn't for hobbiests would never get developed.
  • I think that's the wrong way to lok at Emacs - from looking at a number of people who have liked and used Emacs for years (including myself), I've noted that in fact the common view that Emacs is the "all in one" tool is totally false!!

    Instead, Emacs is like a block of iron that has been forged and hammered by each user to be some very wierd yet totally specific tool. Take any two serious users of Emacs, compare configuration files, and watch them at work. They are hardly using the same editor! One of them might have totally difefrent key sequences and processes to do the same thing another user does.

    Think of it this way - scripting languages become popular for certain tasks they make simple. Perl is great if you're doing a lot of string manipulation/matching. Shell scripting is nice for quick automation of simple tasks that can be accomplished with the standard tools, like batch renaming or specialized alteration of files with sed/awk.

    In the same way, Emacs is a scripting language that is tailored to interactive editing. Everything in emacs is geared toward your customizing and extending the heck out of any part of the system, with hooks everywhere and almost any package of any importance being totally configurable in every respect. In Emacs the end goal is to get as much possible done with the fewest keystrokes.

    Take for instance my use of Emacs. I have an emacs configuration file I've carried with me for about twelve years. I have custom macros to help with various programming tasks, like simple code generation (JavaDoc comments, for example). I have syntax highlighting altered to be the way I like it. All of the code indents are just so. I can do things really quickly in it that probably another Emacs user would take longer to do without setting up his own settings.

    Sure, it can read mail as well as write code. But after making it be a great mail reader you'd almost certainly be using a different editor than the focused code-editing construction I've built.
  • nobody wanted them at the time, either

    Yeah, my point.

Space is to place as eternity is to time. -- Joseph Joubert