docs: add blog about 1k star

pull/100/head
moonrailgun 2 years ago
parent d2aa750152
commit 99c8779ffd

@ -0,0 +1,119 @@
---
title: Share how I have operated open source projects and reached 1k star in the past few years
authors: moonrailgun
image: /img/logo.svg
slug: share-1kstar
keywords:
- tailchat
tags: [Share]
---
I developed an IM project [Tailchat](https://tailchat.msgbyte.com/), and finally reached the 1k star milestone in the early morning of June 28, 2023. I am very excited. Of course, for many well-known open source projects, this only need takes a few days, but it is still very important for me. Therefore, I really want to share how I operate an open source project as an open source enthusiast.
![](/img/blog/1kstar/1.png)
![](/img/blog/1kstar/2.png)
First of all, I must admit that I am a very typical and pure programmer. I have no background, no resources, and I am not good at communication. It can be said that I am a relatively socially phobic person. For people like me, the difficulty is not how to develop an app, but how to promote my app after the development is completed or reaches a certain stage, so that everyone can understand my philosophy.
Once, I naively thought that open source was just sharing the source code so that everyone could see my code. However, I gradually realized that open source is more like a business. It not only needs to develop its own products, but also needs to find ways to sell the products.
## A good official website is very important
The official website is the facade of an application, and for many libraries, the README is their official website. However, for relatively large and complex projects, a simple README may not provide enough information, and an independent official website page becomes very important.
An excellent official website can increase users' trust in the project. Usually, my basic trust in open source projects comes from the following aspects: whether there is a README or official website, whether there are enough stars, and how much usage/download.
For example, Tailchat's official website https://tailchat.msgbyte.com/ has become quite good after a few iterations. The first screen occupies almost the entire page, and shows previews of desktop and mobile, which means that my project supports both desktop and mobile. Then succinctly list the characteristics that I think are important, and these are also the key points that I want my product to distinguish from other similar projects.
The official website is the embodiment of product thinking. Convey your ideas to users through the official website, so that users can understand your design philosophy and why you want to make such a product.
On the other hand, the official website also provides guidance for users during use. Unless your product does not require users to do anything, just open it and use it (such as various small games), a complete document will help users far beyond your imagination.
Don't think that you can stop doing these things just because the source code is open source. The code itself is the document. Recalling our own development experience, when using a library, we would not choose to view the source code unless we had to. This is true for libraries, let alone a complete project?
For open source projects, a complete and multi-platform compatible deployment method is the most basic bottom line.
## Focus on differentiation
For open source projects, the easiest way to introduce your products to others is the open source alternative of xxxx, where xxxx is generally a commercial application that you are familiar with. This can give users a very basic idea of your product very quickly. You can also quickly establish a basic concept through everyone's consensus.
For example, if you want to build an online shopping mall, then you can say that you have created a substitute for Amazon. For example, if you want to make a forum, you can say that you want to make a substitute for discuz.
However, while saying that your project is a substitute for xxxx, you need to always be clear about the differences between yourself and the other party, instead of constantly copying the functions of other projects. For example, when I introduce and promote my project with others, I will say that I am an IM, an open source alternative to discord/slack. But at the same time I will also emphasize that it is not just an IM. I will talk with the other party about why we need a plug-in system and what the plug-in system can bring us, why I spend 2 years on the underlying architecture and polishing the system to complete this architecture, and why I think my product is excellent. for other projects.
This is a very difficult thing to do. Because most users don't care about your differences. For most users, only the most basic functions are used, and users are more concerned about whether they can meet their needs. A very sad thing is that no matter what you do, you will have many peers competing with you. The reason why users decide whether to use your product is not because of how powerful your functions are, but whether your functions can meet the needs—— Of course, if you have enough functions, so many that all imaginable needs can be met. But that is what companies do. If you are an individual open source developer, you must learn to focus and focus on differentiation.
## Emphasis on the international market
Multilingualism is a very necessary thing. Although China has a huge market, let's take a longer view. The Chinese market is only 1/5 of the global market. Especially in the open source field, you as a developer don't have to care about language boundaries. Because you are not in control of the differences in laws and regulations and privacy policies in various places. As a developer, you only need to make your product well.
Therefore, it is very important to support multiple languages. Supporting at least English can greatly expand your audience. If you are not confident about your English level, please make good use of translation software.
In addition, you can go to overseas platforms to promote your application, not just limited to domestic platforms. Such as Reddit, Hackernews, medium, etc. Don't limit yourself to your own country
## Give users a sense of trust through perfect documentation and automated testing
Although a thick instruction manual will not bring any real value to the product itself, it will at least make users who pay attention to this product feel at ease.
Security is a very metaphysical thing. As a developer, you can say that your project is very easy to use and does not require any documentation at all. But even if you don't read these documents, the existence of these documents will give users a kind of trust, at least it can show that you have paid enough attention to your project.
There are similar automated test scripts, the former is for ordinary users, and the latter is for developers.
As developers, we all know the importance of CICD. CICD is an important way to ensure the code quality of a project, and it also means the bottom line of a project. If one doesn't have any CICD workflows or are all failed workflows. Then I would be very, very distrustful of it.
Open source projects naturally lack trust compared to commercial projects, because the latter are used for profit and can be used to support the operation of enterprises, which means that at least there will be no problems. And open source projects often originate from interests, which naturally give people a feeling of unreliability. Especially when the number of stars in the early stage is relatively low.
How to break this sense of distrust is also an important factor for open source maintainers to make their projects work.
## String your content together to reduce exploration costs
A very bad example is to put relevant content everywhere, making it very difficult for users to see all the content.
It is very important to have important content indexed in one place. Such as your social media, your documentation, your function manual, your demo environment, your various technical blogs....
Reduce the user's exploration cost, because if the cost is too high, the user is likely to choose to give up. That's why most sites have keywords in the footer
If you only have a README file, add all the links to the documentation so the user can clear what's there and what it's for.
Also, not just your various content, but your project itself should keep this in mind. For example, it is easy to dissuade people from registering with a mobile phone number, and a proper public content experience can better allow users to experience the charm of the product and retain it for a long time. This is what I do in Tailchat. Users can log in with a temporary account, and only need to fill in a nickname to experience the full functionality. When the user decides to keep your account for a long time, you can go through the registration process to claim the temporary account. If you want to let users join your community, you can even directly replace the entry with an invitation link.
Similarly, if your project contains multiple sub-projects. Monorepo will be a better choice than multiple warehouses. I once wrote a blog about this from a technical point of view, [talking about the benefits of merging multiple projects into one project](http://moonrailgun.com/posts/2674f04a/).
From the perspective of open source operations, multiple project repositories not only make it more difficult for users to see the whole picture, but also undermine the confidence of open source contributors, because everyone expects contributors to large projects to have their own profile pictures, even if they just change the document typo.
## Pay attention to the operation of the community and the ecology
The operation of the community is a very important part of an open source project. Only continuous feedback from the community can pull up a positive cycle of open source projects. The simplest community is to set up a reddit channel or discord group. When I was operating in the early days, I thought that since I am doing IM, why should I go to other IM platforms to operate my community? However, this is wrong, because as a developer, you should accommodate users instead of letting users accommodate you. If users prefer to use reddit, then you should choose to use reddit. If users use discord more, then you should build your own community on discord. Keeping the community active is the first element.
I really like Notion's ambassador culture and community culture. Establishing a good community-driven ecology is an essential quality for a successful open source project. Although my project is far from reaching this stage, I have studied many successful open source projects without exception. Simply put, open source is a carnival for idealists, and a good open source project is a carnival for a group of idealists. It is a very difficult thing to let users recognize your project and promote it spontaneously, but it is necessary to do it. It is much easier for a group of people to advance than one person.
On the other hand, we need to pay attention to the value of developers. What is developer value? It is what your project can bring to developers. When promoting Tailchat, I often make an analogy with vscode. vscode is a plug-in text editor. Its ontology is an expansion center + monaco editor, and its value lies in a good developer ecology. Allow different developers to realize their own ideas through vscode's plug-in system and integrate different language support. I dont know if anyone still remembers that github had its own editor atom before github was acquired by Microsoft. I also like to use it very much, atom has been deprecated since Microsoft acquired github. I believe that Microsoft also sees the great potential of the plug-in system. And Tailchat also uses the plug-in system as the underlying capability at the beginning of the design. One of my favorite sayings is: "A Product That Gets Developer Love Gets Everything". This is also the power of ecology. When the ecology is up, it will be difficult for your product to be replaced by other similar applications.
## Revisit your early adopters at the right time
It is very important to maintain seed users in the early stage. Revisit your early users in a timely manner to make your users feel that they are valued and motivated by this product. This will greatly increase the possibility of your users turning into community contributors.
Many technical people think that only code contribution is contribution. In fact, there are only a small number of people who understand the code, not to mention that there are even fewer people who need to match the technology stack of your project. If many people can make suggestions, I think it is very good for an open source project to do an international translation. up. The most important thing is that these things will be what you move forward. People want to keep moving forward either by money or interest, and the community is a gas station that continuously recharges your interest.
The early entrepreneurs I came into contact with would like to make appointments with their users to chat about the development of their projects and users' opinions. If you don't feel like you can do that, it's okay to greet with a text. Believe me, the rewards will be greater than imagined.
## Actively blog and write technical articles
I am very disgusted to promote my project by constantly and repeatedly sending the introduction of my project in various technical communities like an advertising robot. Although it seems to be a bit of a scholar's aloofness, I still feel that this kind of behavior greatly affects the experience of other people. Some people may say that it is better to be disgust than no one knows, but this is a selfish act of sacrificing other people's experience to achieve one's own.
My choice as a technical person is to write more blogs and technical documents. Promote your own projects in technical articles. I hope this should be a win-win behavior: as a reader, you gain knowledge, and as a writer, I gain exposure.
At the same time, writing articles is also a sorting out of your own ideas, which is similar to writing technical documents. I used to be very disgusted with writing technical documents, because things that can be written directly by writing code still need to write technical documents to restrain myself. Generally speaking, the time for writing technical documents is about the same as the time for writing codes, because to write a correct technical document, it is often necessary to determine the possibility of the solution. Basically, to determine the feasibility of the solution, most of the code is almost written. But now I understand the necessity of writing technical documents, more to organize my thoughts. Writing code is easy, writing code that people can understand is difficult, and writing code that people can understand and maintain later is the most difficult. I used to rely on my own experience to achieve easy maintenance in the later stage, and the technical documentation is to add a layer of CICD to constrain behavior on the basis of my reliance on experience. The same is true for writing technical articles. While writing code, you must organize things to form a methodology. This is also a kind of improvement of one's own ability.
## Summarize
Open source is bumpy in the end, and there is a high probability that there will be no actual benefits in the end. That's why I say open source is a carnival for idealists.
Open source projects often do not pursue profit and pay a lot. In addition to writing code, they also need to devote energy to publicity and operation. It is a thankless task for most people.
Of course, what I'm talking about here are real open source projects that require long-term efforts. If it is only for high star, there are actually many ways to use it for job hunting or other purposes. Many projects have only a few lines of code, but there are still many hot projects such as tens of thousands of stars on github.
On the contrary, my topic is undoubtedly the Red Sea in the Red Sea. On the C side, there were giants that occupied the market early more than ten years ago, and there are also many powerful competitors competing on the B side. Also in open source, there are countless similar products competing with each other. The reason why I still choose IM as my open source project direction, and I have worked hard for several years so far. I also believe that my design concept will stand out among a bunch of similar competitors with serious homogeneity. Of course, it is undeniable that there will be a possibility of failure. Maybe this is an idealist, and I am willing to devote my heart and soul to my ideal.
I believe that the world is often changed by idealists. Given the choice, I prefer to work with a group of idealists. I believe that you who see the end must also be a person who loves open source, encourage each other, and go on together.

@ -0,0 +1,119 @@
---
title: 分享下这几年我是如何运营开源项目并达到1k star的
authors: moonrailgun
image: /img/logo.svg
slug: share-1kstar
keywords:
- tailchat
tags: [Share]
---
我开发了一款 IM 项目 [Tailchat](https://tailchat.msgbyte.com/)终于在2023年6月28日凌晨达到了 1k star 的里程碑。我感到非常激动。当然,对于许多知名开源项目来说,这只需要几天就可以完成,但对于我来说仍然非常重要。因此,我非常想分享一下我作为一个开源爱好者是如何运营开源项目的。
![](/img/blog/1kstar/1.png)
![](/img/blog/1kstar/2.png)
首先,我必须承认我是一个非常典型且纯粹的程序员。我没有背景,没有资源,也不擅长沟通,可以说是比较社恐的人。对于像我这样的人来说,困难并不在于如何开发一款应用,而是在开发完成或者达到一定阶段后如何推广我的应用,并让大家能够理解我的理念。
曾经,我天真地认为开源只是将源代码分享出去,让大家能够看到我的代码。然而,我逐渐意识到开源更像是一个企业,不仅需要开发自己的产品,还需要想办法将产品销售出去。
## 一个好的官网非常重要
官网是一个应用的门面对于许多库来说README就是它们的官网。然而对于相对庞大、复杂的项目来说简单的README可能无法提供足够多的信息这时一个独立的官网页面就变得非常重要。
一个优秀的官网能够增加用户对项目的信任感。通常情况下我对开源项目的基本信任感来自于以下几个方面是否有README或官网、是否有足够多的star以及使用量/下载量如何。
举个例子Tailchat的官网https://tailchat.msgbyte.com/经过几次迭代后变得相当出色。首屏几乎占满整个页面,并展示了桌面端和移动端的预览图,这意味着我的项目同时支持桌面端和移动端。然后简洁明了地列出了我认为重要的特点,这些特点也是我希望我的产品与其他类似项目区分开来的关键点。
官网是产品思考的体现。通过官网向用户传达自己的想法,让用户理解你的设计哲学,明白你为什么要做出这样一个产品。
另一方面,官网也为用户在使用过程中提供指导。除非你的产品不需要用户做任何操作,只需打开即可使用(比如各种小游戏),否则一个完整的文档对用户的帮助远远超出你的想象。
不要认为只因为开源了源码就可以不去做这些事情,代码本身就是文档。回想一下自己的开发经历,在使用一个库时,除非万不得已,否则我们不会选择去查看源码。对于库来说都如此,更何况是一个完整的项目呢?
对于开源项目来说,一个完整且兼容多平台的部署方式是最基本的底线。
## 注重差异化
对于开源项目来说,向其他人介绍自己的产品的时候最简单的方式就是 xxxx 的开源替代品, 这里的 xxxx 一般是你耳熟能详的商业应用。这样可以非常快速的让用户对你的产品有一个很基本的概念。你也能通过大家的共识快速建立起一个基本的概念。
比如你想做个在线商城那么你就可以说自己做了个淘宝的替代品。比如你想做一个论坛那你可以说你是要做一个discuz的替代品。
但是,在说自己的项目是 xxxx 的替代品的同时需要时刻明确自己与对方的差异点而不是在不断复刻其他项目的功能。比如我在与其他人介绍、推广我的项目的时候我会说我是一个IM是discord/slack的开源替代品。但与此同时我也会强调不仅仅是一个IM。我会与对方谈论为什么我们需要插件系统以及插件系统可以给我们带来什么为什么我会花2年时间来做底层架构、打磨体系来完成这套架构以及为什么我觉得我的产品是优于其他的项目的。
这是一件非常困难的事情。因为大部分的用户并不会在乎你的差异。对于大部分用户来说只会用到最基本的功能,而且用户更加关注的是是否能满足自己的需求。一件非常悲伤的事情是不论做什么你都会有很多的同行与你竞争,让用户决定是否用你的产品的理由并不是因为你的功能多么强大,而在于你的功能是否能满足需求 —— 当然如果你的功能足够多,多到所有能想象到的需求都能满足也行。但是那是企业做的事情,如果你是个人开源者更要学会专注,专注于打差异化。
## 重视国际化市场
多国语言是非常必要的一件事。虽然中国有很大的市场,但是我们把目光放远一些,中国市场也不过是全球 1/5 的市场。特别是在开源领域,你作为开发者更加不必在乎语言的边界。因为你不受控于各地的法律法规隐私政策的差异。作为开发者只需要做好你的产品就行了。
因此,支持多国语言非常重要。至少支持英语,能很大程度扩展你的受众范围。如果你对自己的英语水平不够自信,请善用翻译软件。
另外,你可以多多去海外的平台宣传自己的应用,不仅仅是局限于国内的平台。如 Reddit、Hackernews、medium 等。因为海外的用户对开源的接受度、理解度更加高如果这些用户能够认可你的项目的话在开源领域会比国内用户带来的帮助更加多。一个很悲伤的事实是国内开发者天天996根本没有时间再去为开源做贡献特别是个人开源的项目。
## 通过完善的文档、自动化测试给用户带来信任感
虽然一本厚厚的说明手册并不会给产品本身带来任何的实际价值,但至少会让在这个产品上投入关注的用户感到安心。
安全感是一个很玄学的事情。作为开发者你可以说自己的项目非常简单易上手,根本不需要任何文档。但是哪怕不去看这些文档,这些文档存在的本身会给使用者一种信任,至少能表示你对自己的项目投入了足够多的关注。
类似的还有自动化的测试脚本,前者是给普通用户的,后者是给开发者的。
作为开发者我们都知道CICD的重要性。CICD是保证项目的代码质量的重要方式也意味着一个项目的底线。如果一个没有任何CICD工作流或者都是失败的工作流。那么我会非常对此非常具备不信任感。
开源项目天然的就相比商业项目是缺乏信任感的因为后者是拿来牟利的且是能够用来支持起企业的运作的意味着至少不会有什么问题。而开源项目往往起源于兴趣天然的就给人不靠谱的感觉。特别是在前期star数比较低的时候更是如此。
怎么打破这种不信任感也是作为开源的维护者想要让自己的项目起来的重要因素。
## 将你的内容串在一起,减少探索成本
一个非常不好的例子在于把相关的内容放的到处都是,让用户能看到所有的内容非常困难。
将重要的内容在一个地方被索引是非常重要的事情。比如你的社交媒体、你的文档、你的功能手册、你的演示环境、你的各种技术博客….
减少用户的探索成本,因为如果成本过高用户很有可能选择放弃。这就是为什么大多数网站都会在页脚留有各个关键
如果你仅README文件那就把所有的链接都添加到文档中让用户能够清除知道有什么内容这些内容是干什么的。
另外,不只是你的各种内容,你的项目本身也要牢记这一点。比如上来就是一个手机号注册就很容易让人劝退,而适当的公开内容体验可以更好的让用户体验到产品的魅力从而长期留存。在 Tailchat 中我是这么做的, 用户可以使用临时账号登录,只需要填入一个昵称即可体验到完整的功能。当用户决定长期保留你的账号时,你可以走注册流程认领该临时账号。如果想要让用户加入到你的社群中,你甚至可以把入口直接换成邀请链接。
类似的如果你的项目包含了多个子项目。monorepo会是比多个仓库更好的选择我曾经写了一篇博客就是从技术角度说的这个[谈论从把多项目合并成一个项目中获得的收益](http://moonrailgun.com/posts/2674f04a/) 。
从开源运营的角度来说,多个项目仓库不但更难让用户看清全貌,也会打击开源贡献者的信心,因为谁都期望大项目的贡献者上有自己头像,哪怕仅仅是改了文档的一个错别字。
## 重视社区的运营,重视生态
社区的运营是开源项目中非常重要的一环只有来自社区的不断反馈才能拉起开源项目的正循环。最简单的社区就是建立一个微信群或者discord群。我早期在运营的时候想着既然我自己是做IM的为什么要到其他的IM平台上去运营我的社区呢然而这是错误的因为作为开发者应当去迁就用户而不是让用户迁就你。如果用户更加喜欢用微信那么你就应当选择使用微信。如果用户更多使用discord那么你就应该在discord建立自己的社群。保持社群的活跃才是第一要素。
我非常喜欢Notion的大使文化与社区文化。建立良好的社区驱动的生态是一个成功的开源项目必不可少的基本素质。虽然我的项目还远远达不到这个阶段但我研究过很多成功的开源项目无一例外。简单的说开源是理想主义者的狂欢一个好的开源项目则是一群理想主义者的狂欢。让用户认可你的项目并自发的宣传这是一件非常困难的一件事但是是有必要去做的一群人前进会比一个人前进轻松很多。
另外一方面需要关注开发者价值。什么是开发者价值呢就是你的项目对开发者能够带来什么。在推广Tailchat的时候我往往会与vscode进行类比。vscode就是插件化的文本编辑器。其本体就是一个拓展中心 + monaco 编辑器其价值在于良好的开发者生态。让不同的开发者能够通过vscode的插件系统来实现自己的想法集成不同的语言支持。不知道是否还有人记得在github还没被微软收购的时候 github有一款自己的编辑器 atom。我也非常喜欢用自从微软收购了github后atom就被弃用了。我相信微软也是看到了插件系统的巨大潜力。而Tailchat也是以插件系统作为设计之初的底层能力。我很喜欢的一句话是: 得开发者得天下。这也是生态的力量,当生态起来了以后,你的产品就很难被其他同类应用替代了。
## 恰当的时候回访你的早期用户
在早期维系种子用户是非常重要的,适时的回访你的早期用户,让你的用户感受到自己被重视,这个产品的积极性,这将会大大增加你的用户转变到社区贡献者的可能性。
很多技术人会觉得,只有代码贡献才是贡献。其实了解代码的毕竟是少数,更何况要匹配你的项目的技术栈的话就更加少了,很多人如果能提提建议,打打下手做个国际化翻译我觉得对于一个开源项目来说就非常不错了。最重要的是这些东西会成为你前进的东西。人想要不断前进要么靠金钱,要么靠兴趣,而社区就是持续不断为你的兴趣充能的加油站。
在我接触到的早期创业者,都会很喜欢与自己的用户约个会,聊一下自己项目的发展以及用户的看法。如果你觉得自己做不到这一点,用文字问候一下也是可以的。相信我,收获会比想象中的更加大。
## 积极写博客,写技术文章
我很反感像广告机器人一样在各种技术社区中通过不断的、重复的发送自己项目的介绍来推广自己的项目。虽然看起来好像有点读书人的清高和不食肉糜,但是我依旧觉得这种行为是非常影响其他人的体验的。有的人可能会说,相比有人黑总比没有人知道好,但这是牺牲其他人的体验而成就自己的自私行为。
我作为技术人的选择是,多写博客,多写技术文档。在技术文章中推广自己的项目。我期望这应当是一个双赢的行为:作为读者的你收获到了知识、作为作者的我收获了曝光。
同时写文章也是对自己思路的一个整理这点和写技术文档是差不多的。曾经的我非常反感写技术文档因为直接写代码就能写完的东西还需要写技术文档来约束自己。一般来说写技术文档的时间和写代码的时间是差不多的因为要写出一个正确的技术文档往往需要确定方案的可能性基本上确定方案的可行性大部分的代码就写的差不多了。而现在我会理解写技术文档的必要性更多的是为了整理自己的思路。写代码是简单的写代码让人能够理解是困难的写了代码以后让人能够理解并且后期好维护是最难的。曾经的我是依赖自己的经验来实现后期易于维护而技术文档就是在我依赖经验的基础上追加了一层CICD来约束行为。写技术文章也是一样的在闷头写代码的同时要把东西整理出来形成方法论。这也是一种对自己能力的提升。
## 总结
开源的到底是坎坷的,而且大概率是最后没有实际收益的。这也是为什么我会说开源是理想主义者的狂欢。
开源项目往往不追求盈利,付出又多,除了写代码还要投入精力去宣传,去运营。对于大部分人来说都是一件吃力不讨好的事情。
当然我这里说的是真正的、需要长期付出的开源项目。如果仅仅是为了star高来用于求职或者其他目的的话其实有很多方式很多项目代码没几行但是star数都是几十k这样的蹭热点的项目在github上还是有不少的。
相反的我的选题无疑是红海中的红海在C端十几年前就有早早占领了市场的巨头在B端也有很多强大的竞品进行竞争。同样在开源也有无数的同类产品相互竞争。我之所以依旧选择IM作为我的开源项目方向并且为止付出了数年的努力。我也相信我的设计理念会在一堆同质化严重的同类竞品中脱颖而出当然不可否认的是会有失败的可能可能这就是理想主义者我愿意为我的理想付出心血。
我相信,世界往往是被理想主义者所改变的。如果可以选择,我更喜欢与一群理想主义者一起共事。相信看到最后的你也一定是一位热爱着开源的人,共勉,一起走下去。

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 142 KiB

Loading…
Cancel
Save