About the Speaker
Author: Alexey Milovidov, 2021-02-16.
1. Git repository hosting.
2. Project management system.
3. Social network for developers.
Level 0: archival and museum code.
Source code is publicly available under one of the open-source
or «source-available» licenses.
Product development is not expected.
Community participation is not required.
Examples:
— id-Software/DOOM;
— microsoft/MS-DOS;
— vk-com/kphp-kdb;
Important for preserving cultural heritage.
Level 0: archival and museum code.
Examples:
— abandoned projects;
— projects with completed development cycle;
— demonstration code within research;
— forced open-source for license compliance;
— projects for preserving cultural heritage,
of historical interest;
Level 1: «cathedral development».
Source code is publicly available.
Product is developed without community participation.
Example 1:
— SQLite: developed by a small team;
patches are accepted in exceptional cases
and usually rewritten.
Example 2:
— development within corporations
with periodic publication of code snapshots.
Level 2:
Source code is publicly available.
Patches from community are accepted.
Closed development processes.
Development processes:
— contribution guidelines;
— task tracker;
— code review system;
— development roadmap;
— testing and CI system;
— release cycle;
— user support;
— documentation;
Level 3:
Source code is publicly available.
Patches from community are accepted.
Open development processes.
Maximum encouragement and community involvement.
GitHub — is a social network for developers.
Question: can GitHub contain all development processes,
to maximize its advantages?
Example 1: torvalds/linux
Possibly the largest and most developed community.
Recently started using GitHub for code hosting.
Changes are accepted through mailing lists,
pull requests on GitHub are not used
(as if they are used, but in fact, contain garbage).
For issue tracker, Bugzilla is used,
Issues on GitHub are not provided.
For CI, a separate product kernelci.org is used.
No processes are integrated with GitHub.
Example 2: llvm/llvm-project
One of the most active open-source C++ products.
Recently migrated from SVN and self-hosting to Git and GitHub.
All pull requests on GitHub are automatically closed by a bot.
Patches are reviewed in Phabricator: https://reviews.llvm.org/
For issue tracker, Bugzilla is used: https://bugs.llvm.org/
No processes are integrated with GitHub.
Example 3: mongodb/mongo
JIRA is used as issue tracker
Changes are published as pull requests.
Code review and merge are done outside GitHub.
Community participation in development is minimal.
For CI system, their own development Evergreen is used: https://evergreen.mongodb.com/
Only test results are publicly available, but not logs and artifacts.
Example 4: arangodb/arangodb
Issues and pull requests on GitHub are used.
Active discussions and code review within GitHub.
Closed CI: links lead to inaccessible pages.
Example 5: tensorflow/tensorflow
Issues and pull requests on GitHub are used.
Active discussions and code review within GitHub.
Open CI: their own system is used,
logs and artifacts are publicly available.
Low barrier to entry:
— simplicity and clarity of code, presence of design docs;
— well-documented code — like a textbook.
Open not only code, but also processes:
— open-source product development can be a reality show!
Core developers use the same tools as external ones:
— send pull requests and merge them according to the same rules.
Discussions and plans are accessible from outside:
— a contributor can choose a large task to implement,
and discuss ways to implement it.
Minimal effort to make changes:
— presence of code style and guidelines;
— no need to register on external service;
— no need to fill complex forms;
— simplest possible process for agreeing to CLA or DCO.
Fast feedback in pull requests:
— publicly available, automated CI system:
quickly reports errors that the author can fix themselves.
— builds, linters, code formatting, static analysis,
tests and test coverage, fuzzing...
Friendly code review process:
— quick assignment of reviewers;
— collaborative work on code and bringing it to merge.
Involvement and encouragement of contributors:
— mandatory credits in changelog, list of authors;
— contests and hackathons; souvenirs, gifts;
— involvement in conferences and events;
— educational projects and interaction with institutes;
— technical articles, interesting for developers;
Never blame contributors for anything:
— if you accepted incomplete code — it's your problem;
— contribution to your product should be a source of pride.
Time and attention:
— developing a community will require a lot of effort.
Originally developed at Yandex.
We apply all the mentioned recommendations in practice :)
Working with the community — is a significant part
of my team's job responsibilities.
Currently 46%* of changes — from the community.
:) SELECT * FROM system.contributors ┌─name──────────────────────────────────┐ │ Olga Khvostikova │ │ abdrakhmanov │ │ Mikhail Filimonov │ │ Jason │ │ achulkov2 │ │ Veniamin Gvozdikov │ ... │ Artemeey │ │ ivanzhukov │ │ Ilya Khomutov │ └───────────────────────────────────────┘ 855 rows in set.
