10. Maintenance after the initial release¶
10.1. Your responsiblity on adding a module to Erlang/OTP¶
When you add a module to Erlang/OTP, that means you are also responsible for maintaining the module, especially when the security issues or vulnerabilities are found. As in the case of typical Open Source Software, you are not legally bound to provide a help, but you are morally and professionally bound to provide a help when it is requested by the OTP Team. Also, you are expected to contribute a further enhancement or a new feature when they are available.
An unmaintained piece of code will be deprecated and removed from OTP by
the OTP Team’s discretion. Old code is prone to vulnerability or
degradation leading to new security issues. For example.
module, the predecessor of
rand module, survived for a very long
time at least from February 1999 , but finally to be phased
out and removed from OTP 20, which will be released in June 2017
. Generally speaking, an 18-year old code should be reviewed
and revised simply because it is old enough.
10.2. Move carefully for adding a new feature¶
Adding a new feature to an existing Erlang/OTP module may require the same or even more effort to write a new module. OTP Team generally takes conservative approach to changes, and the users of Erlang/OTP do not want drastic changes, especially when they break the backward compatibility. So you need to be careful on moving for adding a new feature to an existing module, even if that is under your control.
|The oldest available source code archive of Open Source
random module code resided at
erlang-47.4.1/lib/stdlib/src/random.erl. The time stamp
of the file was on
Feb 24 1999.
|Quoted from Kenneth Lundin’s presentation slides of News from The OTP Team, at Erlang User Conference 2016 in Stockholm, Sweden, September 2016.