I think that this statement from the letter sums of the problem rather well:
"What message does the company taking a position send to its employees who have strongly-held beliefs on the opposite side of the issue?"
We have dealt with this same question in my company where the leaders in the company have strong feelings about social issues and are tempted to use the power of the corporation to foist those opinions on the employees. I think Ballmer gets it right when he indicates that Microsoft has an interest in taking a stance on legislative issues that affect the business in terms of competitiveness and other less-social concerns. A company as large as Microsoft has employees that will have opinions on social issues that cover the entire spectrum. It's threatening to employees for the corporation to take a public position on these kinds of personal issues. I think that it's healthy for corporations to set a tone for it's workers that focus on cultivating a work environment focused on productivity and cooperation. I applaud Ballmer.
It's interesting to note that almost every item that he has taken a photo of is some sort of take out food. Very little homecooked food is shown. Is that now a typical diet?
Escrows a viable compromise for vertical markets
on
Source Code Escrow
·
· Score: 1
Several companies I worked with also use source code escrow agreements for closed source software. We wouldn't get it for general purpose software that costs from $100's to $1000's. Escrow agreements are viable for vertical markets, very specialized software such as Mortgage Processing, Insurance Claims Processing, Insurance Agency Management Systems, and other specialized enterprise software. You won't yet find too much open source software in the vertical markets because, I'd argue, the needs are too specialized and varied. The money is there for sure. But these industries can't rely on the open source community to develop their software because their needs are specialized. They don't have much motivation to release developed software into to the public domain because, as the software is specialized, it's like publishing your business processes. You help your competitors.
So when such software is purchased, it's from a vendor which has a relatively narrow market and therefore is expensive ($10,000's-$1,000,000's). The escrow agreement is a nice compromise that allows a company to invest in a smaller IT company that is producing what you consider mission critical software.
Getting a source code escrow agreement depends on how badly the IT vendor wants your contract.
I'm a bit surprised by the D- for NASA. I was a NASA contractor for many years, and about 5 years ago NASA got very serious about implementing the requirments of OMB Circular A-130 Security Management of Federal Automated Information Resources. In particular, NASA developed a set of its own stricter guidelines to respond to Section III of the OMG circular. NASA referred to this as NPG 2810 and instructed all program-related data centers and contractors to implement post-haste.
Money was added to our contract to facilitate the implementation, the NASA CIO oversaw the implementation effort and assigned both security contractors and internal security managers to coordinate the implementation. The schedule was fast paced, and within 3 months we had completed 3 detailed plans: Risk Assessment, IT Security, and Contingency. We then had 6 months to implement. After 6 months we were audited by a independent security team. We were audited every 6 months with proactive scanning, plan checks, security background checks, and other auditing methods.
About 1.5 years after kicking this effort off, we asked to begin penetration testing, and NASA hired an independent contractor to conduct an aggressive penetration test. NASA demanded compliance, we were responsive, and NASA provided the resources (including training). While I don't know how comprehensively NASA applied this same attitude to all of its programs, they were very aggressive with all contractors as well as NASA-run data centers within the same program area. I'm flabbergasted to see a D-grade for them!
Several companies I worked with also use source code escrow agreements for closed source software. We wouldn't get it for general purpose software that costs from $100's to $1000's. Escrow agreements are viable for vertical markets, very specialized software such as Mortgage Processing, Insurance Claims Processing, Insurance Agency Management Systems, and other specialized enterprise software. You won't yet find too much open source software in the vertical markets because, I'd argue, the needs are too specialized and varied. The money is there for sure. But these industries can't rely on the open source community to develop their software because their needs are specialized. They don't have much motivation to release developed software into to the public domain because, as the software is specialized, it's like publishing your business processes. You help your competitors. So when such software is purchased, it's from a vendor which has a relatively narrow market and therefore is expensive ($10,000's-$1,000,000's). The escrow agreement is a nice compromise that allows a company to invest in a smaller IT company that is producing what you consider mission critical software.
Getting a source code escrow agreement depends on how badly the IT vendor wants your contract.
A little forking goes on even in closed-source software, but as the author of the article says, the maintenance is not survival of the fittest, but more market driven. Various versions are kept operational and upgraded separately. The closed-source folks don't want to give away their business, so the forking is kept internal and to a minimum because it costs more to maintain multiple versions. In the open-source world, the forks are typically developed by different teams, so new resources are added to the project.
Without a doubt, forking is a natural part of the open source process, and is important. Since it can sometimes entail substantial costs for the user (say a completely new configuration or security model, or new database structures to convert) it understandable why business will stay with the tried and true as opposed to the latest and greatest.
Gads, there's a lot to say about this topic. It gets at the core of why open-source can jump ahead of closed source projects. It's evolution following the theory of punctuated equilibrium[wikipedia.org].
Slashdot Mirror
I think that this statement from the letter sums of the problem rather well:
"What message does the company taking a position send to its employees who have strongly-held beliefs on the opposite side of the issue?"We have dealt with this same question in my company where the leaders in the company have strong feelings about social issues and are tempted to use the power of the corporation to foist those opinions on the employees. I think Ballmer gets it right when he indicates that Microsoft has an interest in taking a stance on legislative issues that affect the business in terms of competitiveness and other less-social concerns. A company as large as Microsoft has employees that will have opinions on social issues that cover the entire spectrum. It's threatening to employees for the corporation to take a public position on these kinds of personal issues. I think that it's healthy for corporations to set a tone for it's workers that focus on cultivating a work environment focused on productivity and cooperation. I applaud Ballmer.
It's interesting to note that almost every item that he has taken a photo of is some sort of take out food. Very little homecooked food is shown. Is that now a typical diet?
Several companies I worked with also use source code escrow agreements for closed source software. We wouldn't get it for general purpose software that costs from $100's to $1000's. Escrow agreements are viable for vertical markets, very specialized software such as Mortgage Processing, Insurance Claims Processing, Insurance Agency Management Systems, and other specialized enterprise software. You won't yet find too much open source software in the vertical markets because, I'd argue, the needs are too specialized and varied. The money is there for sure. But these industries can't rely on the open source community to develop their software because their needs are specialized. They don't have much motivation to release developed software into to the public domain because, as the software is specialized, it's like publishing your business processes. You help your competitors.
So when such software is purchased, it's from a vendor which has a relatively narrow market and therefore is expensive ($10,000's-$1,000,000's). The escrow agreement is a nice compromise that allows a company to invest in a smaller IT company that is producing what you consider mission critical software.
Getting a source code escrow agreement depends on how badly the IT vendor wants your contract.
I'm a bit surprised by the D- for NASA. I was a NASA contractor for many years, and about 5 years ago NASA got very serious about implementing the requirments of OMB Circular A-130 Security Management of Federal Automated Information Resources. In particular, NASA developed a set of its own stricter guidelines to respond to Section III of the OMG circular. NASA referred to this as NPG 2810 and instructed all program-related data centers and contractors to implement post-haste.
Money was added to our contract to facilitate the implementation, the NASA CIO oversaw the implementation effort and assigned both security contractors and internal security managers to coordinate the implementation. The schedule was fast paced, and within 3 months we had completed 3 detailed plans: Risk Assessment, IT Security, and Contingency. We then had 6 months to implement. After 6 months we were audited by a independent security team. We were audited every 6 months with proactive scanning, plan checks, security background checks, and other auditing methods.
About 1.5 years after kicking this effort off, we asked to begin penetration testing, and NASA hired an independent contractor to conduct an aggressive penetration test. NASA demanded compliance, we were responsive, and NASA provided the resources (including training). While I don't know how comprehensively NASA applied this same attitude to all of its programs, they were very aggressive with all contractors as well as NASA-run data centers within the same program area. I'm flabbergasted to see a D-grade for them!
Several companies I worked with also use source code escrow agreements for closed source software. We wouldn't get it for general purpose software that costs from $100's to $1000's. Escrow agreements are viable for vertical markets, very specialized software such as Mortgage Processing, Insurance Claims Processing, Insurance Agency Management Systems, and other specialized enterprise software. You won't yet find too much open source software in the vertical markets because, I'd argue, the needs are too specialized and varied. The money is there for sure. But these industries can't rely on the open source community to develop their software because their needs are specialized. They don't have much motivation to release developed software into to the public domain because, as the software is specialized, it's like publishing your business processes. You help your competitors. So when such software is purchased, it's from a vendor which has a relatively narrow market and therefore is expensive ($10,000's-$1,000,000's). The escrow agreement is a nice compromise that allows a company to invest in a smaller IT company that is producing what you consider mission critical software.
Getting a source code escrow agreement depends on how badly the IT vendor wants your contract.
A little forking goes on even in closed-source software, but as the author of the article says, the maintenance is not survival of the fittest, but more market driven. Various versions are kept operational and upgraded separately. The closed-source folks don't want to give away their business, so the forking is kept internal and to a minimum because it costs more to maintain multiple versions. In the open-source world, the forks are typically developed by different teams, so new resources are added to the project.
Without a doubt, forking is a natural part of the open source process, and is important. Since it can sometimes entail substantial costs for the user (say a completely new configuration or security model, or new database structures to convert) it understandable why business will stay with the tried and true as opposed to the latest and greatest.
Gads, there's a lot to say about this topic. It gets at the core of why open-source can jump ahead of closed source projects. It's evolution following the theory of punctuated equilibrium[wikipedia.org].