They produce the toolkit as an incidential when developing something else, and want the chance to get feedback and patches to it. This is much of the same reasoning as many open source developers (people) use.
They want the internal morale boost among employees that many people get from going open source.
I agree: I've been burned by incorrect documentation, and it utterly sucks. I've also abandoned Linux, partially due to sucky documentation - instead, I use FreeBSD (disclosure: and I'm a FreeBSD developer).
And my experience with open source vs commercial is that it's usually cheaper to set up something commercial, at least as long as things go without problems - yet it's hell to debug, so if there's trouble, I'd much rather be on an open source solution. I tend to say it as "open source costs a trifle more for everyday things, and that's insurance against things suddenly going horribly wrong".
With what I do, it's usually cheaper to spend a little more at predictable times instead of taking the risk of suddenly spending lots of time when things have gone wrong and something's not working. I don't know if that's true in your situation or not.
I agree that startup cost is an extremely important point for sales, and that open source projects often suck at it. I believe it's also important inside open source - for instance, I believe a large part of mysql's success compared to PostgreSQL is startup cost.
As for "RTFM, idiot" - I hear people tell of this reaction all the time, yet I've never seen it. Maybe it's to do with what projects I choose to deal with - I use FreeBSD instead of Linux, and do work with PostgreSQL/Perl/Ruby (and, due to costs of migrating away from it, MySQL), and I've never seen that reaction in those communities. I've seen the reaction "man XYZ" or similar (pointing at the appropriate documentation) regularly, but that's generally of help to the person being told what to read. And if the person has a problem understanding the documentation, we try to help and update the documentation as appropriate.
Interesting, I've never had need to talk to a MS-SQL or any database developer to use any of the database products I've used. I've worked on some pretty complex databases and queries as well.
It's mostly a matter of convenience - the developers give better support, and the network of people around it give superb support. I suspect you have been trying to work with open source without knowing how to exploit the network around it.
As for increasing complexity (losing design) and lacking finish, that depends on the project, but yes, it is typical. In one way, it's a strength - open source tends to gravitate towards simple solutions that can be robust because those that try to push finish on it just don't have time. In others, it's a great weakness.
I am used to working with open source and I'm fairly used to working with proprietary software. I find it much, much harder to work with e.g. MS-SQL than either PostgreSQL or MySQL, as the resources around it is missing. MS-SQL has a ton of tutorials and screenshots and stuff for the proprietary stuff, but there's no working support community (I can't go on IRC and talk to a developer), the configuration systems are long and complex (probably because the developers do not use them to configure things and do not do support), and the use of graphical interfaces make the tutorials long and clumsy ("Now press "OK" in the dialog that had a screenshot just taking up half the page" is noticably more icky than "").
To add insult to injury, when the stuff is in trouble, I cannot go to the source code and find out what's up or fix that stupid error message that says "Cannot open file" but nothing about WHICH freakin' file.
In sum: I find open source much, much easier to support. When there's a problem, I can talk to other people that have had the same problem *and have had the resources to fix it*, unlike e.g. Microsoft support. (Microsoft support have actually called me to find out how to fix a problem in a Microsoft product - a problem that should have been trivial for them to debug if they had code access.)
It is basically not possible to provide the full experience without controlling both hardware and software. There are too many possible interactions.
My background (authority) for this claim: I've been an OS developer (FreeBSD and briefly OpenBSD), I've done various forms of embedded systems work (from minature through games to providing systems based off FreeBSD), and I've tracked operating systems integration for about 20 years.
What's really needed, of course, is a new way of writing and maintaining software. The programs we use today are essentially bespoke, hand-built items, much the way cars were at the start of the 20th century. The primitive fabrication methods are masked because computer software can be duplicated infinitely without additional cost, but it's still an industry ripe for a new enry Ford to invent the digital equivalent of a production line.
You are missing something: Programs are DESIGNS. This is an important point. This is a VERY important point.
Programming is like the DESIGN of the T-Ford, which was never automated. The PRODUCTION of programs has already been automated - it's the compilation and duplication I get when I do "make && make install".
Delivering all mail to the inbox has a real risk: Human classification error, which AFAIR tend to run at about 0.1%. This is higher than some automated systems.
Sorry, I meant end user community. And in my experience, it grows at roughly the same rate, as long as support is reasonably distributed. The challenge is not in the number of people available - for any particular level of support, this tend to be enough - it's on the level of internal communication in the top tier of support/developers.
A large number of uninformed users rapidly start giving *some* support to others, and the short path upwards makes this work fairly well. The problem with the commercial companies is that their developers are NOT available to give support.
Heck, I know a numbers of the developers at Apple, and when they were doing FreeBSD, we'd be exchanging support - in the public mailing lists and in the form of code, making it all available for everybody. Now that's gone, and the feedback loop with it.
At Microsoft, the high end support people don't even have access to developers or code. I had one case where one of my consulting customers had a problem with an Exchange server on a clustered system. They were a large, priority Microsoft support customer (with a very expensive support contract), and my customer had lodged about a ticket a month earlier, and now things were coming to a push, so they'd had two people trying to solve the case locally for three days. No go. Then a Unix person there (me, actually, but that's besides the point) was pulled in, went through the docs, found an analogous problem with a solution for MS-SQL, they tested the solution, and voila - it worked! It was a fairly trivial registry tweak that would have been obvious from looking at the source (direct string compare on an id that wasn't the same for RAID disks).
Anyway, the ticket with Microsoft support was closed. An hour or two later, MS support called back. They wanted to know what my customer had done to resolve the problem - since MS support had three other priority support tickets against the same problem, and hadn't been able to find a solution.
This is what happens when support doesn't have access to and competence in the source code. Open source OS projects give better support and are more responsive because we have that access, and because we get into the habit that if a customer is willing to give us info on a reproducable, we will solve the problem. We almost never have any insurmountable barrier that stop us from doing so.
I'm sorry, but I believe you're taking a very minor parameter and attributing everything to it. In open source, the support community grows at roughly the same rate as the developer community, and there's completely different mechanisms at work.
The reasons for faster response, from my point of view (having had a commit bit for FreeBSD for almost a decade now):
The developers actually do support. They're in contact with the end users. And some of the end users are other coders, and are allowed to do things with the OS code. This allows them to send in suggestions for how to fix their own problem. As opposed to the rumours, we only use these as is less than half the time - yet they're useful for pointing out things.
The developers are allowed to prioritize their own time. This result in both higher quality code (developers clean up when they feel cleanup is warranted), and easy end user problems being prioritized. Especially in combination with developers doing support.
Open source software is mostly designed based on what's technically reasonably easy, not marketing. This makes for simpler and more nimble codebases.
Open source goes through evolution: Those codebases that aren't nimble mostly die. In closed source software, those codebases that sell can add more resources (programmers) to get around not being nimble.
I think these things are much more important. Especially the first two.
I'm a copyright holder, and I've made maybe half my income over my worktime from copyright. Copyright infringment is not theft - it is copyright infringment. There are really significant differences, and anybody that equate the two will be unable to think properly about copyright infringment.
I would guess downloads / day over the last, say, 3 months should contribute much to the ranking.
It is possible downloads/release over the last year should contribute quite a bit (to cover the projects that's mostly interesting around release time).
OSS projects are not working anywhere near to perfect. They are working somewhat adequately, yet they're very far from perfect. SF.net is even less perfect - when you say [sourceforge] "... easily provides all the services that any OSS project of any size needs in order to function and flourish" - why do most of the large OSS projects (Free/Net/Open/DragonflyBSD, KDE, Gnome, X11, Debian, Gentoo,...) use separate infrastructure? I can only speak for FreeBSD: We do so because Sourceforge services isn't enough, and we get more done by taking the overhead of running our own.
On to problem areas for open source in general:
Problem report to patched, committed source with commit comment. The path is LONG - even if you have a checked out tree, you'll need to save the patch, switch windows, cd to an appropriate directory, run a patch command, run a commit command, and write a commit message.
Ability to integrate automated testing on commit. This is possible, yet it's an utter pain in most version control systems. (Aegis gets it mostly right, of course, as this was the original reason for Aegis).
Project search is difficult, even including SF.net and Freshmeat and Freshports and pkgsrc and Debian package metadata and CPAN and...
The problem report/issue tracking systems I know of are icky to use for large projects. (They're icky for small, too, but there the ickyness doesn't matter much)
There is no way to mark up code with discussions a la a Wiki.
There's no easy way to mark up code for high quality UML output, so people can get into projects quickly
Every project end up setting up their own infrastructure for archiving chat logs
Mailing list archive search is icky, and this is necessary to find why what happened. (This may, unfortunately, always end up being icky.)
There's no (perceived as) reliable, scalable version control system that handle distributed branching/development.
I can write up points for hours - and have. Unfortunately, my last try at dealing with many of these issues (http://www.rubyarchive.org, presently so defunct that the Wiki has been spammed almost out of existence) ended up being sabotaged, and I'm sort of demotivated towards doing any more tries...
This seems reasonable at first glance, yet it indicates a misunderstanding of how projects work. Projects have momentum and culture. It actually often is a better idea to build things from scratch - adding resources to a project far from always improves it.
In "The mythical man month", Fred Brooks simplified it as "Adding manpower to a late software project makes it later."
AFAIK, filesystems caches at the OS level wasn't common in consumer operating systems until the 1990s. I was kind enough to give you the latest date that you should have picked it up - if I was to point at the first examples I can think of, I'd say 1960s. Apart from that, the app would start faster, which is what most of the comments about IE preloading in general has been about, and which I assumed was what you were talking about. Your shouting of WINDOWS DOES NOT PRELOAD IE PERIOD is what I was responding to - to use your own form of capitalization, it was WRONG AND MISINFORMING PERIOD. (I think shouting less would work better, BTW:)
Windows will end up preloading (to cache) important parts of IE in many cases. This decrease load time. COW page sharing could also decrease the amount of memory spent by IE, though I suspect relocation will make page sharing minimal (and I'm not even sure if Windows implement COW).
Because it's not fair. And those countries don't have as much entirely justifiable litigation either. Since litigation is simply dispute resolution, this means that they have a lot of unresolved disputes. That's not desirable.
No, we do not have "More unresolved disputes". Our legal systems mostly avoid the disputes occuring in the first place. There are a number of different ways different systems handle this, yet as far as I can tell, the end result is that the US is one of countries in the world with the highest number of actual disputes.
Now, please go learn about the 1990s technique of "filesystem caching". This means that the DLLs can effectively bepreloaded even if they are loaded by another process in another memory space. All that's needed is a memory copy from the cache and a relocation, which is much cheaper than a load from disk.
The jury does not "Have to apply the law". The jury can judge the law, too, as in jury nullification. Some (including me) would say the jury is even supposed to judge the law, and that's one of the most important of its functions.
The economics of your proposition seems quite unlikely. (As in: Corporations will use proprietary codebases they have to pay for instead of using GPLed codebases.)
That wasn't the point at all. The point is that Apple has been saying what great OSS supporters they are, and now they are even discontinuing the tiny bit of code sharing they have done.
(A) OpenDarwin wasn't run by Apple.
(B) Apple is sharing code both by distributing it directly and (occasionally) by having Mac OS engineers commit it directly into the FreeBSD tree. The latter means that people from Apple are doing all the adaption work to actually make the code directly usable by the upstream.
While I wish there was even more of (B), I blame the low level on inadequate tools - the version control systems in use make this a pain to do. That's also the reason for much of the divergence of Free/Net/OpenBSD.
The GPL is not a requirement for something being classed as free software; there's numerous other licenses. I personally work with the BSD class of licenses mostly because I see GPL as unfree.
I guess we should just say please and thank you instead to get the info we need?
I guess you should go read some books on interrogation before having an opinion. I can recommend David Lieberman's "Never be lied to again" as a start . It is easy to read and will also be useful in your day to day life.
Slashdot Mirror
Developer time is expensive, download bandwidth is fairly cheap.
Eivind.
Eivind.
And my experience with open source vs commercial is that it's usually cheaper to set up something commercial, at least as long as things go without problems - yet it's hell to debug, so if there's trouble, I'd much rather be on an open source solution. I tend to say it as "open source costs a trifle more for everyday things, and that's insurance against things suddenly going horribly wrong".
With what I do, it's usually cheaper to spend a little more at predictable times instead of taking the risk of suddenly spending lots of time when things have gone wrong and something's not working. I don't know if that's true in your situation or not.
Eivind.
As for "RTFM, idiot" - I hear people tell of this reaction all the time, yet I've never seen it. Maybe it's to do with what projects I choose to deal with - I use FreeBSD instead of Linux, and do work with PostgreSQL/Perl/Ruby (and, due to costs of migrating away from it, MySQL), and I've never seen that reaction in those communities. I've seen the reaction "man XYZ" or similar (pointing at the appropriate documentation) regularly, but that's generally of help to the person being told what to read. And if the person has a problem understanding the documentation, we try to help and update the documentation as appropriate.
Eivind.
As for increasing complexity (losing design) and lacking finish, that depends on the project, but yes, it is typical. In one way, it's a strength - open source tends to gravitate towards simple solutions that can be robust because those that try to push finish on it just don't have time. In others, it's a great weakness.
Eivind.
To add insult to injury, when the stuff is in trouble, I cannot go to the source code and find out what's up or fix that stupid error message that says "Cannot open file" but nothing about WHICH freakin' file.
In sum: I find open source much, much easier to support. When there's a problem, I can talk to other people that have had the same problem *and have had the resources to fix it*, unlike e.g. Microsoft support. (Microsoft support have actually called me to find out how to fix a problem in a Microsoft product - a problem that should have been trivial for them to debug if they had code access.)
Eivind.
My background (authority) for this claim: I've been an OS developer (FreeBSD and briefly OpenBSD), I've done various forms of embedded systems work (from minature through games to providing systems based off FreeBSD), and I've tracked operating systems integration for about 20 years.
Eivind.
You are missing something: Programs are DESIGNS. This is an important point. This is a VERY important point.
Programming is like the DESIGN of the T-Ford, which was never automated. The PRODUCTION of programs has already been automated - it's the compilation and duplication I get when I do "make && make install".
Eivind.
Eivind.
A large number of uninformed users rapidly start giving *some* support to others, and the short path upwards makes this work fairly well. The problem with the commercial companies is that their developers are NOT available to give support.
Heck, I know a numbers of the developers at Apple, and when they were doing FreeBSD, we'd be exchanging support - in the public mailing lists and in the form of code, making it all available for everybody. Now that's gone, and the feedback loop with it.
At Microsoft, the high end support people don't even have access to developers or code. I had one case where one of my consulting customers had a problem with an Exchange server on a clustered system. They were a large, priority Microsoft support customer (with a very expensive support contract), and my customer had lodged about a ticket a month earlier, and now things were coming to a push, so they'd had two people trying to solve the case locally for three days. No go. Then a Unix person there (me, actually, but that's besides the point) was pulled in, went through the docs, found an analogous problem with a solution for MS-SQL, they tested the solution, and voila - it worked! It was a fairly trivial registry tweak that would have been obvious from looking at the source (direct string compare on an id that wasn't the same for RAID disks).
Anyway, the ticket with Microsoft support was closed. An hour or two later, MS support called back. They wanted to know what my customer had done to resolve the problem - since MS support had three other priority support tickets against the same problem, and hadn't been able to find a solution.
This is what happens when support doesn't have access to and competence in the source code. Open source OS projects give better support and are more responsive because we have that access, and because we get into the habit that if a customer is willing to give us info on a reproducable, we will solve the problem. We almost never have any insurmountable barrier that stop us from doing so.
Eivind.
The reasons for faster response, from my point of view (having had a commit bit for FreeBSD for almost a decade now):
- The developers actually do support. They're in contact with the end users. And some of the end users are other coders, and are allowed to do things with the OS code. This allows them to send in suggestions for how to fix their own problem. As opposed to the rumours, we only use these as is less than half the time - yet they're useful for pointing out things.
- The developers are allowed to prioritize their own time. This result in both higher quality code (developers clean up when they feel cleanup is warranted), and easy end user problems being prioritized. Especially in combination with developers doing support.
- Open source software is mostly designed based on what's technically reasonably easy, not marketing. This makes for simpler and more nimble codebases.
- Open source goes through evolution: Those codebases that aren't nimble mostly die. In closed source software, those codebases that sell can add more resources (programmers) to get around not being nimble.
I think these things are much more important. Especially the first two.Eivind.
Here's longer discussion.
Eivind.
It is possible downloads/release over the last year should contribute quite a bit (to cover the projects that's mostly interesting around release time).
Eivind.
On to problem areas for open source in general:
- Problem report to patched, committed source with commit comment. The path is LONG - even if you have a checked out tree, you'll need to save the patch, switch windows, cd to an appropriate directory, run a patch command, run a commit command, and write a commit message.
- Ability to integrate automated testing on commit. This is possible, yet it's an utter pain in most version control systems. (Aegis gets it mostly right, of course, as this was the original reason for Aegis).
- Project search is difficult, even including SF.net and Freshmeat and Freshports and pkgsrc and Debian package metadata and CPAN and
...
- The problem report/issue tracking systems I know of are icky to use for large projects. (They're icky for small, too, but there the ickyness doesn't matter much)
- There is no way to mark up code with discussions a la a Wiki.
- There's no easy way to mark up code for high quality UML output, so people can get into projects quickly
- Every project end up setting up their own infrastructure for archiving chat logs
- Mailing list archive search is icky, and this is necessary to find why what happened. (This may, unfortunately, always end up being icky.)
- There's no (perceived as) reliable, scalable version control system that handle distributed branching/development.
I can write up points for hours - and have. Unfortunately, my last try at dealing with many of these issues (http://www.rubyarchive.org, presently so defunct that the Wiki has been spammed almost out of existence) ended up being sabotaged, and I'm sort of demotivated towards doing any more tries...Eivind.
In "The mythical man month", Fred Brooks simplified it as "Adding manpower to a late software project makes it later."
Eivind.
How "encountered"? And how do you want to merge files with folders?
Eivind.
Windows will end up preloading (to cache) important parts of IE in many cases. This decrease load time. COW page sharing could also decrease the amount of memory spent by IE, though I suspect relocation will make page sharing minimal (and I'm not even sure if Windows implement COW).
Eivind.
Eivind.
Now, please go learn about the 1990s technique of "filesystem caching". This means that the DLLs can effectively bepreloaded even if they are loaded by another process in another memory space. All that's needed is a memory copy from the cache and a relocation, which is much cheaper than a load from disk.
Eivind.
Eivind.
Preferably, it would also be possible to post an explanation of why it is wrong at the same time, without that "Cannot post and moderate" restriction.
Eivind.
Eivind.
(A) OpenDarwin wasn't run by Apple.
(B) Apple is sharing code both by distributing it directly and (occasionally) by having Mac OS engineers commit it directly into the FreeBSD tree. The latter means that people from Apple are doing all the adaption work to actually make the code directly usable by the upstream.
While I wish there was even more of (B), I blame the low level on inadequate tools - the version control systems in use make this a pain to do. That's also the reason for much of the divergence of Free/Net/OpenBSD.
Eivind.
Eivind.
Eivind.