Clopen Source refers to Open Source projects that have adopted practices that Close off uses or rights. There is a special category of Clopen Source that feature a Corporate Entity like Sun, Microsoft, Novell or any large company, supporting the Open Source software. This blending of Corporate and Open Source software should be labeled as such as Corpen Source.
Novell is currently the corporate patron of the Mono project. Mono could be summarized as Dot Net Framework Everywhere. That is the making the Dot Net Framework available on non Windows OS but it will also be available on Windows. If Mono remains successful, this cross platform capacity would make it preferable to Microsoft's version. So one can see how Novell interest in this project and as the corporate sugar daddy it is clear Novell will call the shots. As such, Mono is a Corpen Source project.
Firefox which is spun out of Mozilla is a Corpen project of Mozilla. But in addition to this Google provides significant resources in exchange for access. The integration of Google search and antiphishing consolidates Firefox as a Clopen Source project.
In addition to Corpen Source there are Corpen Standards projects. Microsoft submitted C# before ISO and ECMA, but as Microsoft provides all the resources it is clear C# is a Clopen Standard. Sun started to submit Java to ISO and ECMA but withdrew and released large portions under the GNU GPL instead. No doubt this was an attempt to get Java accepted as an Open Standard while retaining control. Having failed this they made Java into a Clopen Source project.
Showing posts with label Clopen Source. Show all posts
Showing posts with label Clopen Source. Show all posts
Sunday, July 20, 2008
Saturday, July 19, 2008
Clopen Source
The promise of Open Source was Free Software.
Open Source takes it's name from the practice that the source code should be open in all senses. It should be Open for Inspection. It should be Open for Contributions and It should be Open for Repurposing for Alternate Uses.
But like the first communes and every commune since, it is broken up by questions of who owns what and who should decide. One piece of property that no open source project will surrender is their trademark. Trademark becomes the camels nose under the tent. Here the camel is asserting that the software is Closed for some purposes.
More of the Closed camel follows because there must be some entity to govern both the use of the property and development of the software. If no one became rich or famous, a minimal platonic democracy could have formed and it would somehow work. Now everyone has an eye on cashing in big on their Open Source project. Often the projects license have terms that allow the owners to take back the software.
Open Source takes it's name from the practice that the source code should be open in all senses. It should be Open for Inspection. It should be Open for Contributions and It should be Open for Repurposing for Alternate Uses.
But like the first communes and every commune since, it is broken up by questions of who owns what and who should decide. One piece of property that no open source project will surrender is their trademark. Trademark becomes the camels nose under the tent. Here the camel is asserting that the software is Closed for some purposes.
More of the Closed camel follows because there must be some entity to govern both the use of the property and development of the software. If no one became rich or famous, a minimal platonic democracy could have formed and it would somehow work. Now everyone has an eye on cashing in big on their Open Source project. Often the projects license have terms that allow the owners to take back the software.
The GNU License is another common closing. Because this license grows virally you must always be worried that the free software you use will ultimately cost you your software.
A minor variation of open source software closing are projects that require extensive signing over of rights. Fortunately the irritation factor has caused these project to wither.
The takeaway from all of this is every Open Source project has some significant Closed aspects to it. As such we should borrow a term from mathematics and label projects that are significantly closed as Clopen Source. And projects which use the GNU License or have take back provision should present themselves as Clopen Source projects.
Friday, July 18, 2008
Open Source's Infinite Budget: Part 2 Your Company
Open Source has an infinite budget
As I discussed in Part 1 The Community, the open source community is not the source of this infinite budget. In fact the Open Source projects are overrun with bugs and security breaches and as such are turning to various Clopen models to generate revenue. Most of the Clopen Source modes are failing. (The notable exceptions are using a variant of Clopen Source which can be called Corpen Source which I will address in another post.) So if the infinite budget is not in the community where is it?
If you have allowed a free reign of open source in your company then it is coming from you. And it is being spent in a way that should alarm you.
Suppose your company allows the use of any and all open source tools. To the developer this is functionally the equivalent of an infinite budget for open source tools and software.
Whenever the developer wants a tool it's purchase is automatically approved because the price "free" does not reduce any budget.
He then can start using the tool and all is well.
Provided of course that it stands alone and has no bugs or security problems. Oh and provided of course that he does not need to learn how to use it. But if it needs to be integrated or bugs need to fixed then the budget that pays for it is hidden from management.
The developer will be spending hours integrating or fixing or working around bugs. These hours come out of the finite number of developer hours available to you. Note there is no check or limit on how much effort will be spent on supporting open source in your company, as such the budget for open source that you are paying is infinite.
So what is the moral? Never use open source software?
No, the answer is harder than that. What is called for here is management. Management means monitoring and making some hard decisions based on facts. Some open source software, NUnit would be may favorite example, is almost defect free and can be easily used with little integration or learning ramp up time.
But keep an eye on these, even if you stick to solid open source software, the integration costs increase at a factorial rate as the number of components increase.
There will come a time when you should opt to use a development stack and pay a flat fee instead. MSDN is a great example. For a few hundred dollars a developer (partner pricing) you can get access to all the software needed and at the same time the integration costs disappear.
As I discussed in Part 1 The Community, the open source community is not the source of this infinite budget. In fact the Open Source projects are overrun with bugs and security breaches and as such are turning to various Clopen models to generate revenue. Most of the Clopen Source modes are failing. (The notable exceptions are using a variant of Clopen Source which can be called Corpen Source which I will address in another post.) So if the infinite budget is not in the community where is it?
If you have allowed a free reign of open source in your company then it is coming from you. And it is being spent in a way that should alarm you.
Suppose your company allows the use of any and all open source tools. To the developer this is functionally the equivalent of an infinite budget for open source tools and software.
Whenever the developer wants a tool it's purchase is automatically approved because the price "free" does not reduce any budget.
He then can start using the tool and all is well.
Provided of course that it stands alone and has no bugs or security problems. Oh and provided of course that he does not need to learn how to use it. But if it needs to be integrated or bugs need to fixed then the budget that pays for it is hidden from management.
The developer will be spending hours integrating or fixing or working around bugs. These hours come out of the finite number of developer hours available to you. Note there is no check or limit on how much effort will be spent on supporting open source in your company, as such the budget for open source that you are paying is infinite.
So what is the moral? Never use open source software?
No, the answer is harder than that. What is called for here is management. Management means monitoring and making some hard decisions based on facts. Some open source software, NUnit would be may favorite example, is almost defect free and can be easily used with little integration or learning ramp up time.
But keep an eye on these, even if you stick to solid open source software, the integration costs increase at a factorial rate as the number of components increase.
There will come a time when you should opt to use a development stack and pay a flat fee instead. MSDN is a great example. For a few hundred dollars a developer (partner pricing) you can get access to all the software needed and at the same time the integration costs disappear.
Wednesday, July 16, 2008
Open Source's Infinite Budget: Part 1 The Community
Functionally Open Source has an unlimited budget.
Open Source promoters rave about the legion of programmers that stand poised to squash any bug that emerges and the other legion diligently adding features and functionality that the suits would never allow in a corporate run development and yet another legion that will repair any security breach discovered. It would appear that there is a bottomless pit development resources for any Open Source project.
But despite this, Open Source projects are plagued with bugs and security failures. Boosterism on the part of the Open Source believers and antipathy (the contempt and aversion variety) on the part of Open Source skeptics has resulted in these defects receiving little coverage.
So let me refresh your memory with a few salient recent developments. In a head to head security test of the LAMP (Linux Apache MySql PHP) stack versus the Microsoft stack, the LAMP stack was breached first. Linus Torvalds has been quoted "Even by the most *stringent* reasonable rules, we add a new bug every four days." Linus is pleading for us to look past the bugs because of all the features they are adding. What he and other Open Projects are lacking is resources devoted to QA. But even if they had adequate QA there is an additional lack of desire in developers working for free to fix bugs. They would much rather implement some bright shiny object.
This lack has on the one hand caused Linus to threaten to halt all new development on the kernel so that the bugs must be fixed. And in the rest of the community we have seen numerous experiments in Clopening the software. (Clopen is a term borrowed from the mathematicians, it is possible for things like sets to be both closed and open in math, when this happens they joke that the set is clopen). The idea behind Clopening the Software is this will give the projects resources to get a handle on Architecture and QA as well as means of providing the maintenance to fix those bugs no one wants to work. Often the Clopen occurs by offering privileged access for those who pay a premium. The software projects are surprised to learn that there are few takers and in return for the small amount of revenue they want quite a bit of control.
Which leaves one to conclude that Open Source's Infinite Budget does not come from the community. In Part 2 Your Company, we will find the ugly truth.
Open Source promoters rave about the legion of programmers that stand poised to squash any bug that emerges and the other legion diligently adding features and functionality that the suits would never allow in a corporate run development and yet another legion that will repair any security breach discovered. It would appear that there is a bottomless pit development resources for any Open Source project.
But despite this, Open Source projects are plagued with bugs and security failures. Boosterism on the part of the Open Source believers and antipathy (the contempt and aversion variety) on the part of Open Source skeptics has resulted in these defects receiving little coverage.
So let me refresh your memory with a few salient recent developments. In a head to head security test of the LAMP (Linux Apache MySql PHP) stack versus the Microsoft stack, the LAMP stack was breached first. Linus Torvalds has been quoted "Even by the most *stringent* reasonable rules, we add a new bug every four days." Linus is pleading for us to look past the bugs because of all the features they are adding. What he and other Open Projects are lacking is resources devoted to QA. But even if they had adequate QA there is an additional lack of desire in developers working for free to fix bugs. They would much rather implement some bright shiny object.
This lack has on the one hand caused Linus to threaten to halt all new development on the kernel so that the bugs must be fixed. And in the rest of the community we have seen numerous experiments in Clopening the software. (Clopen is a term borrowed from the mathematicians, it is possible for things like sets to be both closed and open in math, when this happens they joke that the set is clopen). The idea behind Clopening the Software is this will give the projects resources to get a handle on Architecture and QA as well as means of providing the maintenance to fix those bugs no one wants to work. Often the Clopen occurs by offering privileged access for those who pay a premium. The software projects are surprised to learn that there are few takers and in return for the small amount of revenue they want quite a bit of control.
Which leaves one to conclude that Open Source's Infinite Budget does not come from the community. In Part 2 Your Company, we will find the ugly truth.
Subscribe to:
Posts (Atom)