This talk concerns an unusual kind of team. Jiang Haoqun had worked full time in open source since 2018. At the time, his company had very few full-time employees, while its projects involved part-time and volunteer contributors from many countries. His experience combined employment and an open community; it was not a model of every remote company’s policies.
At the start of the recording, Jiang said he had been with Vue Technology LLC for about four years. The company then had only two full-time members, including its founder, but the wider collaboration network had dozens of people across time zones. A meeting might include employees and volunteer maintainers. Assigning work, finding a time, and confirming responsibility could not simply follow a one-office company’s routine.
The recording was published on March 8, 2023; the event date has not been confirmed. Team size, tools, revenue, and contract arrangements below reflect that period.
From a job post to long-term toolchain maintenance
Jiang found a recruiting article in the community and applied because full-time remote open-source work seemed to fit him. After resume screening and interviews, he joined. He had used Vue in projects but had not made a code contribution to it before getting the job. “Try applying; there is little to lose” was his thinking at the time.
As one of the company’s earliest employees, he helped work out procedures over several years rather than receiving a complete remote-work manual on day one. His role stayed that of an individual contributor, not a manager. This route into employment differs from becoming a core maintainer through repeated voluntary code contributions, another path discussed in the audience questions.
The job itself changed. Initially he implemented specific features listed in the recruiting material. Later, toolchain maintenance took more of his time. The work can be repetitive and involve substantial communication, yet needs sustained full-time attention. Outside participants seeing only GitHub discussions might not know he was an employee.
The job post had also looked demanding. Jiang was not able to handle every listed responsibility without help when he joined; he received mentoring. Some proposed features became smaller, used another implementation, or were dropped when a better solution appeared. A reasonably matched applicant should not assume the posting describes every skill they must have mastered on the first morning.
English is first a way to make the problem clear
A worldwide team needs basic English reading and writing, but much of its work happens in asynchronous text. Jiang valued the willingness and ability to communicate and to use language tools. Joining an all-English environment revealed gaps even in skills he had expected to be sufficient. Writing a GitHub reply could take him a long time at first.
The technical point still had to be clear in his own mind. He could outline it in the language most comfortable to him, then refine the English. Repeated real discussions gradually made common words and structures familiar. He did not say a newcomer must deliver an effortless English speech from day one.
He had paid for Grammarly to catch grammar and wording issues after writing a draft. Translation tools and the emerging AI writing tools mentioned in the recording could also shape a formal email. They can improve expression, but the sender must still know the central point and judge the technical facts. These were his tools at the time, not a current accuracy assessment of each product.
A live meeting requires different preparation. With an agenda available beforehand, Jiang could write the problem, the decision he wanted, and likely follow-up questions. A full script was an option when spontaneous English was difficult. He emphasized listening, because prepared words cannot cover another person’s immediate response. In his experience, being willing to speak mattered more than making every sentence flawless.
Flexible hours do not automatically mean fewer hours
The team discussed whether planned tasks were finished rather than treating visible online time as the primary measure. Jiang still worked about forty hours a week. He credited the work-life balance he enjoyed more to company culture than to remote work by itself.
At first, the global flow of messages made it hard to stop. His evening was a colleague’s morning. A technical discussion appeared on his phone, someone mentioned him, and he opened his computer again to inspect code. The extra work was not necessarily ordered by the company; he lacked a boundary.
In the next stage he learned to take advantage of daytime freedom for a checkup, a hospital visit, or an administrative errand. Yet his weekly task did not shrink. He would make up the time at night, and with no shared stopping time around him could keep working very late. The unstable rhythm made cooperation harder for others as well and risked burnout.
His later solution was to align the main work period roughly with his family’s ordinary workday, preserving flexibility without losing a point at which to stop. Location needed equal care. In his own experience, a day of distracted work at home sometimes produced less than several concentrated hours in a quiet cafe or shared office. Remote work still benefits from a reliable workplace; that workplace simply need not be the employer’s building. The home-versus-cafe comparison was his personal impression, not a universal productivity measure, and the travel concerns of the pandemic belong to that time.
Bring a subject and a proposal to asynchronous discussion
Across cities and time zones, one message and the next reply may be hours apart. Jiang asked contributors to give a discussion a clear subject and bring their own idea. In an office, several quick spoken questions can fill in missing context. A remote “how should this be done?” can cost half a day before anyone learns what “this” means.
A better opening includes the goal, current approach, where it fails, and a proposed next step. A colleague can then begin working on the same question when they come online instead of using several turns to discover the background.
The team initially discussed concrete work around GitHub issues and used Slack threads. GitHub Discussions later supported broader forum-like topics, while the team moved to Discord for threaded discussion, open participation, and its costs at the time. Issues preserve a linear record of one problem but become harder to read when a design issue branches into several subtopics. A forum or thread lets contributors follow one branch without interrupting ordinary chat. When everyone is online, direct messages work; for a deeper or asynchronous topic, a dedicated thread preserves context. Tool prices and features may change, but the structure of a discussion still matters.
Give progress, decisions, and social connection different spaces
Many collaborators were not full time, so the group met by video about once every two weeks. Originally, the meeting was a progress update. Jiang found that reading two-week-old reports aloud added little when GitHub already held the record. It also gave participants little reason to engage.
Progress could be written. The rare shared meeting was more valuable for a new feature design, a difficult bug, or a decision requiring several people. A separate co-working session addressed the lack of casual proximity: people chose a common time, turned on cameras, worked on their own open-source or other tasks, and chatted occasionally. It recreated some of the feeling of sharing an office without pretending to be a formal decision meeting.
Finding meeting times had its own tools. For a group of perhaps ten or more, Doodle collected available periods in each person’s local time zone; the team chose a slot with the most participants. Calendly helped Jiang arrange smaller one-to-one or external conversations. Daylight-saving changes could require a new shared time. Even with these tools, his meetings often landed at 9 or 10 p.m. in China and sometimes at 11. Software removes repeated scheduling messages; it cannot create overlap between distant time zones.
The host asked whose time took priority when colleagues’ preferences conflicted. Jiang said family circumstances mattered too: in one case the schedule worked around a colleague’s children, rather than treating formal seniority as the rule.
Life choices and team relationships
Remote work let Jiang live in his hometown and spend time with family. He did not claim that was the one best lifestyle. Friends with ordinary office schedules in a larger city could have more varied leisure and social activities. He attributed part of his balance to employer culture as well as location. The useful comparison is the life a person wants, not the word “remote” alone.
Asked how a distributed team builds personal connection, he said occasional face-to-face meetings and conferences can help when possible. The small amount of in-person contact in the preceding years reflected their circumstances then, not a permanent rule against meeting.
Audience questions: entering open source and sustaining a team
Where can a newcomer contribute? Jiang named more than code. Translate or improve documents, answer an issue, or help a user when core maintainers cannot respond quickly. Someone who has already solved a particular problem can offer value even before modifying the core. He separated finding a way to help from continuing to help. Teams see talented contributors who appear only once; repeated reliable work makes it possible to judge someone as a prospective maintainer. Months of participation may attract notice, but there is no fixed probation period or hiring promise.
Did he have to contribute deeply to Vue before his job? No. He had built with it, but had not submitted code to the project. Applying for a paid full-time role and joining a maintainer group through community contributions are distinct routes.
How did the project earn revenue? According to his account at the time, Vue relied mainly on community donations, with website advertising and a small amount of cooperation with community partners. That described one project’s revenue mix then, not an economic formula for all open source.
Did age matter, and how was someone invited into the team? Jiang said he did not normally know a contributor’s age before observing their technical discussion. He described a university student who contributed code frequently enough that members noticed his ability and commitment. A member could nominate the contributor, discuss it with the others, and invite them. There was no fixed number of months. The example shows how public work and continued delivery can substitute for some personal acquaintance; it cannot prove the remote industry has no age barriers.
What about contracts, payment, and tax? The final questions concerned Jiang’s cross-border working arrangement, a different model involving an employer-of-record company in China, and his experience declaring foreign income. He said legal relationships vary by person. His contract and declaration were a historical individual practice. Actual arrangements depend on the place, contract, and rules in force when they are made.