"dll hell" lasted? This is still a major problem, and one of the major goals of CLR and managed code is to finally address this problem.
And this is not just a Windows problem. Ok, it's.so hell instead of.dll hell, but I have versioning issues with core libraries like libC, qt, etc. all the time.
>>...is not the industry that most programmers work in.
This is absolutely true. However, the interesting point is that the software industry is trying to encroach on the industry in which most programmers do work: internal IS custom development.
For example:
Many millions (billions?) of programmer hours have been invested in writing slightly different versions of a double entry accounting system. Look around your company - there is at least one person making a decent living supporting custom accounting/hr/payroll applications. The software industry (Oracle, SAP, PeopleSoft, Siebel, etc) is agressively trying to put this person on the unemployment line. The fact that these companies have not yet been successful in this attempt does not change my opinion that eventually they will be successful: off-the-shelf (OTS) vs. custom is a solved problem, and it is only a matter of product iterations (5?) before the field is cleared.
In fact, outside of data processing (collecting information in a relational database and running reports on said data), the battle between OTS and custom is over. The fact that the battle between the commerical software industry and the open source software industry in these arenas is ongoing is irrelevant to the 98% of software developers employed by internal IS. Today, no one in your company in making a living writing device drivers, operating systems, network stacks or word processing programs, as they might have been 10-15 years ago.
So, if current trends continue, what is the prognosis for the mainstream software developer? Are we auto mechanics - our services commoditized and wages lowered by massive standardization and upstream quality improvements? Are we electrical engineers - our hand crafted circuits driven out by general purpose registers and instructions? Are we secretaries and typists - destroyed by a cultural change and widespread adpotion of do-it yourself tools (computers, word processing software and voice mail systems)?
I don't know. If I did, I would be as rich as Larry Ellison.
In "The Cathedral and the Bazaar", Eric Raymond describes how to run a successful 3GL project as a community software initiative. And by and large, the great success stories of the Open Source movement have been 3GL projects. In his essay "The Magic Cauldron", Eric Raymond discusses how the open source revolution will effect the economics of software development. He starts by describing the qualities a program must have to be a candidate for open source development:
"For purposes of examining this question, it will be helpful to sort kinds of software by the degree of completeness which the service they offer is describable by open technical standards, which is well correlated with how commoditized the underlying service has become...(as)...services become commoditized, they will in turn tend to fall into the open-source infrastructure -- a transition we're seeing in operating systems right now." [tMC]
What is interesting for our argument is that the criteria Eric describes for a project to be open source are very similar to the criteria for a project to be executed with a 4GL. Open source software requires that the application be a commodity service with open technical standards. 4GL applications exist as a collection of commoditized components which communicate through open, standards based interfaces. He goes on to say:
"Finally, we may note that purveyors of unique or just highly differentiated services have more incentive to fear copying of their methods by competitors than do vendors of services for which the critical algorithms and knowledge bases are well understood. Accordingly, open source is more likely to dominate when (e) key methods (or functional equivalents) are part of common engineering knowledge." [tMC]
Once again, the conditions which create a strong preference for open source are the same conditions which create a strong preference for using a 4GL. The application which turns on your VCR from your web browser is a unique and highly differentiated service, while the critical algorithms and knowledge bases of double entry accounting are certainly part of common engineering knowledge. The example of accounting software is an interesting one, because the most successful commercial 4GL programs on the market today are extended accounting packages, sold under the generic name of "Enterprise Resource Planning" (ERP) applications. ERP applications are pathologically closed source; they are tightly controlled by the software vendor, difficult to implement, extremely difficult to customize, very expensive, upgraded infrequently, and always filled with bugs.
"Suppose you open-source that accounting package. It becomes popular and benefits from improvements made by the community. Now, your competitor also starts to use it. The competitor gets the benefit without paying the development cost and cuts into your business. Is this an argument against open-sourcing?" [tMC]
The answer to this question is no, and the proof is the Business Process Reengineering (BPR) which generally accompanies the implementation of an ERP package. While the person doing the BPR will probably charge three hundred dollars an hour, and may take (upwards) of a year to get to the point, what they will eventually tell you is that instead of trying to customize the ERP package to fit your business processes, you should just change you business processes to fit the ERP package. The fact that companies in the same industry, in the same market segment, would spend a lot of time and a lot of money, to achieve the same business process as their competitor shows that whether or not another company has the source code to your accounting software, the fact that the other company has the same binary version of your accounting software means that there is no possible competitive advantage from the accounting software in any form.
Slashdot Mirror
"dll hell" lasted? This is still a major problem, and one of the major goals of CLR and managed code is to finally address this problem.
.so hell instead of .dll hell, but I have versioning issues with core libraries like libC, qt, etc. all the time.
And this is not just a Windows problem. Ok, it's
>>...is not the industry that most programmers work in.
This is absolutely true. However, the interesting point is that the software industry is trying to encroach on the industry in which most programmers do work: internal IS custom development.
For example:
Many millions (billions?) of programmer hours have been invested in writing slightly different versions of a double entry accounting system. Look around your company - there is at least one person making a decent living supporting custom accounting/hr/payroll applications. The software industry (Oracle, SAP, PeopleSoft, Siebel, etc) is agressively trying to put this person on the unemployment line. The fact that these companies have not yet been successful in this attempt does not change my opinion that eventually they will be successful: off-the-shelf (OTS) vs. custom is a solved problem, and it is only a matter of product iterations (5?) before the field is cleared.
In fact, outside of data processing (collecting information in a relational database and running reports on said data), the battle between OTS and custom is over. The fact that the battle between the commerical software industry and the open source software industry in these arenas is ongoing is irrelevant to the 98% of software developers employed by internal IS. Today, no one in your company in making a living writing device drivers, operating systems, network stacks or word processing programs, as they might have been 10-15 years ago.
So, if current trends continue, what is the prognosis for the mainstream software developer? Are we auto mechanics - our services commoditized and wages lowered by massive standardization and upstream quality improvements? Are we electrical engineers - our hand crafted circuits driven out by general purpose registers and instructions? Are we secretaries and typists - destroyed by a cultural change and widespread adpotion of do-it yourself tools (computers, word processing software and voice mail systems)?
I don't know. If I did, I would be as rich as Larry Ellison.
Ram Sadasiv
Hopefully, this would at least help you get started.
Ram Sadasiv
"For purposes of examining this question, it will be helpful to sort kinds of software by the degree of completeness which the service they offer is describable by open technical standards, which is well correlated with how commoditized the underlying service has become...(as)...services become commoditized, they will in turn tend to fall into the open-source infrastructure -- a transition we're seeing in operating systems right now." [tMC]
What is interesting for our argument is that the criteria Eric describes for a project to be open source are very similar to the criteria for a project to be executed with a 4GL. Open source software requires that the application be a commodity service with open technical standards. 4GL applications exist as a collection of commoditized components which communicate through open, standards based interfaces. He goes on to say:
"Finally, we may note that purveyors of unique or just highly differentiated services have more incentive to fear copying of their methods by competitors than do vendors of services for which the critical algorithms and knowledge bases are well understood. Accordingly, open source is more likely to dominate when (e) key methods (or functional equivalents) are part of common engineering knowledge." [tMC]
Once again, the conditions which create a strong preference for open source are the same conditions which create a strong preference for using a 4GL. The application which turns on your VCR from your web browser is a unique and highly differentiated service, while the critical algorithms and knowledge bases of double entry accounting are certainly part of common engineering knowledge. The example of accounting software is an interesting one, because the most successful commercial 4GL programs on the market today are extended accounting packages, sold under the generic name of "Enterprise Resource Planning" (ERP) applications. ERP applications are pathologically closed source; they are tightly controlled by the software vendor, difficult to implement, extremely difficult to customize, very expensive, upgraded infrequently, and always filled with bugs.
"Suppose you open-source that accounting package. It becomes popular and benefits from improvements made by the community. Now, your competitor also starts to use it. The competitor gets the benefit without paying the development cost and cuts into your business. Is this an argument against open-sourcing?" [tMC]
The answer to this question is no, and the proof is the Business Process Reengineering (BPR) which generally accompanies the implementation of an ERP package. While the person doing the BPR will probably charge three hundred dollars an hour, and may take (upwards) of a year to get to the point, what they will eventually tell you is that instead of trying to customize the ERP package to fit your business processes, you should just change you business processes to fit the ERP package. The fact that companies in the same industry, in the same market segment, would spend a lot of time and a lot of money, to achieve the same business process as their competitor shows that whether or not another company has the source code to your accounting software, the fact that the other company has the same binary version of your accounting software means that there is no possible competitive advantage from the accounting software in any form.
Ram Sadasiv
Exceprted from Linux Database Programming