Slashdot Mirror


Shortcomings Of OSS?

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.

7 of 124 comments (clear)

  1. Emacs by apm · · Score: 5

    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.

  2. Rejected patches by heikkile · · Score: 5
    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...

    --

    In Murphy We Turst

  3. Okay... by Cuthalion · · Score: 5
    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.
    --
    Trees can't go dancing
    So do them a big favor
    Pretend dancing stinks!
  4. Variety by heikkile · · Score: 5
    Currently at freshmeat.net, 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?

    --

    In Murphy We Turst

  5. So you start your own project. by DeadSea · · Score: 5
    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

  6. Open Source is not a process by jilles · · Score: 5

    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.

    --

    Jilles
  7. OSS: the Shareware of th 00s by big.ears · · Score: 5
    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.