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.
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.
Strong data typing is for those with weak minds.
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.
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.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
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
Just because there are a lot of similar software projects doesn't mean that the oss model does not work. ...but they do things in a different way.
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.
I is a one-armed man with mad itchin' on the wrong side of my back.
Liberty.
- 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.
Would you like to touch my monkey?
"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.
Banu
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.
-C
"This above all, to thine own self be true"
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!
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.
---
How am I supposed to fit a pithy, relevant quote into 120 characters?
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.
I believe posters are recognized by their sig. So I made one.
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.
Debian: GNU/Linux done the Linux way
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
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.
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
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?
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.
--
The more I learn about the Internet, the more amazed I am that it works at all.
This means that you should not code....
"As I always say, why jack-off when you can jack-in!" - Plughead from "Circuitry Man" (1990)
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 more I learn about the Internet, the more amazed I am that it works at all.
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.
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 ;)
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.
Mojotoad
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.
Mikael
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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'!
All kings is mostly rapscallions. -Mark Twain, The Adventures of Huckleberry Finn
Good coke, high quality coke, the good stuff only your rich father's money can buy!
The current Slashdot moderation system is made by gay communists!
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.
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.
Does my bum look big in this?
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
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.
# debian/rules
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).
-- "Perceptions create reality. By changing your perceptions you change your reality."
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
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 :-)
.sig: file not found
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.
"When I grow up, I'll be stable."
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.
Karma only matters to me now and zen.
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.
:)
:D This got a bit long, and shurely not helt onto one topic throughout, but .. :D
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.
--
"Rune Kristian Viken" - http://www.nwo.no - arca
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.
Cam.
(P.S Cheers to all those people at the GreenGate Hotel in Killara, whos alcohol has made this commment possible!)
-- Cheer, Cheer, The Red and the White.
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
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?
Hmmm?
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
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.
Jeremy
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Thad
The Bolachek Journals
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!..."
It's 10 PM. Do you know if you're un-American?
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.
So there.
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.
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.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
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
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
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.
The best way to accelerate a windows box is at 9.8 meters per second square.
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.)
May your soul reach heaven before the devil realizes you are dead
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 ....
I personally use only xemacs, but the fact is that it sucks big time, too. All I want is a decent programmer's editor that's fast and has all the features I want. Not one that I've seen; there's latte but that's ... whatever.
:)
The 180th entry in freshmeat is going to be mine, I'll just write an editor with all the features of ced and golded from amiga.
thanks!
--exa--
- For example, think about a newbie, he wants to use a new editor, he asks in a forum "which editor should I use?".
He will receive MANY answers: joe,vi,pico,emacs,nedit, etc,etc...
The number of answer will confuse him, and will create some troubles, he will ask emacs-related question in a group of users which only use vi for example, well you get the idea.
So having such a big diversity is a "bad" things for a newbie, it confuses him..
- Another example: At one time, I wanted to do some code review of a console in order a) to learn how a console works b) improve the code of the console if possible.
Which console? Well frankly I don't care, the only thing I wanted is to find a well-written console which would be used for a long time..
But the problem is that there is a big number of console (kconsole,xterm,kvt, etc..), and frankly I don't want to spend years looking at all the sources in order to see which has the "best" sources before helping the "best" to become even better..
So, unable to choose, I gave up..
Could I have submitted a patch to someone else's project? Probably. But replacing the primary key in a CD database would have made for a pretty big patch. Besides, I wanted to prove to myself that you could write a graphical app using Perl and Qt. I wanted to prove you could write a database app that didn't require a database server. I wanted a graphical app with a command line version available. And I also hoped that other CD catalog authors would take my disk ID concept and include it in their real cataloger programs, since that feature is pretty common on "other platforms."
So far (AFAIK) that hasn't happened, but I'm still hopeful. Meanwhile I've gotten a few new-feature patches emailed to me, but haven't incorporated them yet. Why not? Well, the program does what I need it to, after all, and the patches would have extended the functionality further beyond that of CD cataloger. I no more want to browse directories with a CD cataloger, for example, than I want to read news with a web browser.
I also want to revamp it, probably rewrite it in C++ as a fullblown KDE app, include MySQL support because text files are way too slow for million-record databases, RPMify it the way you can't easily do with perl programs with dependencies, but all that is Real Soon Now.
This makes me part of the problem, I know, but I hope I've at least explained why it doesn't bother me.
*And I did actually write a text editor - my very first Tcl experiment was a Notepad clone. I also had the sense to never release it ;)
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.
:)
Explain then Windows 1.0 and Windows 2.0
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
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.
Outdoor digital photography, mostly in New Engl
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.
---------
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!
Only 'flamers' flame!
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")?
Your favorite
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?
Repeat after me:
"We are not a team."
The assumption that people who write programs in their spare time are part of some big "team" lies behind most of the "Why don't OSS/hobby programmers work together on projects rather than choosing to work separately?" pieces that turn up on a regular basis.
Some people seem to think that its tantamount to a crime for an individual to want to start a project of his or her own, especially if its proposed functionality overlaps that of an already existing program. Why is this? What we do in our free time is our own business. Several posters have already noted valid reasons for wanting to start a project yourself, including educational value, difficulty getting involved with a project already underway, trouble reading code that someone else has written, etc. I'd also like to propose another reason. People reinvent the wheel because they think previous implementations suck. If I had access to the MS word source code and decided that I wanted a fast, lightweight, command-key-driven (Don't talk to me about wordstar...) word processor, would I be better off trying to prune and reshape MS word or simply starting from scratch?
Where do you think revolutionary changes come from? Starting with a clean slate truly gives you freedom, although admittedly usually at the cost of greater effort.
Would the Wright brothers have ever built a working airplane if they had just bought a standard wagon & team of horses and worked hard on modifying the pre-existing model of transportation to add the "flight" feature?
I have no linux agenda. Don't get me wrong: I think that having a free unix clone is just great, and I love the fact that I can examine the code of all these neat programs I use, but I don't expect linux to take over the world, nor do I expect it to become the OS of choice for the masses without undergoing a frightening (and to me undesireable) level of "windowsification". Why is this relevant? I think another unspoken basis for the "OSS programmers should just contribute to existing projects unless filling in areas of functionality that have not been covered" sort of rant we just read is the feeling that hobby/part-time programmers who write software for linux are all part of some big, loosely-coordinated team (with Linux & a few others vaguely directing from the top) whose goal is to build Linux into The Perfect Desktop OS (tm).
Well, it's not so. People code for free because they want to, and if anyone thinks someone can be easily coerced into spending personal time working on another person's pet project out of a vague sort of trumped-up community responsibility, then I refer them to the aphorism about herding cats.
Linux filled a niche, stimulated lots of related development, and became fairly successful. Changing the primary mode of development from individual-desire-based to community-directed is a big step, and one I'm not sure should be taken, even if doing so were possible.
This is all fun, but it ain't The Glorious Revolution, folks.
zeke
Have you ever tried EZ? Part of the Andrew Toolkit. Not the greatest editor, but it starts out with emacs-like keybindings and it's quite customizable...
--
"It's tough to be bilingual when you get hit in the head."
By far the biggest problem the OSS community has is poor communication with users and potential users.
Marketing is creating a connection between an effort and potential users. Most OSS leaders don't think about marketing, or don't think about it sufficiently.
OSS project web site home pages often don't even have a few clear paragraphs about the purpose of the software! This is true even of large, excellent efforts like the PHP Hypertext Processor and the Python Programming Language.
Poor communication creates a high barrier for potential users and for potential developers. Better communication is the single most important area of improvement that could increase the spread of Open Source Software.
If you have an open source software project and need help with communication, email me. This seems to be the way that I can best contribute.
Michael
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.
it just amazes me that the author of this said the word hobbie a million times without once considering it's meaning. When I write my software I do it for the fun of doing it. I consider releasing it as a nice thing to do, just in case someone might find a use for it or one of it's routines. I don't expect people to fall all over themselves to use it, that's not why people participate in hobbies. I think the problem here is that the open source community was started by people who NEEDED something. Now we have the opposite problem, it's hard to think of something ANYONE needs and doesn't have a million solutions for. The open source community wasn't started by hobbists...it was started by professionals who needed software that didn't exist. I think we need to realize that people aren't programming for anyone but themselves now and there's almost nothing to write that hasn't already been written.
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 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.
A Government Is a Body of People, Usually Notably Ungoverned
needs a
."http://www.w3.org/TR/html4/struct/text.html#ede
9.3.1 Paragraphs: the P element
[...]
Start tag: required, End tag: optional
Charles Miller
(I don't do XHTML yet.)
--
The more I learn about the Internet, the more amazed I am that it works at all.
I know what you mean about often needing a simple editor to get something done quickly. I sometimes use vi, but if the system has Emacs installed at all I use gnuclient.
.emacs, but it's one or two lines.
Simply, gnuclient lets you attach to a running emacs process and edit a file, so you do not have to wait throug the emacs load time. So, you'd type something like:
gnuclient -f filename
and away you go - C-X # makes the buffer vanish and ends the gnuclient session. In Xemacs it brings up a seperate window with the file to be edited which goes away when you are finished.
It does involve a little setup to start the gnuclient server in your
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
nobody wanted them at the time, either
Yeah, my point.
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu