Management and Virtual Decentralised Networks: The Linux Project - 0 views
-
A mechanistic management system is appropriate to stable conditions. It is characterised by:The Organismic form is appropriate to changing conditions. It is characterised by: Hierarchic structure of control, authority and communicationNetwork structure of control A reinforcement of the hierarchic structure by the location of knowledge of actualities exclusively at the top of the hierarchyOmniscience no longer imputed to the head of the concern; knowledge may be located anywhere in the network; the location becoming the centre of authority Vertical interaction between the members of the concern, ie. between superior and subordinateLateral rather than vertical direction of communication through the organisation A content of communication which consists of information and advice rather than instructions and decisions
-
chelfyn Baxter on 10 Apr 07This is very similar to many Web 1.0/2.0 analogies
-
-
Structurehierarchicalnetworked Scopeinternal/closedexternal/open Resource focuscapitalhuman, information Statestabledynamic, changing Directionmanagement commandsself-management Basis of actioncontrolempowerment to act Basis for compensationposition in hierarchycompetency level
-
However, "the Linux movement did not and still does not have a formal hierarchy whereby important tasks can be handled out ... a kind of self-selection takes place instead: anyone who cares enough about a particular program is welcomed to try" [54]. But if his work is not good enough, another hacker will immediately fill the gap. In this way, this 'self-selection' ensures that the work done is of superb quality. Moreover this "decentralisation leads to more efficient allocation of resources (programmers' time and work) because each developer is free to work on any particular program of his choice as his skills, experience and interest best dictate" (Kuwabara, 2000). In contrast, "under centralised mode of software development, people are assigned to tasks out of economic considerations and might end up spending time on a feature that the marketing department has decided is vital to their ad campaign, but that no actual users care about" [55].
- ...4 more annotations...
-
Industrial AgeInformation Age Focus on measurable outcomesFocus on strategic issues using participation and empowerment Individual accountabilityTeam accountability Clearly differentiated-segmented organisational roles, positions and responsibilitiesMatrix arrangement - flexible positions and responsibilities Hierarchical, linear information flowsMultiple interface, 'boundaryless' information networking Initiatives for improvement emanate from a management eliteInitiatives for improvement emanate from all directions
-
-
There is only one layer between the community of Linux developers and Linus: the "trusted lieutenants". They are a dozen hackers that have done considerably extended work on a particular part of the kernel to gain Linus' trust. The "trusted lieutenants" are responsible to maintain a part of the Linux Kernel and lots of developers sent their patches (their code) directly to them, instead of Linus. Of course, apart from Linus that has encouraged this to happen, this informal mechanism represents a natural selection by the community since the "trusted lieutenants" are recognised [by the community] as being not owners but simple experts in particular areas [57] and thus, their 'authority' can always be openly challenged. This does not mean that Linus has more influence than they have. Recently, "Alan Cox (one of the "trusted" ones) disagreed with Linus over some obscure technical issue and it looks like the community really does get to judge by backing Alan and making Linus to acknowledge that he made a bad choice" [58].
-
In 1991, Linus Torvalds made a free Unix-like kernel (a core part of the operating system) available on the Internet and invited all hackers interested to participate. Within the next two months, the first version 1.0 of Linux was released. From that point, tens of thousands of developers, dispersed globally and communicating via the Internet, contributed code, so that early in 1993, Linux had grown to be a stable, reliable and very powerful operating system. The Linux kernel is 'copylefted' software, patented under the GNU GPL, and thus, nobody actually owns it. But more significantly, Linux is sheltered by the Open Source (hacker) community. From its very birth, Linux as a project has mobilised an incredible number of developers offering enhancements, modifications/improvements and bug fixes without any financial incentive. Despite the fact that an operating system is supposed to be developed only by a closely-knit team to avoid rising complexity and communication costs of coordination (Brook's Law), Linux is being developed in a massive decentralised mode under no central planning, an amazing feat given that it has not evolved into chaos. Innovation release early and often: Linus put into practice an innovative and paradox model of developing software. Frequent releases and updates (several times in a week) are typical throughout the entire development period of Linux. In this way, Linus kept the community constantly stimulated by the rapid growth of the project and provided an extraordinary effective mechanism of psychologically rewarding his co-developers for their contributions that were implemented in the last version. On top of this, in every released version, there is a file attached which lists all those who have contributed (code). Credit attribution if neglected, is a cardinal sin that will breed bitterness within the community and discourage developers from further contributing to the project. According to conventional software-building wisdom, early versions are by definition buggy and you do not want to wear out the patience of your users. But as far as the Linux development stage is concerned, developers are the users themselves and this is where most innovation is created (Figure 8). "The greatest innovation of Linux is that treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging" (Raymond, 1998a).
