Stop hate-fork­ing projects

Why Adam Innes be­lieves fork­ing is the high­est form of flat­tery in the world of open-source soft­ware

net magazine - - CONTENTS - Adam Innes is a Se­nior De­vel­oper at 50,000feet, a de­sign-tech agency in Chicago, USA. He has over 10 years’ ex­pe­ri­ence de­vel­op­ing web ap­pli­ca­tions and has been known to fork.

Adam Innes be­lieves fork­ing is the high­est form of flat­tery in the world of open-source

The open-source phi­los­o­phy lets any­one take a project in a new di­rec­tion by chang­ing the orig­i­nal to cre­ate some­thing unique. That phi­los­o­phy is the rea­son we have projects like Fire­fox, a project orig­i­nally forked from the Mozilla Ap­pli­ca­tion Suite. In Fire­fox’s case, the de­vel­op­ers felt the soft­ware was too bloated, so they used the orig­i­nal code­base to cre­ate a more stream­lined brows­ing ex­pe­ri­ence. As a re­sult, Fire­fox has be­come one of the most used browsers in the world. Fork­ing a project is a sa­cred and im­por­tant func­tion of the open-source model, which is why it’s im­por­tant to know when to do it right.

When it comes to proper fork­ing eti­quette, there are best prac­tices in re­gards to pub­lish­ing forks. To be clear, fork pri­vately any way you want. Ex­per­i­ment­ing with new fea­tures and code is part of the fun of pro­gram­ming. Even though guid­ing prin­ci­ples of open source en­sure de­vel­op­ers have the right to pub­lish a fork, it doesn’t mean that is al­ways the cor­rect choice. Fork­ing to make a small in­signif­i­cant change or to add a sin­gle fea­ture with­out prop­erly at­tempt­ing to par­tic­i­pate in and con­tribute to the open source com­mu­nity is bad form.

The orig­i­nal project main­tain­ers have put their code out there be­cause they be­lieve in it and they know that other peo­ple may have ideas to im­prove on what they’ve made. To them, the project is prob­a­bly some­thing they’re pas­sion­ate about. Be­fore bas­tar­dis­ing their hard work and ef­fort, one op­tion is to sub­mit a fea­ture re­quest. Open source projects typ­i­cally have a sys­tem in place to ac­cept feed­back and code, so we rec­om­mend us­ing it. If you’ve al­ready coded the change, sub­mit the new code in a pull re­quest. This ap­proach helps en­sure that de­vel­op­ers not pub­lish a fork and just walk away.

Sub­mit­ting a pull re­quest in lieu of a fork is es­pe­cially im­por­tant if you’re im­prov­ing the se­cu­rity of the code. Open Source soft­ware re­lies on the ‘many eyes’ ap­proach to se­cu­rity, mean­ing the more peo­ple look­ing through the code base, the bet­ter. Don’t hide your se­cu­rity tweak in an un­seen and for­got­ten fork. In­stead push it with pride and your ef­forts will likely be much ap­pre­ci­ated by the main­tain­ers plus you’ll be mak­ing the code more se­cure for all those who use it.

If you’re pas­sion­ate about the project and have a vi­sion for the fu­ture, be­come an ac­tive con­trib­u­tor. This is also a great way to hone your devel­op­ment skills. Par­tic­i­pat­ing in the project gives the main­tain­ers an op­por­tu­nity to make the fea­ture or change avail­able to every­one who uses that project by in­cor­po­rat­ing it into the orig­i­nal. Not only does this please users through the thought­ful im­prove­ment of the over­all user ex­pe­ri­ence, the prac­tice of join­ing a project can help in­tro­duce you to a world of cod­ing op­por­tu­ni­ties. When you build re­la­tion­ships with fel­low pro­gram­mers, the re­sult­ing sense of com­mu­nity up­lifts every­one.

If you’re pas­sion­ate about the project and have a vi­sion for the fu­ture, be­come an ac­tive con­trib­u­tor. Some­times you will find that the project has been aban­doned and is no longer ac­tively main­tained. In this case, you should reach out to the main­tainer and ask to take it over, which would af­ford you the op­tion of build­ing on the project frame­work while tak­ing it in a new di­rec­tion. A good ex­am­ple of this is when Jeff At­wood, the co-founder of Stack­Over­flow, pub­licly asked to take over the Mark­down project from John Gru­ber or to have Gru­ber par­tic­i­pate in a new ver­sion. Re­ceiv­ing no re­sponse, he cre­ated Com­monMark. Com­monMark was forked with the in­tent to cre­ate a new, bet­ter ver­sion of the orig­i­nal. At­wood at­tempted to par­tic­i­pate in the orig­i­nal project and reached out to the orig­i­nal main­tainer. That’s how you fork.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.