Slashdot Log In
Shortcomings Of OSS?
Posted by
Hemos
on Wed Oct 18, 2000 03:15 AM
from the how-to-make-things-happen dept.
from the how-to-make-things-happen dept.
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?
|
Log In/Create an Account
| Top
| 124 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
Emacs (Score:5)
The reason there are so many text editors.. (Score:3)
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
Rejected patches (Score:5)
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...
Re:OSS - what next? (Score:3)
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.
Okay... (Score:5)
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.
Why I joined an open source project (Score:3)
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 [citadel.org] 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.
---
Re:OSS - what next? (Score:3)
That's what Berlin [berlin-consortium.org] is all about.
Variety (Score:5)
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?
Blowing human nature out of proportion. (Score:3)
<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.
--
Re:Rejected patches (Score:3)
- 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)...Sometimes you can't edit what's out there. (Score:3)
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:
- 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.
- This editor will be extendable through shared objects. You just compile your
.so and load it to get a new mode/whatever.
- 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.
- 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.Perhaps my reasons are valid, perhaps I'm just trying to enhance my ego similarly to what has been suggested. Who knows.
So you start your own project. (Score:5)
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 [f2s.com] 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
Open Source is not a process (Score:5)
- 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.
Different uses, and so forth. (Score:3)
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.
--
The Darwinistic Nature of OSS (Score:3)
Thad
OSS: the Shareware of th 00s (Score:5)
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.
Text editors are *BAD* examples (Score:3)
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.