Good programmers know how to write code. Great programmers know when to reuse and when to rewrite code.
Eric explains this using Linux' example of initially using Minix code base to start with. Over time, as Linux evolved the Minix code base got completely rewritten or thrown away. The initial use of code written by someone else helped in letting Linux develop from a nascent stage to a fully matured operating system.
Usually the first solution to any problem isn't perfect. Its only after implementing the solution, you realize there is a better way! That's when you should be ready to throw away what you just built and start over.
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
If you have users, you've built it right. Users and Products grow together. Users should be groomed to become co-developers. Products become famous, when their user base continuously grows and those users contribute back e.g. Linux, GNU, Kodi, Gimp, etc.
Release early. Release often.
On most software projects, an exclusive group works on developing for months and then decides to release a stable version for its users and then the group goes back into the cycle. Open source projects, reveal their code tree, check-ins are public, anyone can contribute though the contributions are reviewed before being accepted and merged, releases are daily/weekly/etc.
When users can contribute, their contributions merged, releases made frequently the end result is a motivated group of co-developers who are willing to pick up the latest build, find bugs, develop new features and give back to the community.
In the bazaar model, one person identifies a bug, another person understands it, a third person fixes it and so on... As a large number of eyeballs focus on the code base, the time gap between identifying and fixing a bug reduces. Overall product quality and acceptance increases.
Compared to the cathedral development model, an internal team of specialists is dedicated to find issues and iron them out which leads to longer release cycles, and at the end of every cycle its assumed that all possible bugs have been identified and removed. If a severe bug is found post-release it leads to considerable disappointment and a large effort in rolling back or fixing.
The bazaar model doesn't have big releases and thus avoids the post-release dilemmas. The specialists in the bazaar model are self selected, motivated to use and improve the product, intellectually capable to solve problems and generous in contributing their solutions. These qualities lead to solutions, designs and products that match with what can be built by specialists working in a closed organizational environment.
When many co-developers pick up the latest release, test it in different scenario's and analyze the same bug - they are bound to come up with one ore more solutions, some of them may think of the same solution or there may be overlaps. One individual may find the problem challenging whereas another may find it trivial - the level of perceived complexity varies based on the level of experience and sophistication of the individual.
Its not whether you've got the right answer, its whether you're asking the right question.
After developing a solution and refining it to a point where it seems perfect, the question to ask yourself is whether there is a different way to define the problem and would this solution still be valid when the problem is redefined?
Products mature, features get added, make the solution more powerful and then comes a time when the problem needs to be looked at with a different perspective. Powerful word processing desktop applications evolved and then simple cloud based apps replaced them, since users no longer wrote documents and printed them, instead they now needed to share and collaborate.
When the design becomes simple, code becomes better, complexity reduces - that's when you know you are on the right path. Perfection is achieved not when there is nothing more to add, but when there is nothing more to take away.
One way to recognize if you've hit a point where the product doesn't need additional features but needs a shakeup - is when your customers stop upgrading, are satisfied with the current state.
A great tool lends itself to uses you never expected.
If you develop a tool that works as expected, then that is a good tool. If it starts being used in ways you din't anticipate, it becomes a great tool. All scientific discoveries fall in this category for e.g. radio waves were initially thought to be some sort of radiation, till someone discovered their uses. The same applies to Linux, it evolved into a useful tool for scientific community, students, home use, servers, mobile phones, drones, etc.
Preconditions for a Bazaar Project
Bazaar projects don't start of with a sophisticated design and large number of features, rather all they have is a reasonable design, a stable implementation and a clever idea that attracts others to contribute. The people who have been credited with starting successful open source projects were/are not great developers, instead they are smart enough to identify a great idea and convert it into a project which can be built on top of. Consider the Linux OS, it borrowed the code base of Minix, which was an original idea by Andy Tanenbaum who din't have the foresight to see it as a successful open source project. Linus took Minix and started off with a stable release for Linux, captured the imagination of others which led them to follow and contribute.
Eric explains this using Linux' example of initially using Minix code base to start with. Over time, as Linux evolved the Minix code base got completely rewritten or thrown away. The initial use of code written by someone else helped in letting Linux develop from a nascent stage to a fully matured operating system.
Usually the first solution to any problem isn't perfect. Its only after implementing the solution, you realize there is a better way! That's when you should be ready to throw away what you just built and start over.
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
If you have users, you've built it right. Users and Products grow together. Users should be groomed to become co-developers. Products become famous, when their user base continuously grows and those users contribute back e.g. Linux, GNU, Kodi, Gimp, etc.
Release early. Release often.
On most software projects, an exclusive group works on developing for months and then decides to release a stable version for its users and then the group goes back into the cycle. Open source projects, reveal their code tree, check-ins are public, anyone can contribute though the contributions are reviewed before being accepted and merged, releases are daily/weekly/etc.
When users can contribute, their contributions merged, releases made frequently the end result is a motivated group of co-developers who are willing to pick up the latest build, find bugs, develop new features and give back to the community.
In the bazaar model, one person identifies a bug, another person understands it, a third person fixes it and so on... As a large number of eyeballs focus on the code base, the time gap between identifying and fixing a bug reduces. Overall product quality and acceptance increases.
Compared to the cathedral development model, an internal team of specialists is dedicated to find issues and iron them out which leads to longer release cycles, and at the end of every cycle its assumed that all possible bugs have been identified and removed. If a severe bug is found post-release it leads to considerable disappointment and a large effort in rolling back or fixing.
The bazaar model doesn't have big releases and thus avoids the post-release dilemmas. The specialists in the bazaar model are self selected, motivated to use and improve the product, intellectually capable to solve problems and generous in contributing their solutions. These qualities lead to solutions, designs and products that match with what can be built by specialists working in a closed organizational environment.
When many co-developers pick up the latest release, test it in different scenario's and analyze the same bug - they are bound to come up with one ore more solutions, some of them may think of the same solution or there may be overlaps. One individual may find the problem challenging whereas another may find it trivial - the level of perceived complexity varies based on the level of experience and sophistication of the individual.
Its not whether you've got the right answer, its whether you're asking the right question.
After developing a solution and refining it to a point where it seems perfect, the question to ask yourself is whether there is a different way to define the problem and would this solution still be valid when the problem is redefined?
Products mature, features get added, make the solution more powerful and then comes a time when the problem needs to be looked at with a different perspective. Powerful word processing desktop applications evolved and then simple cloud based apps replaced them, since users no longer wrote documents and printed them, instead they now needed to share and collaborate.
When the design becomes simple, code becomes better, complexity reduces - that's when you know you are on the right path. Perfection is achieved not when there is nothing more to add, but when there is nothing more to take away.
One way to recognize if you've hit a point where the product doesn't need additional features but needs a shakeup - is when your customers stop upgrading, are satisfied with the current state.
A great tool lends itself to uses you never expected.
If you develop a tool that works as expected, then that is a good tool. If it starts being used in ways you din't anticipate, it becomes a great tool. All scientific discoveries fall in this category for e.g. radio waves were initially thought to be some sort of radiation, till someone discovered their uses. The same applies to Linux, it evolved into a useful tool for scientific community, students, home use, servers, mobile phones, drones, etc.
Preconditions for a Bazaar Project
Bazaar projects don't start of with a sophisticated design and large number of features, rather all they have is a reasonable design, a stable implementation and a clever idea that attracts others to contribute. The people who have been credited with starting successful open source projects were/are not great developers, instead they are smart enough to identify a great idea and convert it into a project which can be built on top of. Consider the Linux OS, it borrowed the code base of Minix, which was an original idea by Andy Tanenbaum who din't have the foresight to see it as a successful open source project. Linus took Minix and started off with a stable release for Linux, captured the imagination of others which led them to follow and contribute.
