You still haven't grasped the concept.

Daily builds are not there to solve customer problems.

Daily builds are there for the developers and the in-house testers.

Daily builds are mainly there to be able to test work-in-progress. Be it new functions or bug fixes.

But no, it doesn't matter if you talk about open-source projects or commercial projects. The goal with daily builds is still not to have good software for end users. The goal is to make sure
1) That you all the time ends the day with buildable source code.
2) That you all the time have some form of code base you can run automatic regression testing on.
3) That you have a - potentially very rough - code base where testers can check if a specific bug reported in a current release (note "release" - not "daily build") still seems to exist or not.
4) Daily builds for open source projects, or for larger corporate projects, is the way to make sure lots of developers from potentially a large geographic region, works towards source code that integarete into a single working product.

So no - there are no driving forces or goals that projects (commercial or not) should supply daily builds to end users.

On the contrary - many open-source projects ships daily builds to end users just because they do not have a working release team. They do not have a strong person (with enough time on his/her hands) or team that can follow the progress charts for the regression tests, and that can spend lots of own time testing, testing, testing before packaging new real releases.

In real life, it's mostly one-man operations (where the state of the program is well known since all changes are decided, implemented, tested and documented by a single person) or corporations with product management, testing and development as different entitites, that can do us the favour of releasing specific, named, releases with specific history files etc revolving around bug fixes and feature improvements.

What you ask for and thing is a minimum requirement, is in reality normally the lazy backdoor for projects that are run without strict control.

Microsoft does daily builds (see the build number after the version?). But it is for inhouse testing. There is a product management board that decides when it is time to send out beta versions (and what nightly builds that will be accepted as beta releases), release candidates, commercial releases etc.

Debian does daily builds. And the target are software developers who actively develop source code packages etc. But they have a 'unstable', a 'testing' and a 'stable' release, where users are intended to use "stable", while people who like to live a bit on the dangerous side to get new features quicker may run "testing". The unstable release isn't for end users. It's for developers.

Many, many projects has - besides fixed releases and potential daily builds - a direct access to their source code repository. But same thing there. It isn't intended for end users. It's intended for developers, with the skill to build, test, fix, report back patches, ...

So commercial companies should not really release any daily builds because it is against the values, policies, goals, etc of a commercial company. And for the large majority of customers, it would be counterproductive. And being commercial, they obviously should not put their source code repositories online either, or they'll get a competitor (commercial or privateer) that will try to rip the best part of the code and merge with some other own or "stolen" code into a competing package.

You should really have figured out the differences between commercial projects and hobby projects by now. Commercial projects have commercial testers and commercial support. For 99% or 99.9% or 99.99% of all users, it is way better to get someone else to fix the problems and supply the fixes than to have to figure it out by themselves. The only real difference is when the product is aimed at software developers. But then most software developers still don't have the skill to update random - large - software packages. Being able to write embedded source code doesn't mean you can work with compiler source code, database source code, window manager source code etc.

You had an example about a software feature. So the majority of users would not be helped by any dailies. And they would not have the skills to implement extra features from a repository. What we do, when using commercial products, is that we either inform them what we want and wait for results. Or we vote with our wallets and find another product. That is what commercial software is intended to be about. Unless you with commercial software would mean software you order written by a consultant. But that isn't really the view we are expected to have here, so it's irrelevant.

You, as the customer, must do the work of figuring out what is a good product. And what is a good company. That is your responsibility. When you fail that, you can't really blame the concept of commercial companies. Commercial companies behaves similar to private projects. They have good project management and their products progresses forward at high speed and with good responses based on customer requests. Or they get worse project management and the customers don't get the updates that the customers would have liked. Same with open-source projects. There are millions of splits of open-source projects since the original project slowed down. And the majority of these splits are dead ends. The person(s) splitting the source didn't had the stamina or skills to do something more than fix a nice web page or register their split on source forge. But it ends up a dud.


I'm not misquoting, because it wasn't a quote. But yes, Richard. You have at more than one time given that message. Listening to music while working means the person is lazy and would get sent out the door - or wouldn't have been let in the door in the first place. Then there are a couple of posts by you where you have tried to back-track a bit when you have found that you didn't see anyone agreeing with you.

The people who plays so loudly in their "poorly-fitting earbuds" can be found on the bus on their way to their station at the dish washer - sorry but I just have to guess there. The fact is that I have often seen them on a bus. But never seen them in any commercial environment. So either they switch their behaviour when they start working, or they do not work in any area of business I have ever come into contact with. But I have seen lots of developers with head phones. None busy playing their music in a way that it affected the people around them. All playing their music as a way to screen themselves from the rest of the room, to make them concentrate on their task instead of the phone calls around them.

There are developers of all skills out there (alas), but I do not think you can recognize them on clothes or music preferences. It isn't what they look like that tells you how good they are.

About commercial commpanies making money. Just about all companies that focuses on making money listens to the customers. There are mainly two reasons for companies to do something else:
- they have a management that gets a specific bonus for short-term profit, so they maximize the profit by keeping down on costs. Such companies dies quickly.
- they have a policty to maximize the value of the company. So they focus on the stock market, or want someone to buy the company to make a great exit.

But the above are not general situations for companies. It things that happens because of specific people at specific positions in the company organisation or boards. And it tends to be self-rectifying. The companies dies or gets bought (and potentially killed) or management notices how they have lost market shares.

Since it isn't a general situation for commercial companies, you can't use it as a general concept for complaining. It's only meaningful when talking about specific companies at specific points in time. Like how Borland almost dropped out of the market, when they got run by ties that decided that the company must not agree to known bugs and must not publish change documents listing bug fixes.

But the majority of companies focuses on real customers buying their products often enough (either support contracts, or buying new releases with more features or whatever concept they have) to make a profit. So they know they all-the-time must run. It is well known that you must run forward or die. Standing still means to die. Companies that stands still does it because they have lost their driving force. But that isn't a commercial problem. It's a general problem affecting any product developed using any concept. There are but a few open-source projects that have managed to get an organisation where there are multiple, independant, driving forces in the organisation, and organized in a way that they can keep the product progressing without inhouse fighting. Most projects can't, so open-source is not a good concept to discuss as an example of how it should work. The good thing about open source is that they source doesn't have to die when the team dies. But the teams are more likely to die than the commercially operated project teams.