 |
| Viking Ship (Image Credit: image-pearl.com) |
Open Source isn't really about Application Software. No, it's a philosophy. That's it.
Most think of Open Source in the context of Software Development, naturally, but it goes further than that. It is, essentially, a mindset and 'way of life'.
One can share in a cooperative fashion making contributions to a singular cause and remain compatible with Open Source. This is a human trait -- a willingness to cooperate, share, help others. Nurturing and embracing the Open Source philosophy can produce positive results on many levels.
Open Source and the Gnu Public License confer the end-user flexibility to access and make changes to the Linux codebase.
Working cooperatively in lock-step fashion in a large team of Developers requires sharing in the goals of a project and furtherance of those goals, even when there might be some disagreement with the approach taken to do a task or disagreement with agreed-to management objectives or community goals.
The current 'rift' which has developed around whether Debian should or should not incorporate middle-ware design changes promulgated by Red Hat has become a focus of discussion with consideration being given to forking the entire Debian codebase in an effort to retain control of those design changes which are pending in merging systemd into Debian.
The very idea of being able to fork a code base is a good thing. It was demonstrable when Oracle asserted their control over OpenOffice in a way which resulted in irreconcilable differences with the Open Source Community sufficiently to cause a fork to LibreOffice. It is assumed that conditions were reached where the requirements set forth by Oracle management oversight were recognized as incompatible with Open Source, the philosophy, and so we now see the end result.
The outcome in this example fortunately was a good one. It relieved an intractable situation and enabled work to continue on an otherwise viable project.
The Debian Project has taken input on the decision to switch away from aged sysvinit to systemd some time ago. It was all done with requests for public feedback to be considered in making the final choice.
I feel that choice, to switch to systemd, was a good one given systemd's recognized 'net' technical merits.
Yet, today, we see splinter groups who for their own reasons, some which may be valid and some which may not be valid, wish to fork Debian.
What will the unforeseen 'unintended consequences' of taking such action be?
In my estimation, it will put a 'cloud' over Debian, for one, and produce increased end-user confusion with 'mixed messages' implied as to what is 'good verses bad' design. A fork of Debian is divisive and will so cause an 'us verses them' environment, hostility, isolation, continued disagreement and is not conducive to cooperation and compatible with the Open Source philosophy.
The Vikings learned to build ships with arrays of oars wherein men would cooperate to function in a collective purpose moving their oars in the water in unison to a drum beat, thereby moving the vessel efficiently and speedily like no other.
It was effective. It was necessarily cooperative or it would not work. Ignoring the drum beat would cause the ship to founder and not be propelled forward.
Having yet another fork of Linux is arguably good and bad. It moves manpower away from one project to another.
Forking dilutes the effectiveness of staying to a singular purpose, a singular api, and introduces more variation which makes achieving standards all the more difficult.
It is because Microsoft Windows and Apple OSX are singular apis that a thriving ecosystem was born. Out of singularity standardization developed, de facto and otherwise. There was less confusion as all parties involved know the API is singular and coding applications is vastly simplified.
In terms of commercial involvement, such considerations matter greatly. Cost for one is reduced when it is known in advance that software behaves one and only one way and so administrative controls can be put in place to promote stability. Enterprise craves stability. Systems must run uninterrupted. Any perceived inconsistencies regarding one particular operating system, Linux, will be viewed as 'weaknesses' and that is to be expected. No CIO wants to have multiple APIs and their attendant complexities to support. It is at minimum, inefficient and less than stable and less than cost-effective.
Thus, I feel, while forking is important, and Debian 'purists' have the best of intentions, the end result of such a fork will result in a general decline in the use of Debian regardless of which middle-ware is utilitzed.
It is because of this forking, cloning with Distro-sprawl that I reached the conclusion that sticking with ONE Distro was crucial to the overall success of Linux on the Desktop and in the Data Center. With that said, I chose Fedora by virtue of its Red Hat guidance and breadth of community involvement.
So, just because one can fork, clone, by virtue of the GPLv2 licensing terms, doesn't mean one should. While it made sense to fork OpenOffice.org, it does not with Debian and will be harmful.
Restraint and adherence to one API is vital to moving Linux into the realm of mass adoption. -- Dietrich
.png){kind=logo}
