graphical version of VIM has menus and supports "point-and-click" operation.
So does Emacs on Windows or X. It feels like Notepad with different key bindings, and even those can be remapped.
I knew I should've mentioned Emacs. The only reason I didn't is because I don't use it myself. But like VIM, Emacs has a learning curve associated with its more advanced features. I think it's extremely unlikely that a complete newbie could sit down in front of Emacs, and figure out how to do something like swap the last field in a file of comma-separated-values with the first field.
(in vi that would be something like:s/^\([^,]*\)\(.*,\)\([^,]*\)$/\3\2\1 -- I'm fairly certain you can do this in Emacs as well, but I don't know how, because like I said, I don't use Emacs)
Another tool that is reasonably "point and clicky", but is also quite powerful for the expert is AutoCAD. I don't use it myself, but my Dad uses it all the time. AutoCAD has at least two integrated languages (its basic "command language", and the more advanced AutoLISP), so it's very configurable. My Dad, not being a programmer, has never ventured into using AutoLISP. Some other people at his company have written simple scripts to automate tasks that they do frequently. The interesting thing is that the more "advanced" users can help to tweak things and make them better for the less advanced users. Without scripting capbility, that wouldn't be possible.
I think you're completely missing the point here. While scripting arguably makes life easier for power users, it is pretty much useless for novice users. Shells, emacs and vi are nice if you already know what you're doing. Sit a computer newbie down at a login: prompt and give them the task of writing an email to their buddy in Australia, and you'll see (or not) just how necessary scripting is for a good user interface. I'd argue that one of the most basic needs for a good good user interface is for a user to immediately be able to identify the first step they need to take to perform a desired task.
Actually, I think you're missing the point. Experts are users too. For experts, a user interface should probably include scripting. Even newbies eventually get to the point where they would like to automate some tasks. The "Startup folder" idea is an extremely simplified type of automation.
And your assertion that "one of the most basic needs for a good good user interface is for a user to immediately be able to identify the first step they need to take to perform a desired task" doesn't always hold true. Compare Notepad to vi. Notepad meets your criteria. Does it have a better UI though? You'll probably argue that it does, but many will argue that it doesn't. The thing is, the better UI depends on the person. If you edit a text file once every couple of weeks, notepad is probably great. It gets the job done, and you can figure out where stuff is. But if you edit text files all day long every day, vi is probably better. Sure, it's got a steep learning curve, but it's worth it for those that need to edit text a lot.
It really comes down to whether you need a basic "I just need to do this simple job" UI, or an industrial strength UI. You simply can't make a simple UI for certain tasks, because these tasks are inherently complex. An F16 has a more complicated UI than a VW beetle, and for good reason. It does a lot more.
Of course, in the world of software, we're not restricted to static fixed UI's. Some programs are starting to offer both an easy UI and a powerful but complex UI in the same package. VIM is one example. The graphical version of VIM has menus and supports "point-and-click" operation. While in insert mode, it behaves quite a bit like an improved Notepad. But it's still got all of the normal vi features (and then some...). You can make mappings, and write scripts to do common tasks. You can even get it to behave almost identical to the original "plain ol' vi" if you like. The one big problem with VIM for newbies is that it starts up in "normal" mode (aka command mode, or "beep" mode).
Perl loses because people can't write good code? Please.
No, Perl loses because empiraical evidence shows that people don't write maintainable code in Perl. A reasonable explanation for this seems to be that Perl doesn't encourage people to write maintainable code, and instead encourages people to write a million "quick and dirty one-timer scripts", stick 'em together, and hope the mess does something useful.
Perl is good because you can write beautiful, very maintainable code.
You can also write beautiful, very maintainable, x86 assembly code. Neither language encourages you to do it though, so it'll take you a heck of a long time to get anything useful accomplished. At least with assembly code there's an efficiency benefit. Perl's only strength seems to be its ability to let a person write one-liners that not even the author can understand a month later.
Perl is also good because you can write quick and dirty one-timer scripts to do anything.
Really? To do anything? Write a 3D FPS in one line of Perl. No calling out to other programs allowed.
Seriously though, Python lets one write quick one-off's just as easily as Perl. The main difference being that Python one-off's can then be incorporated into real applications without hurting the maintainability.
The best description of this that I've ever heard is that Perl gets out of your way so you can focus on what you're trying to accomplish.
Perl's goofy syntax gets in my way.
Just because languages like Python, C, C++, and Java are pretty structured, it doesn't mean you can't write unmaintainable code.
I never said that you can't make unmaintainable code in Python. Nor did I ever say that you can't make maintainable code in Perl. What I'm saying is that Python code tends to be very maintainable, while Perl code tends to be very unmaintainable.
A likely explanation is that Python encourages good programming style (ie: maintainable code), while Perl actually encourages bad programming style (ie: unmaintainable code). Having used both languages, I believe this to be the case. Have you used both languages?
Note that I never said Python was perfect either. It's got its warts. There are some things I'd really like to be fixed (like the namespaces issue). A lot of people seem to be turned off of Python because of the indentation thing though. That's unfortunate, and immature. You indent your code anyway. Do you worry about indentation gremlins going and un-indenting it during the night? Why do you think that will happen with Python code?
If you don't agree that Perl encourages people to write unmaintainable code, explain why virtually all Perl code is virtually indecipherable. Why do even Perl programmers joke about the "write-only" characteristic of Perl?
For example, say I want to dial-in to the Internet, download slashdot every morning at 4:00, parse out the crap, format it into latex and send it to my other computer and post it into an sql database. This could be done with *nix and perl in about 3 cans of jolt cola. Name one other OS/launage that could do it in that short of time, and have it work well.
Um, how about Unix and Python? And as an added bonus, you'll still be able to understand the script a year later.
Yes, it's possible to write readable Perl code, but virtually all Perl programmers don't write readable code. That's what happens when your language doesn't encourage good style. Since maintainability is the most important feature of any serious programming language, Perl loses.
6) Does it have words in it? Does it need to be parse?
I'm not even sure what the above means because... it doesn't parse. What are you claiming? That Perl doesn't need to be parsed? That other languages don't need to be parsed? Either way, you'd be wrong.
One closing thought: gzip still forces us all to use tar - don't give me that old 'UNIX division of labour' thing, I think everyone knows that division of labour and specialisation can be taken too far! Personally, it'll be a long time before I move away from zip and unzip to gzip/tar.
Agreed. Ever try the -z option of GNU tar?
tar -zcvf foo.tar.gz a b c d # to compress
...
tar -zxvf foo.tar.gz # to extract
That said, I do remember using PKZip back in my BBS days. There was even an Amiga version called "PKAZip". It was a GUI utility. On the Amiga, lharc, and later "lha" were more popular though. ("arc", "pak", and "zoo" were also popular really early on...)
Today I use the infozip utilities for zip files though. They're available for all of the platforms I use, and they extract directory structures by default. (that was always my big complaint with pkunzip tools...)
I checked crowds.org and its not regestered. crowds.com is owned by some German guy who hasn't put much of anything up. And crowds.net is also regestered.
The way things are now you can't lock users into your distribution because anyone can take it, sell it, and support it without paying you a cent. This means that Linux companies have to rely on things like their ability to SUPPORT their products. Poor guys...it's a tough world.
You're over-trivializing the difficulty of selling GPLed code. With GPLed code all you really can sell is support and distribution. Trying to do development is a waste of time, because all of the other distros can benefit from your development work just as much as you can. You can't come out ahead by expending resources on development, so why waste them? It's a lot more profitable to do no development at all, and just incorporate whatever updates are produced by outside developers.
The playing field is leveled only in the sense that technical superiority no longer exists, because anyone else can copy your work. Perhaps one day we'll "level the playing field" in support to, where one company can charge customers for support calls to another companies tech support lines.
Now, in Caldera's case, I think it is kind of silly for them to complain. They're getting Linux for free, and they can make money off of support. They just shouldn't bother doing any development, because you can't make money off of open source development.
But what about developers? Being a developer, I know I don't like it when people tell me "make your money off of support". I'm a developver, not a support rep. Will developers ever get paid for their open source work? There's no reason for the distros to pay developers, other than PR purposes. (and even then, they only pay for a measly percentage of the development that goes into a typical distro)
As it is, open source is mostly written by people in their spare time. If you want more software to become open source, somebody had better come up with some sort of business model where the developers of this software can actually get paid for writing it. Yes, you can argue that open source developers don't do it for the money. I know, I've worked on open source projects. But developers are mere mortals -- we need to eat, and pay the rent just like everyone else. I simply can't do open source development full time, because I wouldn't be able to pay the rent.
There'd be a hell of a lot more open source software, and the general quality would be much higher, if developers could work on it full time. Right now, most can't. For those of use who don't like being an "expense" (like developers who work for distros), or writing custom hacks for a living, the only route right now is to write non-open code for a living.
And here's a hint for those of you thinking that developers could survive off of donations: why should people who do useful and valuable work have to live off of charity?
Re:I don't think this is a film about scientology.
on
Battlefield Earth
·
· Score: 2
Contact was OK, not nearly as good as the book of course, but not too butchered for a Hollywood film. Same with Sphere. Apart from that I can't think of any really. As an aside have you seen Cube? Now there is a truly intersting film.
I agree that Contact was okay. I was actully quite impressed with how little they mucked up the story. (It still was quite different from the book, but I think it got most of the important points across)
But Sphere? It's weird, the first time I read the book, I didn't like it. I tought the ending was... sucky, for lack of a better word. Years later (a couple of months before the movie was released), I decided to read it again, and then I realized that there are two interpretations of the ending - one sucky, one not. In fact, the alterntive interpretation was pretty cool, but harder to recognize. The movie's ending was very definitely based on the sucky interpretation of the ending, rather than the cool one. Too bad.
I was surprised, almost 90% of 500-600 people who showed up to an ESR talk responded that they did not get paid to develop commercial closed software products. Most of those people write internal code for companies.
Since when is internal code "non proprietary"? And in any case, the kind of code that people write for internal use is generally not useful as open source because it's highly speciallized. Quite a lot of it entails putting together tools made by others, and adding glue code. In other words, custom hacks.
Who pays for the development of that non-specialized "in-between-the-glue" code? I don't want to be writing custom hacks for a living. I want to write well designed, general software that people at more than one company can actually use.
How many of these people (the 90% you mentioned) were "software developers", and how many were sysadmins? I don't want to sound elitist, but I really don't think someone who works as a sysadmin all day would make a good software developer, in general.
Good software developers learn to always think about the boundary conditions, and to solve the generalized problem. Sysadmins tend to think in terms of "how do I fix this one particular problem on this one machine I'm running into today?"
[If it's true that 90% of open source developers are sysadmins, that might explain some of the truly crufty code I've been looking at in the GIMP...]
Only you >10% of programmers are in danger of losing your jobs (and you guys could salvage it if you'd get sponsorship)
Please clarify what you mean by "you guys could salvage it if you'd get sponsorship".
but you get all the press, you guys take up most of the advertising space, and hence think that you're the most important/most populous portion of the industry.
Sounds like the open source zealtots on Slashdot, actually. I'd guess that less that 1% of Slashdotters are open source zealots, but they make 99% of the noise (once you remove the blatant trolls).
I'd wager that 90% of the software that 90% of people use was written by that "10%".
If I have a copy of a piece of GPL software, I can personally do whatever I want with it. I can even sell it, if I can find buyers (ask Red Hat!).
That's a very big if. Who would buy your software, if they know that once it's released anyone, including their competiotrs could use and redistribute it. Notice that RedHat doesn't buy the software on their CD's. They get it for free. GPL software is, for all practical purposes, "free beer". People won't pay for the beer, if they can get exactly the same beer for free. (well, maybe they would if they've had too much beer to start with...)
I was disturbed at his belittling of the success of the Free Software movement. I don't think that I agree that people that release their work to the community through the GPL get nothing in return as he claims. He attempts to dismiss what they get as being purely egoboo/recognition, but that sort of recognition translates into employability! It seems as though he doesn't appreciate this.
Employability doing what? Oh wait, I know the answer: writing closed source software.
One of the problems with most open source zealtots is that they don't seem to realize that the closed source software economy is what pays the salaries of the vast majority of open source software developers (like myself).
I would be happy to see a system that was a "happy medium", where source code was available so people could fix bugs, and developers would get paid for the work they do. That system doesn't seem to exist in the real world (though Asynchrony seems to be pretty close). Such a system cannot exist if people expect to be able to get software completely "gratis" though. Somewhere along the line, someone has to pay for the development costs.
This "right" of _possession_ is enforced by the military over the right of life, liberty and happiness. That's what's happening in Chiapas now and in many other places around the world where ordinary, decent, intelligent, hardworking humans are beaten, murdered and raped to keep them producing cheap raw goods for export so that our ordinary decent people will work for less so that the uncivilized and barbarous "middle class" can pontificate about perfect free-markets.
I have to laugh every time I see someone bring up people in third world counries who are "beaten, murdered and raped", as if somehow the abolotion of IP laws will make any difference to those people. Yes, there are serious human rights and poverty problems in the world. Bringing it up in a discussion of open source software is about as relevant as saying "do it for the children" though.
Here's what I'd like: a system where everyone's basic survival needs are met, and beyond that, people are rewarded proportionately to their contribution to society. Does open source help bring us closer to such a world? Nope. The "free market" with IP laws (and enough social programs to give people basic survival needs) is a lot closer than a world with no IP.
You are right. Not everyone agrees with me. Ok Allow me to rephrase. According to my definition of "Property", information (ie intellectual works) do not qualify as property. I recognize that others do see them as property and try to respect their worldview, however, I do not and will not share that world view, and will only allow my actions to be dictated by that world view as I deem apropriate.
Allow me to paraphrase:
"According to my definition of 'Property', anything I can get my hands on does not qualify as other people's property. I recognize that others do see them as property and try to respect their worldview, however, I do not and will not share that world view, and will only allow my actions to be dictated by that world view as I deem apropriate."
The ability to produce New Good Music is scarce. Once it is produced, there is no scarcity. I have no problem with hireing musicans to play music, or going to concerts etc etc. Certainly they are talented and should recieve compensation for their talents.
Yes, and how's that going to happen? Noone will pay for it if even people who don't pay benefit equally.
Yes, money is a big motivator. However it is not the only big motivator. Most people are not solely motivated by money.
Money is the most practical way to get food, clothing, and shelter.
You are assuming that there are rights to lose. What you are asking for is not rights to a piece of property but the right to dictate the actions of others. If Alice writes a poem and gives Bob a copy, Then Bob gives a copy to Carol, then how dows the Bob/carol transaction effect Alice? For alice to claim the right to stop the transaction, she is claiming the right to influence transactions between other people, that do not involve her.
The transaction affects Alice because the value of what she has produced has decreased. Ever hear of supply and demand? If there's an infinite supply, the price drops to zero. That would be fine if Alice spent $0 and zero time writing that poem. But if Alice spent the better part of a year writing that poem how can she survive if she can't get paid for it? In an ideal world, the "cost" of producing the poem in the first place would be divided among the people who benefited from it, proportionately to how much they benefited from it. Right now, the free market with IP laws are the best approximation of that we've got.
Consider software development. Thousands of man hours (of highly skilled people) go into producing your typical piece of software. Yes, there is 0 replication cost, but what about that up-front cost? Who pays for all of those developers, and the equipment that they need? I know you're going to bring up open source, but how many developers do you know who actually make money writing open source? Almost all open source developers have a day job writing closed-source software (myself included).
Does this make publishing music less profitable? Yes it does, it means CD pressers would actually have to compete with eachother. It would mean anyone who can press a CD is their competition.
Yes, it also means that content creators get zip.
Does it mean artists wont be able to make money? Hell no. They can still perform.
Explain how people who create digital media like electronica musicians, computer animators, and software developers can make money from "performances". I can already tell that for software developers you're going to say "sell support". Hint: developers don't do support. Support sellers don't need developers, and so they won't hire them.
There will always be a market for live performance. If that doesn't pay well enough, then they will either need to change how performing works (charging more, giving artists a greater cut) or...shudder...get day jobs
Oh yes, get day jobs. because those damn musicians, artists, and software developers don't provide any real value to society. If they want to create, they can do it on their own time. If they want to eat, they can go scrub some floors or something. It's just too bad that the quality of work produced will go down so much, since none of the content creators would be able to afford to do it full time... darn.
BTW, I really liked the way you totally avoided Kaa's point about contracts there.
I believe people should be rewarded for the amount of value they contribute to society. Captalism and IP laws aren't perfect, but they give a reasonable approximation of this. I'm completely open to better approximations, but I've yet to see a proposal for one that seems feasible. Your beliefs almost completely remove the ability for creators of information to be rewarded for the value they contribute to society. The only motive I can see behind your beliefs is greed: you want to be able to get content gratis (for free, as in beer). You don't seem to care if someone spent months or years working on something. I guess you just figure they're a sucker who made something you can use for free.
Ummm, so wouldn't using the themable widgets AND creating a 'crappy Microsoft UI theme' let you have it both ways without code-evil?
Nope. maybe you should go back and read the article, right where it said:
"Oh, sure, somebody will labor mightily to produce a skin that looks just like each native OS, and he or she might even come close to pulling it off. But close doesn't mean much in a world where subtlety and nuance actually matter. Common, native controls exist for a reason, and that reason is not to serve as a model for crude simulations."
Swing, the new UI package that ships with Java <blink>1.</blink>2 (and is also avaialable for 1.1), uses "lightweight" components for almost everything. It comes with a Windows 95-esque "look and feel", but it isn't the real thing. It doesn't feel like the real thing, and it doesn't quite look like the real thing. And if you mess around with your desktop settings, or upgrade to a version of Windows where the components look different, the emulation fails miserably.
That said, I would have nothing against a desktop that was "themeable". The main requirement is that the "themes" should affect everything. Why should my MP3 player look any different from my chat client? Sure, if I want different apps to use different themes, that could be an option. But my point is, the theming/skin system should not be in individual applications. It should be in the UI system itself, so the user can easily have a consistent look and feel to their environment.
GNOME and KDE are making some progress towards that goal. Unfortunatley, GNOME at least (I haven't tried KDE yet) still makes a distinction between "toolkit" themes and "window manager" themes. This is insanely dumb.
Of course, X's problem is that every frigging application uses a different toolkit, so all the widgets look different. And my window borders are rendered by yet another program. My desktop ends up looking like a garage sale, unless I'm very selective about which programs I run. Oh joy!
The UI of your typical X application is rendered by two things: the toolkit that the app uses, and the window manager. The toolkit applies its own look-and-feel, and the wm applies another to the border.
If users chose toolkits, they'd probably pick the one that was easiest to use, or most aethetically pleasing. Users don't choose the toolkits though, developers do. So the toolkit is often chosen because it's easy to program with (eg: KDE), available in the Developer's programming language (eg: Tk), fits with the developer's politics (eg: GTK+), or is some sort of "corporate standard" where the developer works (eg: Motif). None of these reasons matter to the user, yet the user is the one that's ultimately affected. Even if the Develper does try to select a toolkit based on usability (one or two of us actually care about things like that...), the developer's sense of aethetics and usability might not be the same as all of the application's eventual users.
So how do we fix that? In an ideal world, applications would merely provide functionality, with a UI that was specified in terms of what they want to say to the user, and what they need to know from the user. A user abstraction layer (UAL), so to speak. The system would have a UI Manager (UIM) that would act something like a super-window manager. It would handle all of the things that today's window managers handle, but it would also handle the look and feel of window contents as well. The interface between the UAL and the UIM would be standardized, so that users could install a different UIM if they wanted to, and all of their existing apps would benefit from it. The UAL would also be standardized, so that numerous toolkits could exist for it. Developers could then choose any of these toolkits, based on what matters to them. Users could choose whatever UIM they wanted, and configure it however they please, knowing that their customizations will affect all of their applications.
So is that hard to implement? Yes. Is it impossible? I don't think so. It pretty much requires that toolkits have a fairly abstract view of the UI though. Many toolkits probably aren't abstract enough. It would also be important to be very flexible and extendible. If someone needs a new type of "component", it should be possible to add that to the system, without breaking old UIM's.
If the OS community doesn't care about monetary rewards, is there an other benefit in having your proposed Software Market?
Open source developers need to eat too. Most of us have "day jobs", generally writing proprietary software. Anything that would allow open source developers to actually get paid for developing open source would probably only increase the quality and quantity of open source available.
Than said, I don't see how Prof. Pollack's "Software Markets" idea could work for open source. Releasing your source would allow people to remove the mechanism for doing license checking. That in turn would devalue your software.
In other words, it suffers from basically the same problem as conventional commercial software in this regard: If people can get essentially the same product "gratis", many of them won't pay for it. So not only do you make fewer sales, but the "market price" will drop, meaning there's a good chance you'll never make back your development costs. So there's a fairly strong incentive to not release the source.
I gotta admit, I haven't read the article yet, but plain jane silk certainly isn't the most durable substance on earth.
Read the article. This is a low-K dielectric with the trade name "SILK" (probably an acronym).
But one has to wonder why the article says "silk" and not "SiLK®" or at least "SiLK[tm]". Even after reading the sentence "IBM has developed a proprietary technique to build chips using silk, a low-k dielectric material that is commercially available from the Dow Chemical Co.," I still wasn't positive that they weren't talking about the stuff from silkworms. Nowhere in the article do they actually say the "silk" they're talking about is not what people normally mean when they say "silk". I mean, just because it's "commercially available from the Dow Chemical Co." that doesn't mean it can't come from a worm's butt.
From reading the MS culture article here on slashdot a few weeks ago, the employees at Microsoft appear to be very happy, well paid, and have no major issues with what Microsoft does.
If they had major issues with what MS does, do you think they would have started working there in the first place? I could have gone to work at MS, but I didn't because I do have issues with what they do. (I almost considered getting interviewed with MS, just to see, but talking to Microsoft HR people makes me queasy) I imagine that most MS employees either don't care about ethics, or they're deluding themselves.
I have nothing against software companies. (Hint: I'm not a free software zealot) Anyone with any amount of knowledge of computer science and/or software engineering will tell you that Microsoft produces sub-standard software, and the only reason they get away with it is because of their monopoly, and the fact that they have some fairly shady business practices.
The MS apologists often think that those against MS are against a company being successful, or making a profit. So where's the profit in Microsoft spending millions of dollar on a browser that they give away for free? They're being generous you think? No, they're dumping in order to kill off Netscape, and anyone else that might try to make it big by making a browser.
If MS wants to make a browser, or a ham sandwich, or whatever, that's fine. But they have a monopoly in operating systems, so they shouldn't be allowed to dump these other products, or tie them to the OS. Separate products should have to compete on their own merits.
But besides the time factor, why do people drive, rather than taking public transit? For the thrill of the open road, the feeling of power when you are behind the wheel. Robot drivers take that away!
Well, the time factor is a big thing. And convenience. Let's see, my choices are:
1. take my car to the store, get there in about 10 minutes
2. walk to the bus stop, wait for the bus to show up, hope I've got exact change, find a seat that isn't too disgusting, endure the stares of drooling weirdos, transfer a couple of times all the while seeing parts of town that are way out of my way, and then finally arrive at the closest bus stop, which is a ten minute walk from my destination.
While in University, I didn't have a car, and having a car is immensely more convenient than a bus for far more reasons than "the thrill of the open road".
Actually, I do like driving, sometimes, so I would like the option to drive myself. But there are many times I wish my car could drive itself. Times like:
- I'm tired and I just want to get home - really long trips - I don't know where I am (imagine an automated driver hooked up to GPS and a mapping system) - busy cities. I hate driving in busy cities, especially in downtown areas.
Much what I'm doing...;) If you're good, send your resume to Red Hat. If you aren't, try one of the other distributors...;))
I'd have a couple of issues working for Red Hat, or any other distro.
First, while Red Hat does hire developers, the developers don't contribute to the the product that Red Hat actually sells. Red Hat's product isn't software, it's distribution and support.
This means that Red Hat doesn't need its developers to stay competetive. Imagine that another distribution started to seriously cut into Red Hat's profits, and Red Hat figured that it needed to cut costs. The easiest way to do that is to lose the developers. After all, they don't contribute to the bottom line. In fact, the developers are helping that competing distro just as much as they're helping Red Hat, so it makes little difference to Red Hat who they work for (or if they work at all). If this seems far-fetched, consider the fact that Mandrake has won a few awards, even though it's only a slightly modified Red Hat. Mandrake is standing on Red Hat's shoulders, so to speak, yet they don't contribute to the salaries of Red Hat's developers. Consider also that Red Hat has to compete with non-distro support sellers like Linuxcare (which doesn't hire any open source developers, AFAIK).
The only thing that would stop Red Hat from firing their developers in that situation would be the bad PR. That's only the case because most Linux users have an "open source conscious", so to speak. I wouldn't like having my job only because of PR reasons.
The other issue is the whole conflict of interest thing. Red Hat relies on support for income. If Linux were really easy to set up and use, people wouldn't need to buy Red Hat's product. So it's against Red Hat's interests to make Linux too easy to use, or they won't get any profits.
Now, that's an over simplification. There is some incentive for support-sellers like Red Hat to improve Linux. The easier Linux is to use, the more people will consider using it. Since some percentage of those people will buy Red Hat's distro, that's good for Red Hat. But consider also that the easier Linux is to use, the higher the percentage of Linux users that will decide they don't want to pay for support, since they won't ever use it. That means that at some point there's an equilibrium, and beyond that, the easier Linux becomes, the less profit support sellers like Red Hat make.
Contrast that with proprietary software, which often makes little or no profit from support. Support fees are often there just to deter trivial help requests, and to cover the cost of hiring support personnel. So there isn't a conflict of interests, and there is in fact an incentive to improve the software, as the easier it is to use, the more profits are made from sales.
The root of the problem is that people want to use the software, but they don't want to pay for the work that went into producing it. Instead they want the developers to find an alternative source of funding, all the while hoping they can side-step it. They say, "why not give the razor [software] away for free, and charge for the blades [support]?" The problem is, it's developers' responsibility to make the razor so good that the blades are unnecessary, thereby cutting off (no pun intended) their only potential source of income.
People who used to maintain a package and can't do it anymore...
It would be interesting to find out why this happens. My guess is that it's one of the following:
1. health reasons 2. lack of interest in the project 3. "they don't have the time"
My guess is that for most open source projects that go into an unmaintained state, #3 is by far the most common reason. Of course, this is most likely a euphemism for "I have a job now, and I have to concentrate my efforts on something that actually pays the rent".
Instead of finding alternative maintainers, I think it would be immensely useful if the open source community would try to solve the real problem: how do developers of open source software get paid?
Now, I know a lot of people are going to go into flame mode, but try to think rationally about what I'm saying. If open source developers were actually paid for their work, they would be able to spend more of their time working on open source. They wouldn't need to get day jobs writing closed source proprietary software, but instead become full-time open source developers. And who really deserves to get paid anyways? The guys who created the software in the first place, or the guys who took their software, and put it in a pretty box?
I don't know how this could be implemented though. To be considered open source, developers have to release their code in such a way that others are just as able to make a profit off of it as the developer. What ends up happening is that distributors, who spend little or no effort actually developing code comparitively, end up making all of the income, while the actual software developers make none. Hence, they need to get day jobs, hence less time to work on open source, hence open source projects that are lower quality than they could be, and many projects falling by the wayside.
If open source developers were paid a competetive salary for producing open source software there would not only be "more eyeballs" actively looking at the code, but those people would actually be spending a lot more time working on open source, rather than using up their energy working on closed software.
So is there a way developers can make money of the open source they produce? Every time I've asked people about this they always bring up the old "you can make money off support argument". Sorry, that doen't work. I'm not a tech support guy. I'm a developer, I want to write software. I'd like to write open source software (and I do, when I have the time). I can't afford to do it full-time though. Others mention contract work. Contract work generally produces software that isn't particularly useful as open source because it's often "implement this weird thing that only we would ever find a use for" type of stuff.
Utopia for me would be if I could work on various OSS projects like GIMP, GNOME, sawmill, VIM, and my own projects, and make a decent salary (ie: competetive with closed source developers, not a waiter's salary). Ideally, the system would work in such a way that the more useful my contributions to the community, the more I'd make. This is the real world though, and here the open source community seems to feel that free beer is necessary for free speech...
I want my column to be 40 em wide not 50% browser width or 150 pixels.
You ain't never heard of the BR tag?
That wouldn't work, unless you were using a monospace font. Pre-wrapping non-monospace text is a horrendously bad idea, because you end up with an extremely ragged right margin.
My opinion: don't try to force it to be narrower. If users really find it hard to read the long lines of text, they can resize their browser window.
If you try and force it you'll just tick people off when they have to read text that's all squished against the left side of their browser window like this.
Make the code available to all for no charge. Distribute your changes into the distribution. Make money on the service, the documentation, the support. Hell even car dealerships understand this; make almost nothing on the vehicle and most of the profit comes through the serivice and parts desks. What is so freakin hard to understand?
Well, I'd like to know how those of us who actually develop the software will make a living. As it is, it's the distributors (Red Hat, Info Magic, Cheap Bytes, whatever...) that get money, while the developers get nothing.
I want to write code. I do it for a living. I don't want to have to do tech support, or write manuals. Now how can I do that in the scope of what you propose? Keep in mind that support sellers can provide just as good support whether or not they pay for the development. Which do you think they'll do? (And yes, I am aware that Red Hat pays a small number of developers to develop an extremely small proportion of what goes onto a typical Red Hat CD...)
Consider also that if the code is free, competing distributors will have access to that code the instant you release it, and can include it in their distro. Instead of developers getting paid for the quality of their work, they're paid only if they managed to get hired by the leading distributor/support-seller. Does that make sense?
Incidently, I do like free software. I've contributed to several free software projects, and I've been meaning to release one myself in the future. Saying that all software should be free isn't realistic though, unless you can guarantee that developers will be paid for the work they've done. To do that, you have to charge for the software itself, and sadly, the free software community seems to think that software must be free (like beer) in order to be free (like speech). Because of that, most free software developers have to have "day jobs", which means that a very small proportion of our development efforts actually end up becoming free.
So while the Linux kernel is not a part of GNU as such, I don't think that rms is out of line expecting that Linux and Linux distributions acknowledge the debt they owe to GNU and the FSF. Without FSF tools, Linux never would have progressed beyond the "obscure hobbyists' amusement" stage.
Funny. The fact that the FSF wants acknowledgment of the work they've done, and the fact that the following is posted on their website as part of their argument for free software, seems contradictory:
Those who benefit from the current system where programs are property offer two arguments in support of their claims to own programs: the emotional argument and the economic argument.
The emotional argument goes like this: ``I put my sweat, my heart, my soul into this program. It comes from me, it's mine!''
This argument does not require serious refutation. The feeling of attachment is one that programmers can cultivate when it suits them; it is not inevitable. Consider, for example, how willingly the same programmers usually sign over all rights to a large corporation for a salary; the emotional attachment mysteriously vanishes. By contrast, consider the great artists and artisans of medieval times, who didn't even sign their names to their work. To them, the name of the artist was not important. What mattered was that the work was done--and the purpose it would serve. This view prevailed for hundreds of years.
That's from Why Software Should Be Free, by Richard Stallman, Copyright (C) 1998 Free Software Foundation, Inc. [emphasis mine]
I have no problem with them wanting credit for their work, but then they should remove that argument from their website. Of course, doing that would leave a huge hole in their whole argument for free software, so instead they choose to ignore their own hypocrisy.
Slashdot Mirror
That's a steGANographics file system. A steno filesystem would be more like a secrary with shorthand writing down all of your files.
How appropriate. Today is Secretaries Day.
(in vi that would be something like
Another tool that is reasonably "point and clicky", but is also quite powerful for the expert is AutoCAD. I don't use it myself, but my Dad uses it all the time. AutoCAD has at least two integrated languages (its basic "command language", and the more advanced AutoLISP), so it's very configurable. My Dad, not being a programmer, has never ventured into using AutoLISP. Some other people at his company have written simple scripts to automate tasks that they do frequently. The interesting thing is that the more "advanced" users can help to tweak things and make them better for the less advanced users. Without scripting capbility, that wouldn't be possible.
I think you're completely missing the point here. While scripting arguably makes life easier for power users, it is pretty much useless for novice users. Shells, emacs and vi are nice if you already know what you're doing. Sit a computer newbie down at a login: prompt and give them the task of writing an email to their buddy in Australia, and you'll see (or not) just how necessary scripting is for a good user interface. I'd argue that one of the most basic needs for a good good user interface is for a user to immediately be able to identify the first step they need to take to perform a desired task.
Actually, I think you're missing the point. Experts are users too. For experts, a user interface should probably include scripting. Even newbies eventually get to the point where they would like to automate some tasks. The "Startup folder" idea is an extremely simplified type of automation.
And your assertion that "one of the most basic needs for a good good user interface is for a user to immediately be able to identify the first step they need to take to perform a desired task" doesn't always hold true. Compare Notepad to vi. Notepad meets your criteria. Does it have a better UI though? You'll probably argue that it does, but many will argue that it doesn't. The thing is, the better UI depends on the person. If you edit a text file once every couple of weeks, notepad is probably great. It gets the job done, and you can figure out where stuff is. But if you edit text files all day long every day, vi is probably better. Sure, it's got a steep learning curve, but it's worth it for those that need to edit text a lot.
It really comes down to whether you need a basic "I just need to do this simple job" UI, or an industrial strength UI. You simply can't make a simple UI for certain tasks, because these tasks are inherently complex. An F16 has a more complicated UI than a VW beetle, and for good reason. It does a lot more.
Of course, in the world of software, we're not restricted to static fixed UI's. Some programs are starting to offer both an easy UI and a powerful but complex UI in the same package. VIM is one example. The graphical version of VIM has menus and supports "point-and-click" operation. While in insert mode, it behaves quite a bit like an improved Notepad. But it's still got all of the normal vi features (and then some...). You can make mappings, and write scripts to do common tasks. You can even get it to behave almost identical to the original "plain ol' vi" if you like. The one big problem with VIM for newbies is that it starts up in "normal" mode (aka command mode, or "beep" mode).
Perl loses because people can't write good code? Please.
No, Perl loses because empiraical evidence shows that people don't write maintainable code in Perl. A reasonable explanation for this seems to be that Perl doesn't encourage people to write maintainable code, and instead encourages people to write a million "quick and dirty one-timer scripts", stick 'em together, and hope the mess does something useful.
Perl is good because you can write beautiful, very maintainable code.
You can also write beautiful, very maintainable, x86 assembly code. Neither language encourages you to do it though, so it'll take you a heck of a long time to get anything useful accomplished. At least with assembly code there's an efficiency benefit. Perl's only strength seems to be its ability to let a person write one-liners that not even the author can understand a month later.
Perl is also good because you can write quick and dirty one-timer scripts to do anything.
Really? To do anything? Write a 3D FPS in one line of Perl. No calling out to other programs allowed.
Seriously though, Python lets one write quick one-off's just as easily as Perl. The main difference being that Python one-off's can then be incorporated into real applications without hurting the maintainability.
The best description of this that I've ever heard is that Perl gets out of your way so you can focus on what you're trying to accomplish.
Perl's goofy syntax gets in my way.
Just because languages like Python, C, C++, and Java are pretty structured, it doesn't mean you can't write unmaintainable code.
I never said that you can't make unmaintainable code in Python. Nor did I ever say that you can't make maintainable code in Perl. What I'm saying is that Python code tends to be very maintainable, while Perl code tends to be very unmaintainable.
A likely explanation is that Python encourages good programming style (ie: maintainable code), while Perl actually encourages bad programming style (ie: unmaintainable code). Having used both languages, I believe this to be the case. Have you used both languages?
Note that I never said Python was perfect either. It's got its warts. There are some things I'd really like to be fixed (like the namespaces issue). A lot of people seem to be turned off of Python because of the indentation thing though. That's unfortunate, and immature. You indent your code anyway. Do you worry about indentation gremlins going and un-indenting it during the night? Why do you think that will happen with Python code?
If you don't agree that Perl encourages people to write unmaintainable code, explain why virtually all Perl code is virtually indecipherable. Why do even Perl programmers joke about the "write-only" characteristic of Perl?
For example, say I want to dial-in to the Internet, download slashdot every morning at 4:00, parse out the crap, format it into latex and send it to my other computer and post it into an sql database. This could be done with *nix and perl in about 3 cans of jolt cola. Name one other OS/launage that could do it in that short of time, and have it work well.
Um, how about Unix and Python? And as an added bonus, you'll still be able to understand the script a year later.
Yes, it's possible to write readable Perl code, but virtually all Perl programmers don't write readable code. That's what happens when your language doesn't encourage good style. Since maintainability is the most important feature of any serious programming language, Perl loses.
6) Does it have words in it? Does it need to be parse?
I'm not even sure what the above means because... it doesn't parse. What are you claiming? That Perl doesn't need to be parsed? That other languages don't need to be parsed? Either way, you'd be wrong.
Agreed. Ever try the -z option of GNU tar?
That said, I do remember using PKZip back in my BBS days. There was even an Amiga version called "PKAZip". It was a GUI utility. On the Amiga, lharc, and later "lha" were more popular though. ("arc", "pak", and "zoo" were also popular really early on...)
Today I use the infozip utilities for zip files though. They're available for all of the platforms I use, and they extract directory structures by default. (that was always my big complaint with pkunzip tools...)
I checked crowds.org and its not regestered. crowds.com is owned by some German guy who hasn't put much of anything up. And crowds.net is also regestered.
Tip: use a search engine. I recommend Google. Try searching for "crowds proxy". You should find The Crowds Home Page.
The way things are now you can't lock users into your distribution because anyone can take it, sell it, and support it without paying you a cent. This means that Linux companies have to rely on things like their ability to SUPPORT their products. Poor guys...it's a tough world.
You're over-trivializing the difficulty of selling GPLed code. With GPLed code all you really can sell is support and distribution. Trying to do development is a waste of time, because all of the other distros can benefit from your development work just as much as you can. You can't come out ahead by expending resources on development, so why waste them? It's a lot more profitable to do no development at all, and just incorporate whatever updates are produced by outside developers.
The playing field is leveled only in the sense that technical superiority no longer exists, because anyone else can copy your work. Perhaps one day we'll "level the playing field" in support to, where one company can charge customers for support calls to another companies tech support lines.
Now, in Caldera's case, I think it is kind of silly for them to complain. They're getting Linux for free, and they can make money off of support. They just shouldn't bother doing any development, because you can't make money off of open source development.
But what about developers? Being a developer, I know I don't like it when people tell me "make your money off of support". I'm a developver, not a support rep. Will developers ever get paid for their open source work? There's no reason for the distros to pay developers, other than PR purposes. (and even then, they only pay for a measly percentage of the development that goes into a typical distro)
As it is, open source is mostly written by people in their spare time. If you want more software to become open source, somebody had better come up with some sort of business model where the developers of this software can actually get paid for writing it. Yes, you can argue that open source developers don't do it for the money. I know, I've worked on open source projects. But developers are mere mortals -- we need to eat, and pay the rent just like everyone else. I simply can't do open source development full time, because I wouldn't be able to pay the rent.
There'd be a hell of a lot more open source software, and the general quality would be much higher, if developers could work on it full time. Right now, most can't. For those of use who don't like being an "expense" (like developers who work for distros), or writing custom hacks for a living, the only route right now is to write non-open code for a living.
And here's a hint for those of you thinking that developers could survive off of donations: why should people who do useful and valuable work have to live off of charity?
Contact was OK, not nearly as good as the book of course, but not too butchered for a Hollywood film. Same with Sphere. Apart from that I can't think of any really. As an aside have you seen Cube? Now there is a truly intersting film.
I agree that Contact was okay. I was actully quite impressed with how little they mucked up the story. (It still was quite different from the book, but I think it got most of the important points across)
But Sphere? It's weird, the first time I read the book, I didn't like it. I tought the ending was... sucky, for lack of a better word. Years later (a couple of months before the movie was released), I decided to read it again, and then I realized that there are two interpretations of the ending - one sucky, one not. In fact, the alterntive interpretation was pretty cool, but harder to recognize. The movie's ending was very definitely based on the sucky interpretation of the ending, rather than the cool one. Too bad.
I was surprised, almost 90% of 500-600 people who showed up to an ESR talk responded that they did not get paid to develop commercial closed software products. Most of those people write internal code for companies.
Since when is internal code "non proprietary"? And in any case, the kind of code that people write for internal use is generally not useful as open source because it's highly speciallized. Quite a lot of it entails putting together tools made by others, and adding glue code. In other words, custom hacks.
Who pays for the development of that non-specialized "in-between-the-glue" code? I don't want to be writing custom hacks for a living. I want to write well designed, general software that people at more than one company can actually use.
How many of these people (the 90% you mentioned) were "software developers", and how many were sysadmins? I don't want to sound elitist, but I really don't think someone who works as a sysadmin all day would make a good software developer, in general.
Good software developers learn to always think about the boundary conditions, and to solve the generalized problem. Sysadmins tend to think in terms of "how do I fix this one particular problem on this one machine I'm running into today?"
[If it's true that 90% of open source developers are sysadmins, that might explain some of the truly crufty code I've been looking at in the GIMP...]
Only you >10% of programmers are in danger of losing your jobs (and you guys could salvage it if you'd get sponsorship)
Please clarify what you mean by "you guys could salvage it if you'd get sponsorship".
but you get all the press, you guys take up most of the advertising space, and hence think that you're the most important/most populous portion of the industry.
Sounds like the open source zealtots on Slashdot, actually. I'd guess that less that 1% of Slashdotters are open source zealots, but they make 99% of the noise (once you remove the blatant trolls).
I'd wager that 90% of the software that 90% of people use was written by that "10%".
If I have a copy of a piece of GPL software, I can personally do whatever I want with it. I can even sell it, if I can find buyers (ask Red Hat!).
That's a very big if. Who would buy your software, if they know that once it's released anyone, including their competiotrs could use and redistribute it. Notice that RedHat doesn't buy the software on their CD's. They get it for free. GPL software is, for all practical purposes, "free beer". People won't pay for the beer, if they can get exactly the same beer for free. (well, maybe they would if they've had too much beer to start with...)
I was disturbed at his belittling of the success of the Free Software movement. I don't think that I agree that people that release their work to the community through the GPL get nothing in return as he claims. He attempts to dismiss what they get as being purely egoboo/recognition, but that sort of recognition translates into employability! It seems as though he doesn't appreciate this.
Employability doing what? Oh wait, I know the answer: writing closed source software.
One of the problems with most open source zealtots is that they don't seem to realize that the closed source software economy is what pays the salaries of the vast majority of open source software developers (like myself).
I would be happy to see a system that was a "happy medium", where source code was available so people could fix bugs, and developers would get paid for the work they do. That system doesn't seem to exist in the real world (though Asynchrony seems to be pretty close). Such a system cannot exist if people expect to be able to get software completely "gratis" though. Somewhere along the line, someone has to pay for the development costs.
This "right" of _possession_ is enforced by the military over the right of life, liberty and happiness. That's what's happening in Chiapas now and in many other places around the world where ordinary, decent, intelligent, hardworking humans are beaten, murdered and raped to keep them producing cheap raw goods for export so that our ordinary decent people will work for less so that the uncivilized and barbarous "middle class" can pontificate about perfect free-markets.
I have to laugh every time I see someone bring up people in third world counries who are "beaten, murdered and raped", as if somehow the abolotion of IP laws will make any difference to those people. Yes, there are serious human rights and poverty problems in the world. Bringing it up in a discussion of open source software is about as relevant as saying "do it for the children" though.
Here's what I'd like: a system where everyone's basic survival needs are met, and beyond that, people are rewarded proportionately to their contribution to society. Does open source help bring us closer to such a world? Nope. The "free market" with IP laws (and enough social programs to give people basic survival needs) is a lot closer than a world with no IP.
You are right. Not everyone agrees with me. Ok Allow me to rephrase. According to my definition of "Property", information (ie intellectual works) do not qualify as property. I recognize that others do see them as property and try to respect their worldview, however, I do not and will not share that world view, and will only allow my actions to be dictated by that world view as I deem apropriate.
Allow me to paraphrase:
"According to my definition of 'Property', anything I can get my hands on does not qualify as other people's property. I recognize that others do see them as property and try to respect their worldview, however, I do not and will not share that world view, and will only allow my actions to be dictated by that world view as I deem apropriate."
The ability to produce New Good Music is scarce. Once it is produced, there is no scarcity. I have no problem with hireing musicans to play music, or going to concerts etc etc. Certainly they are talented and should recieve compensation for their talents.
Yes, and how's that going to happen? Noone will pay for it if even people who don't pay benefit equally.
Yes, money is a big motivator. However it is not the only big motivator. Most people are not solely motivated by money.
Money is the most practical way to get food, clothing, and shelter.
You are assuming that there are rights to lose. What you are asking for is not rights to a piece of property but the right to dictate the actions of others. If Alice writes a poem and gives Bob a copy, Then Bob gives a copy to Carol, then how dows the Bob/carol transaction effect Alice? For alice to claim the right to stop the transaction, she is claiming the right to influence transactions between other people, that do not involve her.
The transaction affects Alice because the value of what she has produced has decreased. Ever hear of supply and demand? If there's an infinite supply, the price drops to zero. That would be fine if Alice spent $0 and zero time writing that poem. But if Alice spent the better part of a year writing that poem how can she survive if she can't get paid for it? In an ideal world, the "cost" of producing the poem in the first place would be divided among the people who benefited from it, proportionately to how much they benefited from it. Right now, the free market with IP laws are the best approximation of that we've got.
Consider software development. Thousands of man hours (of highly skilled people) go into producing your typical piece of software. Yes, there is 0 replication cost, but what about that up-front cost? Who pays for all of those developers, and the equipment that they need? I know you're going to bring up open source, but how many developers do you know who actually make money writing open source? Almost all open source developers have a day job writing closed-source software (myself included).
Does this make publishing music less profitable? Yes it does, it means CD pressers would actually have to compete with eachother. It would mean anyone who can press a CD is their competition.
Yes, it also means that content creators get zip.
Does it mean artists wont be able to make money? Hell no. They can still perform.
Explain how people who create digital media like electronica musicians, computer animators, and software developers can make money from "performances". I can already tell that for software developers you're going to say "sell support". Hint: developers don't do support. Support sellers don't need developers, and so they won't hire them.
There will always be a market for live performance. If that doesn't pay well enough, then they will either need to change how performing works (charging more, giving artists a greater cut) or...shudder...get day jobs
Oh yes, get day jobs. because those damn musicians, artists, and software developers don't provide any real value to society. If they want to create, they can do it on their own time. If they want to eat, they can go scrub some floors or something. It's just too bad that the quality of work produced will go down so much, since none of the content creators would be able to afford to do it full time... darn.
BTW, I really liked the way you totally avoided Kaa's point about contracts there.
I believe people should be rewarded for the amount of value they contribute to society. Captalism and IP laws aren't perfect, but they give a reasonable approximation of this. I'm completely open to better approximations, but I've yet to see a proposal for one that seems feasible. Your beliefs almost completely remove the ability for creators of information to be rewarded for the value they contribute to society. The only motive I can see behind your beliefs is greed: you want to be able to get content gratis (for free, as in beer). You don't seem to care if someone spent months or years working on something. I guess you just figure they're a sucker who made something you can use for free.
So what do you do for a living?
Ummm, so wouldn't using the themable widgets AND creating a 'crappy Microsoft UI theme' let you have it both ways without code-evil?
Nope. maybe you should go back and read the article, right where it said:
"Oh, sure, somebody will labor mightily to produce a skin that looks just like each native OS, and he or she might even come close to pulling it off. But close doesn't mean much in a world where subtlety and nuance actually matter. Common, native controls exist for a reason, and that reason is not to serve as a model for crude simulations."
Swing, the new UI package that ships with Java <blink>1.</blink>2 (and is also avaialable for 1.1), uses "lightweight" components for almost everything. It comes with a Windows 95-esque "look and feel", but it isn't the real thing. It doesn't feel like the real thing, and it doesn't quite look like the real thing. And if you mess around with your desktop settings, or upgrade to a version of Windows where the components look different, the emulation fails miserably.
That said, I would have nothing against a desktop that was "themeable". The main requirement is that the "themes" should affect everything. Why should my MP3 player look any different from my chat client? Sure, if I want different apps to use different themes, that could be an option. But my point is, the theming/skin system should not be in individual applications. It should be in the UI system itself, so the user can easily have a consistent look and feel to their environment.
GNOME and KDE are making some progress towards that goal. Unfortunatley, GNOME at least (I haven't tried KDE yet) still makes a distinction between "toolkit" themes and "window manager" themes. This is insanely dumb.
Of course, X's problem is that every frigging application uses a different toolkit, so all the widgets look different. And my window borders are rendered by yet another program. My desktop ends up looking like a garage sale, unless I'm very selective about which programs I run. Oh joy!
The UI of your typical X application is rendered by two things: the toolkit that the app uses, and the window manager. The toolkit applies its own look-and-feel, and the wm applies another to the border.
If users chose toolkits, they'd probably pick the one that was easiest to use, or most aethetically pleasing. Users don't choose the toolkits though, developers do. So the toolkit is often chosen because it's easy to program with (eg: KDE), available in the Developer's programming language (eg: Tk), fits with the developer's politics (eg: GTK+), or is some sort of "corporate standard" where the developer works (eg: Motif). None of these reasons matter to the user, yet the user is the one that's ultimately affected. Even if the Develper does try to select a toolkit based on usability (one or two of us actually care about things like that...), the developer's sense of aethetics and usability might not be the same as all of the application's eventual users.
So how do we fix that? In an ideal world, applications would merely provide functionality, with a UI that was specified in terms of what they want to say to the user, and what they need to know from the user. A user abstraction layer (UAL), so to speak. The system would have a UI Manager (UIM) that would act something like a super-window manager. It would handle all of the things that today's window managers handle, but it would also handle the look and feel of window contents as well. The interface between the UAL and the UIM would be standardized, so that users could install a different UIM if they wanted to, and all of their existing apps would benefit from it. The UAL would also be standardized, so that numerous toolkits could exist for it. Developers could then choose any of these toolkits, based on what matters to them. Users could choose whatever UIM they wanted, and configure it however they please, knowing that their customizations will affect all of their applications.
So is that hard to implement? Yes. Is it impossible? I don't think so. It pretty much requires that toolkits have a fairly abstract view of the UI though. Many toolkits probably aren't abstract enough. It would also be important to be very flexible and extendible. If someone needs a new type of "component", it should be possible to add that to the system, without breaking old UIM's.
If the OS community doesn't care about monetary rewards, is there an other benefit in having your proposed Software Market?
Open source developers need to eat too. Most of us have "day jobs", generally writing proprietary software. Anything that would allow open source developers to actually get paid for developing open source would probably only increase the quality and quantity of open source available.
Than said, I don't see how Prof. Pollack's "Software Markets" idea could work for open source. Releasing your source would allow people to remove the mechanism for doing license checking. That in turn would devalue your software.
In other words, it suffers from basically the same problem as conventional commercial software in this regard: If people can get essentially the same product "gratis", many of them won't pay for it. So not only do you make fewer sales, but the "market price" will drop, meaning there's a good chance you'll never make back your development costs. So there's a fairly strong incentive to not release the source.
But one has to wonder why the article says "silk" and not "SiLK®" or at least "SiLK[tm]". Even after reading the sentence "IBM has developed a proprietary technique to build chips using silk, a low-k dielectric material that is commercially available from the Dow Chemical Co.," I still wasn't positive that they weren't talking about the stuff from silkworms. Nowhere in the article do they actually say the "silk" they're talking about is not what people normally mean when they say "silk". I mean, just because it's "commercially available from the Dow Chemical Co." that doesn't mean it can't come from a worm's butt.
That said, you're right that they don't mean stuff from a worm's butt. You can't conclusively determine that just from reading the article though, so nyah.
From reading the MS culture article here on slashdot a few weeks ago, the employees at Microsoft appear to be very happy, well paid, and have no major issues with what Microsoft does.
If they had major issues with what MS does, do you think they would have started working there in the first place? I could have gone to work at MS, but I didn't because I do have issues with what they do. (I almost considered getting interviewed with MS, just to see, but talking to Microsoft HR people makes me queasy) I imagine that most MS employees either don't care about ethics, or they're deluding themselves.
I have nothing against software companies. (Hint: I'm not a free software zealot) Anyone with any amount of knowledge of computer science and/or software engineering will tell you that Microsoft produces sub-standard software, and the only reason they get away with it is because of their monopoly, and the fact that they have some fairly shady business practices.
The MS apologists often think that those against MS are against a company being successful, or making a profit. So where's the profit in Microsoft spending millions of dollar on a browser that they give away for free? They're being generous you think? No, they're dumping in order to kill off Netscape, and anyone else that might try to make it big by making a browser.
If MS wants to make a browser, or a ham sandwich, or whatever, that's fine. But they have a monopoly in operating systems, so they shouldn't be allowed to dump these other products, or tie them to the OS. Separate products should have to compete on their own merits.
But besides the time factor, why do people drive, rather than taking public transit? For the thrill of the open road, the feeling of power when you are behind the wheel. Robot drivers take that away!
Well, the time factor is a big thing. And convenience. Let's see, my choices are:
1. take my car to the store, get there in about 10 minutes
2. walk to the bus stop, wait for the bus to show up, hope I've got exact change, find a seat that isn't too disgusting, endure the stares of drooling weirdos, transfer a couple of times all the while seeing parts of town that are way out of my way, and then finally arrive at the closest bus stop, which is a ten minute walk from my destination.
While in University, I didn't have a car, and having a car is immensely more convenient than a bus for far more reasons than "the thrill of the open road".
Actually, I do like driving, sometimes, so I would like the option to drive myself. But there are many times I wish my car could drive itself. Times like:
- I'm tired and I just want to get home
- really long trips
- I don't know where I am (imagine an automated driver hooked up to GPS and a mapping system)
- busy cities. I hate driving in busy cities, especially in downtown areas.
Uh... not a bad idea, but not a complete solution I think. Income tax write-offs aren't very useful if you don't have any income to start with.
Much what I'm doing...
If you're good, send your resume to Red Hat.
If you aren't, try one of the other distributors...
I'd have a couple of issues working for Red Hat, or any other distro.
First, while Red Hat does hire developers, the developers don't contribute to the the product that Red Hat actually sells. Red Hat's product isn't software, it's distribution and support.
This means that Red Hat doesn't need its developers to stay competetive. Imagine that another distribution started to seriously cut into Red Hat's profits, and Red Hat figured that it needed to cut costs. The easiest way to do that is to lose the developers. After all, they don't contribute to the bottom line. In fact, the developers are helping that competing distro just as much as they're helping Red Hat, so it makes little difference to Red Hat who they work for (or if they work at all). If this seems far-fetched, consider the fact that Mandrake has won a few awards, even though it's only a slightly modified Red Hat. Mandrake is standing on Red Hat's shoulders, so to speak, yet they don't contribute to the salaries of Red Hat's developers. Consider also that Red Hat has to compete with non-distro support sellers like Linuxcare (which doesn't hire any open source developers, AFAIK).
The only thing that would stop Red Hat from firing their developers in that situation would be the bad PR. That's only the case because most Linux users have an "open source conscious", so to speak. I wouldn't like having my job only because of PR reasons.
The other issue is the whole conflict of interest thing. Red Hat relies on support for income. If Linux were really easy to set up and use, people wouldn't need to buy Red Hat's product. So it's against Red Hat's interests to make Linux too easy to use, or they won't get any profits.
Now, that's an over simplification. There is some incentive for support-sellers like Red Hat to improve Linux. The easier Linux is to use, the more people will consider using it. Since some percentage of those people will buy Red Hat's distro, that's good for Red Hat. But consider also that the easier Linux is to use, the higher the percentage of Linux users that will decide they don't want to pay for support, since they won't ever use it. That means that at some point there's an equilibrium, and beyond that, the easier Linux becomes, the less profit support sellers like Red Hat make.
Contrast that with proprietary software, which often makes little or no profit from support. Support fees are often there just to deter trivial help requests, and to cover the cost of hiring support personnel. So there isn't a conflict of interests, and there is in fact an incentive to improve the software, as the easier it is to use, the more profits are made from sales.
The root of the problem is that people want to use the software, but they don't want to pay for the work that went into producing it. Instead they want the developers to find an alternative source of funding, all the while hoping they can side-step it. They say, "why not give the razor [software] away for free, and charge for the blades [support]?" The problem is, it's developers' responsibility to make the razor so good that the blades are unnecessary, thereby cutting off (no pun intended) their only potential source of income.
People who used to maintain a package and can't do it anymore...
It would be interesting to find out why this happens. My guess is that it's one of the following:
1. health reasons
2. lack of interest in the project
3. "they don't have the time"
My guess is that for most open source projects that go into an unmaintained state, #3 is by far the most common reason. Of course, this is most likely a euphemism for "I have a job now, and I have to concentrate my efforts on something that actually pays the rent".
Instead of finding alternative maintainers, I think it would be immensely useful if the open source community would try to solve the real problem: how do developers of open source software get paid?
Now, I know a lot of people are going to go into flame mode, but try to think rationally about what I'm saying. If open source developers were actually paid for their work, they would be able to spend more of their time working on open source. They wouldn't need to get day jobs writing closed source proprietary software, but instead become full-time open source developers. And who really deserves to get paid anyways? The guys who created the software in the first place, or the guys who took their software, and put it in a pretty box?
I don't know how this could be implemented though. To be considered open source, developers have to release their code in such a way that others are just as able to make a profit off of it as the developer. What ends up happening is that distributors, who spend little or no effort actually developing code comparitively, end up making all of the income, while the actual software developers make none. Hence, they need to get day jobs, hence less time to work on open source, hence open source projects that are lower quality than they could be, and many projects falling by the wayside.
If open source developers were paid a competetive salary for producing open source software there would not only be "more eyeballs" actively looking at the code, but those people would actually be spending a lot more time working on open source, rather than using up their energy working on closed software.
So is there a way developers can make money of the open source they produce? Every time I've asked people about this they always bring up the old "you can make money off support argument". Sorry, that doen't work. I'm not a tech support guy. I'm a developer, I want to write software. I'd like to write open source software (and I do, when I have the time). I can't afford to do it full-time though. Others mention contract work. Contract work generally produces software that isn't particularly useful as open source because it's often "implement this weird thing that only we would ever find a use for" type of stuff.
Utopia for me would be if I could work on various OSS projects like GIMP, GNOME, sawmill, VIM, and my own projects, and make a decent salary (ie: competetive with closed source developers, not a waiter's salary). Ideally, the system would work in such a way that the more useful my contributions to the community, the more I'd make. This is the real world though, and here the open source community seems to feel that free beer is necessary for free speech...
You ain't never heard of the BR tag?
That wouldn't work, unless you were using a monospace font. Pre-wrapping non-monospace text is a horrendously bad idea, because you end up with an extremely ragged right margin.
My opinion: don't try to force it to be narrower. If users really find it hard to read the long lines of text, they can resize their browser window.
If you
try and
force it
you'll
just tick
people
off when
they have
to read
text
that's
all
squished
against
the left
side of
their
browser
window
like this.
Seems to me a good test of Stallman's ideas would be to see a company like RedHat turn a profit.
I think it would be even better if a significant proportion of the people who wrote the code in the typical Linux distribution would turn a profit.
Well, I'd like to know how those of us who actually develop the software will make a living. As it is, it's the distributors (Red Hat, Info Magic, Cheap Bytes, whatever...) that get money, while the developers get nothing.
I want to write code. I do it for a living. I don't want to have to do tech support, or write manuals. Now how can I do that in the scope of what you propose? Keep in mind that support sellers can provide just as good support
whether or not they pay for the development. Which do you think they'll do? (And yes, I am aware that Red Hat pays a small number of developers to develop an extremely small proportion of what goes onto a typical Red Hat CD...)
Consider also that if the code is free, competing distributors will have access to that code the instant you release it, and can include it in their distro. Instead of developers getting paid for the quality of their work, they're paid only if they managed to get hired by the leading distributor/support-seller. Does that make sense?
Incidently, I do like free software. I've contributed to several free software projects, and I've been meaning to release one myself in the future. Saying that all software should be free isn't realistic though, unless you can guarantee that developers will be paid for the work they've done. To do that, you have to charge for the software itself, and sadly, the free software community seems to think that software must be free (like beer) in order to be free (like speech). Because of that, most free software developers have to have "day jobs", which means that a very small proportion of our development efforts actually end up becoming free.
Funny. The fact that the FSF wants acknowledgment of the work they've done, and the fact that the following is posted on their website as part of their argument for free software, seems contradictory:
That's from Why Software Should Be Free, by Richard Stallman, Copyright (C) 1998 Free Software Foundation, Inc. [emphasis mine]
I have no problem with them wanting credit for their work, but then they should remove that argument from their website. Of course, doing that would leave a huge hole in their whole argument for free software, so instead they choose to ignore their own hypocrisy.