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.
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
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
- 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?
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.
Free music from Jack Merlot.
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?
Well, I'm always hearing about how XFree86 is just a huge kluge; is there a way to start a new project with 100% clean code, aimed towards more modern video card standards? Probably not... lol.
That's what Berlin is all about.
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
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
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.
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
Glasscode does it :)
--
When I wanted to hack on (name omitted to protect the innocent) I found no documentation, no design drafts, no flowcharts, no class diagrams, no api-docs, no nuttin'!
It is not easy to grasp a project with no documentation whatsoever. I think this is a problem with most one-person hacks/projects. It is often easier to do it yourself, than to dig into some unreadable kludge with no documentation.
Mikael
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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.
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
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
Out of curiousity, what are the features you are missing from text editors?
I think the likes of UltraEdit, TextPad, and maybe JEdit fail to suck. But there are many features I'd have to see all in the same editor before I would call that editor 'good':
- antialiased fonts - easyier to read, and can be smaller if required.
- smooth scrolling - so you can read the text and you scroll down, none of this line-at-a-time crap scrolling.
- syntax highlighting inside strings - a neat feature I saw in kedit, but not yet any other editor.
- line indenting ala tab in emacs in C/C++ mode - personal pref, but it would be nice to have the option.
- windows style tab controls for buffers
(That's not all of them either)I'm not holding my breath on seeing an editor with all those that also has the basics (hex mode, syntax highlighting, regular expression searches, unlimited undo etc etc), and I have on numerous occasions thought of writing my own - but I think adding features to JEdit might be the best way to go, just that smooth scrolling (in combination with some other features I have in mind) may need architecture designed to accommodate them from the ground up.
In many cases the itch you want to scratch isn't a particular feature but rather an architectural issue. It can either be a technical architecture issue, a social architecture issue or both. Even if a particular piece of software you'd like to extend is "Open Source", it's very possible that you don't have adequate freedom to do so, or that the licensing of the existing project doesn't protect against your code being taken, enhanced, moved into a closed source project and not returned to you. Sometimes another programmer has achieved a feature set you'd like to expand but the technical architecture of the software makes the enhancements you have in mind impossible, so you have to start from scratch. Even though starting from scratch is sometimes necessary with "Open Source" software, the situation is still better than with closed source. You get a sample implementation of a program which you have the option of either extending or using as a learning tool for creating your own from scratch. Looks like a win for the open-source model to me :-)
.sig: file not found
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
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.
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?
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
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?
Many of those "projects" are empty. The SourceForge people need to do a purge once in a while. If a project doesn't attract some minimal level of activity, it ought to be purged, or at least moved to archive. "deadmeat", maybe.
This second system should produce far better software than the first company. Someone who's doing something as a hobby should be more involved than someone who's working merely for money.
Merely for money! You make it sound as if earning a living were a bad thing. Of course, the best job in the world is one where you get paid for doing what you would do anyway, but that's no reason to disparage those who hire out their development skills.
The results of hobbyist development are due more to the fact that hobbyists don't have timetables, can choose their projects, concentrate on the features they like, etc. It has nothing to do with the fact they are more involved. Many commercial developers are equally involved, and dearly love the projects they are working on.
If there is a problem with hobbyist development, it is because there is a dearth of hobbyist tech writers and hobbyist quality assurance.
With more people getting involved with writing OSS software, individual applications result without people willing to contribute to other people's work.
The number of people involved has nothing to do with it. Certainly there are some now that release their works as OSS/FS simply because they think they are supposed to, rather than because they want to, but the typical OSS/FS developer has not changed since day one. Who cares of joe and nedit developers are working on each others' projects? I don't recall vi and emacs developers cross contributing much years ago.
They seem to want to write everything themselves from scratch. This is how software development works on the commercial level, which is exactly the opposite of what the OSS movement is trying to accomplish.
How do you know what OSS is trying to accomplish? I'll let you in on a clue... There is no OSS or FS you can point to. All you can find are individuals with indvidual goals and ideals. We are cats! Don't try to herd us! Don't tell me that my project isn't true OSS because I'm not meeting your goals.
Instead of contributing to existing applications lacking a particular feature or with a certain bug, we're getting hundreds of coders starting brand new projects that differ only slightly from existing ones.
I think this is great! It's a sign that the coders are free people, that they have the liberty of choosing their own projects rather than being forced into one by some self-appointed potentate. It seems that nary a week goes by that someone here on Slashdot urges either KDE or GNOME to abandon their project and go work on the other. These guys have no clue to what the freedom they claim to espouse even means.
What would you do? Lobby Algor or Dubya into appointing you OSS Czar so you could have the authority of armies and navies to force people to work on the project you want them to work on? And what would you do when you found some renegade writing Yet Another Text Editor? Lock them away? Shoot them if they resist?
Currently at 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
bravo, but some things are just not cost effective and if it wasn't for hobbiests would never get developed.
How we know is more important than what we know.
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