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.
OSS - what next? (Score:1)
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
Strong data typing is for those with weak minds.
Emacs (Score:5)
Re:OSS - what next? (Score:1)
Yes, comments in code and man files and that stuff. SCNR
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
What's the problem? (Score:1)
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...
It is working anyway (Score:1)
A lot of these software projects have the same goal
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.
Re:OSS - what next? (Score:1)
a tool that scans freshmeat and slashdot and figures out what needs to be written, but where nobody wants to do it.
well then.. (Score:1)
politics are politics, dude (Score:2)
- 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.
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.
We have choices (Score:1)
On The money (Score:1)
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.
-C
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.
Re:Rejected patches (Score:2)
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
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.
---
It's a hobby, that's the point... (Score:1)
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.
Re:OSS - what next? (Score:3)
That's what Berlin [berlin-consortium.org] is all about.
The glass is half full (Score:2)
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.
reasons why? (Score:2)
Re:OSS - what next? (Score:1)
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?
Ooh! One other reason.. (Score:1)
Re:OSS - what next? (Score:1)
Bug-free Windows?
There are times to be diversive (Score:1)
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.
Components and Skins (Score:1)
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.
The Selfish Geek (Score:2)
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?
Re:There are times to be diversive (Score:1)
Re:Okay... (Score:1)
Re:Rejected patches (Score:2)
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?
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:I like to program! (Score:1)
Damnit Damnit Damnit! (Score:1)
Smeg, smeg, smeg.
Charles Miller
--
I don't get it... (Score:1)
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 [ncsu.edu].
Re:naysayer (Score:1)
get universities and schools to contribute (Score:1)
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 :)
small world syndrome (Score:2)
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.
Mojotoad
Re:Damnit Damnit Damnit! (Score:2)
The lack of documentation is a big problem (Score:2)
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.
Mikael
Re:politics are politics, dude (Score:1)
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.
Re:politics are politics, dude (Score:2)
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.
You've got patches, we've got blank stares... (Score:1)
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'!
Re:It's a hobby, that's the point... (Score:1)
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.
Re:Rejected patches (Score:1)
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)...Re:The Selfish Geek (Score:2)
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,
January
Re:The lack of documentation is a big problem (Score:2)
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.
Oh go snort some coke! (Score:1)
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.
Re:OSS - what next? (Score:1)
I think.
shareware text editors!!!! (Score:1)
Wheels, text editors, etc (Score:1)
I don't know of any software engineers who reinvent text editors either!! And we do have so many different types of wheels too!!
OSS is about source, not apps (Score:2)
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.
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
Re:It's a hobby, that's the point... (Score:1)
advantages to separate programs (Score:2)
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.
Re:Okay... (Score:1)
Greetings,
ya, right.... (Score:1)
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.
Re:Ooh! One other reason.. (Score:2)
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.
Some enhancements can't be made to existing code! (Score:2)
I think it's called evolution (Score:1)
Re:Rejected patches (Score:2)
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)
Mike
Re:politics are politics, dude (Score:2)
Yeah, but mine is smaller than yours.
Variation is good (Score:1)
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.
--
Re:So how do you handle data? (Score:1)
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 is right (Score:1)
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)
You have to start somewhere (Score:2)
I imagine that the number of programs is inversely proportional to the difficulty. As it gets more difficult, you get less programs.
Cam.
(P.S Cheers to all those people at the GreenGate Hotel in Killara, whos alcohol has made this commment possible!)
Someone had to mention emacs, so I do it. (Score:1)
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
Re:Why I joined an open source project (Score:1)
The article does have a point. (Score:1)
Granted, all 179 are easier to use, but does that mean they're the standard?
Hmmm?
"Merely Working For Money" (Score:1)
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.
Jeremy
Yes... (Score:2)
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.
The Darwinistic Nature of OSS (Score:3)
Thad
Agree (Score:2)
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!..."
Re:Emacs - (this is not a holy war post) (Score:1)
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.
Re:Ooh! One other reason.. (Score:1)
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. [scintilla.org]
Re:Emacs (Score:1)
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.
_________________________
Actually... (Score:1)
So there.
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.
Re:"Merely Working For Money" (Score:1)
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.
Jeremy
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.
valid, but missing the point (Score:2)
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.
-------
CAIMLAS
Purpose of the writer? (Score:1)
Re:Okay... (Score:1)
Caution: Now approaching the (technological) singularity.
Re:Emacs (Score:1)
Try FTE [sourceforge.net] 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!
text no. hex yes! (Score:1)
This is my itch (Score:1)
Re:Rejected patches (Score:2)
It's because of bad software engineering (Score:2)
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.
Look at the reward system (Score:2)
Here's what the "Open-Source Movement" rewards:
Here's what people do:
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.
---------
um I got pathces features requests etc... (Score:2)
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 sourceforge.net.
I don't want a lot, I just want it all!
Flame away, I have a hose!
evidence? (slightly OT) (Score:2)
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")?
It's called freedom, my friend! (Score:2)
Project glut (Score:2)
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.
OSS/FS Development Is Working (Score:2)
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 freshmeat.net, 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.
Re:"Merely Working For Money" (Score:2)
Emacs - not one tool, but a block of iron (Score:2)
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.
Yeah (Score:2)
Yeah, my point.
__