0. Why translate this book?
On June 16th, I had the honor to participate in the technology open day held by the Red Hat Beijing R&D Center, and met many community leaders who came to Beijing to participate in LinuxCon. Between meals, I had a lot of chats with Bex, Red Hat's Fedora coordinator. In addition to my concerns about incentives and innovation, we also talked about the business model of open source software. He recommended this book to me at that time, and encouraged me to study related topics. Localized translation of open source materials.
From contacting open source to now, apart from the publicity and legal risk analysis within my ability, as a non-technical background, I have not been able to find a solid focus. I think this translation work should be a good choice. Through my own work, I can introduce new foreign open source ideas into China and provide assistance to the vast number of domestic developers within my ability. It feels very reliable.
Although, prior to the translation, I knew the ebook was under a CC-BY-SA 4.0 license, I got in touch with the original author on Twitter, and John was very welcome to do the work and provided me with Any help possible. I hope to complete the translation of this book by the end of November. Of course, due to my limited ability, the content of the translation will inevitably have some deviations. I guess it is difficult to achieve the integrity and elegance, but I will try my best to ensure the integrity. Any questions are welcome to message me.
1. About the author
John Mark Walker is a renowned open source product, community and ecosystem expert who has built large open source communities, launched new product initiatives, and implemented collaborative work processes that have resulted in more Efficient product development processes and higher levels of innovation. We see him a lot at various open source conferences because he prefers to talk face-to-face with people doing interesting things. A recognized thought leader, he authored the seminal article "No Open Source Community" and has spoken at numerous conferences on open source community engagement and product strategy. John Mark recently created a website called OSEN (osenetwork.com), through which readers can learn more about creating products and services using open source software, such as: Code Supply Chain Efficiency, Open Source Product Management, Internal Source Code principles and the value of increasing employee open source engagement.
2. The main content of this book
The content of this book is composed of three articles by John Mark Walker in 2015. He has improved and added some content on the basis of the original three articles. It is divided into two parts and six chapters. .
The directory is as follows:
About the Author
Introduction
Part I: What is an Open Source Product?
Chapter 1: Intro to Open Source Business Models
What VC Investors Want
Shifting Business Models
Services and Support
Chapter 2: Open Core vs. Hybrid Business Models
What is a Platform?
The Open Core Approach
Open Core Advantages
Open Core Disadvantages
A Hybrid Approach
Open Source Platforms as a Product
Chapter 3: Creating a Product
Open Source: It’s About Way More than Code
Secrets to Open Source Products
Chapter 4: The Open Platform Model
Engineering Nuts and Bolts
Proprietary Add-Ons
What Actually Works
PartII: Advanced Open Source Product Management
Chapter 5: Managing the Supply Chain for Product Success
The Open Source Software Supply Chain
Role of the Software Supplier
Achieving Maximum Efciency
Chapter 6: Becoming a Supply Chain Influencer
Evaluating Supply Chains
What Not To Do
Example: Red Hat and OpenStack
Don’t Accumulate Technical Debt
Become the Supply Chain
Conclusion
3. Preface to this book
A few years ago, I never thought I would write this book. Back in 1999, when open source was just starting to take off, I realized that there would be a lot of open source software in the future, and open source software would be a way for people to work, and there would be no need for relevant experts to explain to people how to use it. , because everyone will know how to use it. Fast forward to now: open source has become ubiquitous, and along with it has fostered innovation, but it still seems necessary to explain how to do it well.
On the one hand, it is because doing the right thing is always difficult and requires constant improvement. The other is because the standards of good open source practice have also evolved over time. At one time, the act of obtaining or publishing source code on a website was considered betrayal. For a company, this behavior is insane. "Open your source code? Are you crazy?" Or, if you want to promote your radical ideas, working on free software is the perfect way to build your influence. "Hey guys, I like to use software to help people, I don't need the money at all." Many of these situations have proven to be extremely wrong, but more importantly, through these developments, we have developed an understanding of how people in teams collaborate to form for a more precise understanding.
In the past, "product" was not a good word. There are many people who believe that the creation of products can be disrupted or subverted by developing free software. They believe that distributing software for free is an anarchic act that will lead to the destruction of those software giants. Some software giants have really been weakened or destroyed in the process because they didn't take it seriously. But the idea that the product is dead is definitely wrong. While there have been major changes in the development and sale of products, the reasoning that a customer will still pay for something of value remains the same, even if he can get the source code for free . Any product can be built from source code, but a good product is not just source code. At the very least, a product is about testing, integration, packaging, risk management, manageability, technical support, and delivering a solution that meets expectations.
Over the years, open source products have been iterated over several versions. When everyone thinks that source code is equivalent to product, there is a terrible tendency to see open source projects as knockoffs of high-end products. Back then, proprietary products were considered to foster innovation, while open source projects simply replicated their functionality in a low-cost way. The first product form is a CDROM that can be used to install software, and then you can purchase additional support services. That's what Red Hat did before releasing enterprise Linux. Immediately thereafter, a series of startups were formed based on the model of offering limited versions of some high-end products for free under an open-source license, and then peddling those high-end products. Later, as more open source projects became successful, there was a new shift in selling hybrid products consisting of a core open source platform and proprietary management software based on it. Now, since many software development companies do not sell software, companies that sell open source software-based services have emerged in many industries. While there are many business models for using open source software, there are good and bad ones (discussed in detail in subsequent chapters).
The popularity of open source today has led to a variety of problems. While everyone seems to be developing some type of open source code, the ease of building software with other people's software (abuse) has led to overall clutter and lack of product guidelines. I know I sound like a pedant when I say this, but software development has become so easy that less and less developers are thinking about the origins of software and how to ensure its stability. If you are building a software product using open source components, how do you guarantee the value of the software? How do you know if it will continue to be developed? What if subsequent developers abandon the project? How do you measure the risks inherent in your product's upstream open source code, and how do you account for those risks when delivering your product to customers?
This book is for those who want to create reliable software products or services for their clients. The original intent is for products, services or solutions that are used to sell to customers, but the same applies if you use it within your own company. I think if you want to develop and sell a product, you have to make the product valuable. Hint: The source code itself has no value. A useful solution is valuable. In this sense, it doesn't matter whether your code is open source or not, because what matters is whether what you're selling actually provides value to the buyer. However, if you develop software in an open source fashion, you have many more options than proprietary software developers. If you're good at using open source software, you'll be able to deliver better and better customer-specific software more effectively, and that's what this book is about.
I just started writing in Open Source China recently, and some subsequent articles will be posted here, mainly in several directions: open source software legal risks, license compliance, business models, and collaboration models. I will also translate some foreign works. Based on the principle of being short and powerful, I will eat less and eat more meals. I hope everyone likes it, and you are welcome to make a brick. Thanks for the support
My email: [email protected]
T 信 ： DavidTung