How to popularize Linux (or any hypothetical foss os) ?
Posted 06-21-2010 at 01:04 PM by entz
Tags adoption, foss, linux, mainstream, popularize
After pondering , debating with great passion the issue of linux and why it doesn't achieve mainstream adoption , i personally came to the following points that would if adhered to increase the odds of popular success.
The Manifest:
cheers
The Manifest:
Quote:
1) User Friendliness should be an essential and integral part of any desktop system, which its achievement has no ramifications or negative impact on stability, power , flexibility as well as security.
2) The development process in general should focus on a primary line of release in order to avoid developer fragmentation and user confusion and must constantly orient itself by the needs of the ever growing user base, under no circumstances shall the developers cater to a certain sub-culture of users at the expense of another.
3) The deployment of binary backwards compatibility layers , to allow processing of legacy code such as windows apps.
4) developers or the developing entity(ies) should adopt a "CAN Do" , "Whatever It Takes" and a "Goal justifies the Method" approach.
for instance , if at any given situation it turns out that the current kernel can no longer be efficiently maintained then it should be decommissioned for the better good of the system.
another example, if the only cost and resource efficient method to implement proprietary components such as a binary backward compatibility layer is to reverse engineer closed source binaries , then so be it!
5) The promotion and favoritism of open source standards and technologies , unless proprietary counterparts are more advanced in which case , a reverse engineered open source version needs to be provided.
in all situations , it's encouraged to support as many standards (except obsolete once) as much as possible to ensure inter-operability and to avoid discriminating against user preferences.
6) Follow the golden concepts of Modularity , Code Encapsulation and the motto "re-use the code" (unless it's buggy code) and extend them to system design , implementation of standards and wherever applicable.
The bottomline is , Do NOT write/author/release a function/module twice!
7) Be extra careful to NOT fork the line of release into separate inter-competing releases , instead learn from the dilemma of the 200 linux distros/forks and take heed !!
however the one and only exception to that, are secondary lines of release which serve SPECIAL OPERATIONS and FUNCTIONALITY that are not or can't be covered by the primary line of release , that would include server solutions , mobile device systems , real-time systems ..etc
the rule of thumb , forking the line of release is acceptable when the fork does NOT violate rule #6 .
2) The development process in general should focus on a primary line of release in order to avoid developer fragmentation and user confusion and must constantly orient itself by the needs of the ever growing user base, under no circumstances shall the developers cater to a certain sub-culture of users at the expense of another.
3) The deployment of binary backwards compatibility layers , to allow processing of legacy code such as windows apps.
4) developers or the developing entity(ies) should adopt a "CAN Do" , "Whatever It Takes" and a "Goal justifies the Method" approach.
for instance , if at any given situation it turns out that the current kernel can no longer be efficiently maintained then it should be decommissioned for the better good of the system.
another example, if the only cost and resource efficient method to implement proprietary components such as a binary backward compatibility layer is to reverse engineer closed source binaries , then so be it!
5) The promotion and favoritism of open source standards and technologies , unless proprietary counterparts are more advanced in which case , a reverse engineered open source version needs to be provided.
in all situations , it's encouraged to support as many standards (except obsolete once) as much as possible to ensure inter-operability and to avoid discriminating against user preferences.
6) Follow the golden concepts of Modularity , Code Encapsulation and the motto "re-use the code" (unless it's buggy code) and extend them to system design , implementation of standards and wherever applicable.
The bottomline is , Do NOT write/author/release a function/module twice!
7) Be extra careful to NOT fork the line of release into separate inter-competing releases , instead learn from the dilemma of the 200 linux distros/forks and take heed !!
however the one and only exception to that, are secondary lines of release which serve SPECIAL OPERATIONS and FUNCTIONALITY that are not or can't be covered by the primary line of release , that would include server solutions , mobile device systems , real-time systems ..etc
the rule of thumb , forking the line of release is acceptable when the fork does NOT violate rule #6 .
