0 reply content:
1. Adhere to the Wheaton rules
The central idea of the Wheaton law is "Don't be a dick", which means not to be a person regardless of others' feelings. Here, what I want to say is that you must be patient with yourOpen SourceProject user.
2. Do not be afraid to say "no", "Please submit for test", and "Please fix {X }".
3. select partners wisely
If your project has grown to the point where partners are needed, consider allowing other developers to serve as co-owners or maintainers of the project. The premise is that you have to choose these people wisely.
4. Write the guiding text
Every open-source project has three things that are indispensable: a brief description of the project's objectives and methods, how to participate and authorize permissions. We 'd better put them in advanceREADME.
5. Technical Community
It is very difficult for a person to finish everything, especially many people expect you to come up with good works.
Seize any opportunity to find a pull request. The power of brainstorming is infinite, so whenever and wherever I am, I will seek advice from members of the technical community. I have never heard of the RFC they often say, sometimes they will take the initiative to study front-end topics.
Project can be easily upgraded
With bug fixes and some functional improvements in the project, you need to release another version. Note that:
1. Backward compatibility
Do not allow users to rewrite a large amount of code because of backward compatibility. This will make users angry and abandon your project. Of course, you do not have to be as compatible with products 15 years ago as OpenJDK does.
2. Update logs
There is a clear and clear Update log that needs to include: What changes have taken place in this version? Will the code of your existing project be damaged? And so on. For example, Twitter's practice:
- Every time a bug is fixed, a brief entry is written in the Update log.
- Each time you add a function, you can briefly describe it and attach some sample code.
- Every time an API is changed, it must be explicitly stated in bold in the log
If you have multiple branches, you need to write an Update log for each branch.
3. Version labels
Add a tag for each version of your project, such as v1.0.0-alpha1, v1.0.0, and v1.1.2, so that your users can clearly distinguish the version of the project.
4. publish an announcement
After the project is released, you need to write a blog post for this event, or directly publish the announcement to the project's email list.
In the announcement, you need to describe how this project is used, whether it is backward compatible, and provide a link to the Update log.
5. Project Status tag
Some projects have been using the same version number for a long time, such as 1.1.0, while projects have been improving. If this is a development version, you also need to use tags to describe the development phase of the project. For example:
- 1.1.0.pre1
- 1.1.0-alpha1
- 1.1.0-SNAPSHOT
In short, make sure that the project has a strict version Naming Plan.
4. Use GitHub
On GitHub, you can easily do the following:
- Publish your project
- Browse and search code
- Focus on the issues project
- Participate in contribution and merge user contribution
5. ensure there is a place to provide support for users
If your project reaches a certain level of popularity, you will continue to receive questions from users. You need a place to collect and answer users' questions, such as forums and email lists. As long as there is a place for communication, users can also help each other. Over time, a very good community will be formed.
Vi. Project Transfer
This is not ruled out-you may lose interest in project maintenance, or you will not use the current project any more after you change to a new job. You can publish it on the email list so that other developers can take over your project. Transferring project ownership on Github is easier, especially after someone else introduces new features to your project.
In any case, do not let the project die.
VII. Summary
In short, when you plan to release open-source products, make sure that they include:
- Clear dependency/installation instructions
- At least one brief document/Guide
- The library contains the change log and related labels.
- Some information about Supported languages, runtime environments, tool versions, and project maturity
- Email list for users to ask questions and help each other
8. Last
In short, to make your open-source project "flourish", we should first make it more user-friendly. Except for project documents, other things will not take long. I would like to give a thumbs up first, and the subject seems to have a strong demeanor.
After reading it, the abstraction level is too low and too many interfaces are exposed,
Suggestion 1: Change the demo on the homepage to policy developers rather than transaction channel developers. The target audience is very important.
Suggestion 2: The futures ctp is enough for the time being, which is very common to many people.
However, the lts on the stock end is too small, and Huabao is too small to form a big climate (objective discussion). More stock brokers need to be developed, so that the infrastructure can attract more people.
Stay tuned and find a chance to submit code! What do you think:
- It is better to use Github, and the audience will be wider (Scientific Internet access is not a problem for programmers ). It is best to prepare documents in Chinese and English. In this way, there are more audiences.
- The link to the document in README is not limited to the github wiki. If the document is well written, developers will be interested and users will enjoy it.
- Open source itself has no utilitarian nature, and the open source community does not require you to direct others to do things.
- Most of the cases are as follows: Some people may find your project nice on Github, but they may feel uncomfortable and want to write code. Then there will basically be one fork, and the pull request will be initiated after the commit, or no pull request will be sent ..
- In this way, we gradually accumulate core members who contribute code for a long time. Instead of calling a bunch of people online. You say his core is that he does not write code, and at most it is a kind of friendship support.
I feel that the task assignment mode is not good. If there is no reward, I feel that if someone jumps the ticket (after all, there is no guarantee that his code style is good and the comments are complete), it is easy to get stuck; in addition, the quality of the Code cannot be guaranteed.
Like community or news letter, or some fixed maintenance personnel,
The Code hosting platform is definitely needed, but the open platform doesn't feel very meaningful. After all, it's not something that the public is playing. In open platforms, permission is a very troublesome thing. After all, if anyone can change the code, it may be messy. Unless you get a lot of branch and then spend a lot of time on merge...
Personal feeling: The best way is to do a good job of the underlying framework first, and then use components on the upper layer. you can do some small components or update some small components, this development mode may be better. Follow. There is only one problem. Quantitative transactions impose demanding requirements on latency. Even for low-frequency transactions, it is important to believe that hedging is important. It is a direct loss to hedge against the lack of legs or slide points. I am afraid it is too narrow to limit it to a single side. For policy development, read the important thing three times: Focus on the Back-to-test engine.
Is the simulated transaction price dependent on the quote or bar in the next second? Or trade? At that time, the liquidity kept up? Do you want to set random slide points? What is the worst price? To be honest, I feel like I have never written anything .. It encapsulates two dispatch APIs ..
In addition, quantification is originally intended for anti-open source. In the end, it makes no practical sense to make these things, that is, to play with yourself.
It is better to learn AQR to write a rough but flexible database like pandas. I personally feel that it is still good to use python to study and construct strategies. As for transactions, high-frequency transactions may be available in scala, but there are many places where real-time requirements are not high, the python transaction platform is a good choice. In fact, ib also has python interfaces.
However, in terms of positioning, you can create a good interface. The transaction system on the GUI is too heavy. Maybe an open-source project is dedicated to this? As a newbie, I would like to raise a question: Does Huabao securities API only support Windows platforms? What Should Mac users do. You can use the Q & A community for knowledge management and wecenter for in-depth customization:
Example:
Http://elasticsearch.cn
Http://dockerone.io
