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.
Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts
Wednesday, July 16, 2008
Friday, May 30, 2008
Challenge of the Installer
The installer has enough challenges.
The desire to add features that are better served with administrative forms in the program or post install configuration steps is greatest at the beginning of a projects life. This is because everything is relatively simple at this point including the installer.
The installer program's function starts out simple enough. It needs to copy a few files. And even though the uninstall is a separate function everyone considers it part of the installer. So the installer will also need to uninstall the applications as well. But this is also fairly easy.
The challenges start when moving past this base install. Immediately one needs to consider installing on multiple operating systems. By this I do not mean only multiplatform, Linux, Unix, windows, mac and mobile. But within a platform like windows there are multiple OS options. To point out the worst offender, Vista versions have proliferated. There are more than 6 Vista options. Which does not take into account the Windows Server is a separate line and Windows XP is still another option. The Mac platform is not as bad but it still has multiple versions with compatibility challenges. And arguably Unix lost it's grip on IT precisely because of all of the 'flavors' of Unix. Linux was seen as unifying these flavors but that had it's own challenges.
Beyond the OS difference there are multiple platform challenges. Internet browser lead the list of problems. Internet Explorers market share continues to erode with Firefox taking up most but not all the gain. On the one hand a duopoly may not seem bad, but these are two very different browsers. Another emerging platform feature challenge is the media players involved. And in our future the cpu will matter much more than it does know. We should be worrying about 64 vs 32 bit but modern IDEs do a good job of hiding this difficulty from us. This is not the end of the story, it will pop up later. The multicore future may add some complexity as well.
So far we are still pretty good. Perhaps it is not until we need to save state that things get difficult. There are always some configuration options that need to be persisted and this probably would not be much of a challenge until considering the upgrade path. Initially, the installer just installed and uninstalled. But with an upgrade you want some items like configuration or licensing to survive the install.
Frameworks like Java and Dot Net have radically simplified the development process but the install pays a small fee for that ease. Either the installer has to install the framework, make the framework available for install or check for the existence of the framework.
A similar story holds for third party and for lack of a better term second party applications. Databases are common third party application. Second party applications are other applications that your company or strategic partners want to distribute with your application. On the surface it might seem that these should be the easiest of all since you have some influence on these applications. The reality is that whatever you gain from this closeness you lose do to these application changing more rapidly and they are almost always more buggy than long standing third party apps.
I will leave it there. There is more but this should be enough to scare you into working on the installer first and always keeping the installer up to date.
The desire to add features that are better served with administrative forms in the program or post install configuration steps is greatest at the beginning of a projects life. This is because everything is relatively simple at this point including the installer.
The installer program's function starts out simple enough. It needs to copy a few files. And even though the uninstall is a separate function everyone considers it part of the installer. So the installer will also need to uninstall the applications as well. But this is also fairly easy.
The challenges start when moving past this base install. Immediately one needs to consider installing on multiple operating systems. By this I do not mean only multiplatform, Linux, Unix, windows, mac and mobile. But within a platform like windows there are multiple OS options. To point out the worst offender, Vista versions have proliferated. There are more than 6 Vista options. Which does not take into account the Windows Server is a separate line and Windows XP is still another option. The Mac platform is not as bad but it still has multiple versions with compatibility challenges. And arguably Unix lost it's grip on IT precisely because of all of the 'flavors' of Unix. Linux was seen as unifying these flavors but that had it's own challenges.
Beyond the OS difference there are multiple platform challenges. Internet browser lead the list of problems. Internet Explorers market share continues to erode with Firefox taking up most but not all the gain. On the one hand a duopoly may not seem bad, but these are two very different browsers. Another emerging platform feature challenge is the media players involved. And in our future the cpu will matter much more than it does know. We should be worrying about 64 vs 32 bit but modern IDEs do a good job of hiding this difficulty from us. This is not the end of the story, it will pop up later. The multicore future may add some complexity as well.
So far we are still pretty good. Perhaps it is not until we need to save state that things get difficult. There are always some configuration options that need to be persisted and this probably would not be much of a challenge until considering the upgrade path. Initially, the installer just installed and uninstalled. But with an upgrade you want some items like configuration or licensing to survive the install.
Frameworks like Java and Dot Net have radically simplified the development process but the install pays a small fee for that ease. Either the installer has to install the framework, make the framework available for install or check for the existence of the framework.
A similar story holds for third party and for lack of a better term second party applications. Databases are common third party application. Second party applications are other applications that your company or strategic partners want to distribute with your application. On the surface it might seem that these should be the easiest of all since you have some influence on these applications. The reality is that whatever you gain from this closeness you lose do to these application changing more rapidly and they are almost always more buggy than long standing third party apps.
I will leave it there. There is more but this should be enough to scare you into working on the installer first and always keeping the installer up to date.
Subscribe to:
Posts (Atom)