Creating the Technical Steering Committee at IEUG

By Industrial Erlang User Group | Published: June 4, 2016

The Technical Steering Committee (TSC) of IEUG will be responsible for defining the technical roadmaps of IEUG and driving technical projects forward. The OTP team at Ericsson defines the roadmaps of Erlang/OTP. The TSC at IEUG defines roadmaps for items that are not on Ericsson’s roadmap, but beneficial for the entire Erlang ecosystem, complementing Ericsson’s work. The TSC and the OTP team is close collaboration in sharing responsibilities and exchanging ideas.

The Technical Steering Committee currently consists of all the Board members. In the near future, the TSC will be open to external collaborators who have demonstrated both technical expertise critical to the ongoing maintenance and evolution of Erlang/OTP and a long term commitment to driving the projects and the Erlang community forward. A selection process will be published by the Board.

As a result of a poll within the Technical Steering Committee, the following projects have been proposed:
  1. Documentation improvement
  2. Folsom and exometer improvement
  3. Logging/tracing libraries
  4. JSON
  5. Xmerl
  7. Building portable binary
  8. Erlang Editor
  9. Rebar3 parallel compilation
  10. FIPS 140-2


1. Documentation improvement

Initially proposed by: Peer Stritzinger



  • Improved quality of existing documentation
  • Improved quality of user guides and examples
  • Improved look and feel, and accessibility
  • Cooperation with Elixir community


  • Thoroughness and writing skills needed
  • Optional: Written by someone who is learning Erlang


2. Building portable binary

Initially proposed by: Torben Hoffmann



  • Ability to use rebar3 or to build Erlang systems as a binary packages in a similar way as RPM
  • Ability to build one single binary which has no dependency to shared libraries in runtime, making binaries more portable over Linux distributions
  • Ability to have a repository of apps in binary, served internally within a company


3. Folsom and exometer

Initially pProposed by: Chandru Mullaparthi



  • Improve folsom and exometer to become unstable under heavy load
  • Optionally, a single canonical application without a long dependency chain, and able to build on Windows


4. Logging/tracing libraries

Initially proposed by: Chandru Mullaparthi



  • Improved log4erl which has feature parity with log4j and log4net
  • Improved error_logging:
  • error-logging in OTP should have a better plug-in interface which does not require the duplication of a full event handler.
  • Support for overload protection (frequency and volume limit and just drop messages with a not in the log that they are dropped.
  • Flexible and easy plugin way for supporting different sinks for the data
  • Lager has to many dependencies, uses parse transforms, and is not plugged in the way we would like it to be. But obviously Lager is popular in the community. Partly this is because the plugin interface of today is not the right one.
  • Formatting should be done on the generating side to avoid having a bottleneck in a central logger process.
  • Possibility to interface with existing popular logging frameworks and using them as a sink for Erlang logging.


5. Xmerl

Initially proposed by: Kenneth Lundin



A complete xmerl with validation (xmerl of today have one old part which is pretty bad and a new part (the sax parser) which is really good and fast. Unfortunately the SAX parser does not come with a validator, which we have in our plans but have a hard time to prioritize. Some may think that Erlsom is a superior solution for XML parsing, but I don’t think that is true. It was true when compared with the ols xmerl stuff, but not now when we have the SAX parser.



Initially proposed by: Kenneth Lundin



Select, endorse and support a well designed JSON solution. Possibly include it in Erlang/OTP.



Initially proposed by: Kenneth Lundin



  • REST API off the shelf support both client and server
  • Select, endorse and support a web server solution, such as cowboy


8 . Erlang Editor IDE

Initially proposed by: Kenneth Lundin



  • Select, endorse and support Editor/IDE solutions for Erlang. Ericsson is paying for development of ErlIDE (Eclipse) and it works really well (used inside Ericsson, whose majority is using Emacs).
  • E.g. GPB by Tomas Abrahamsson (Ericsson) is a very good implementation, used in production at Ericsson.


9. Rebar3 parallel compilation

Initially proposed by: Tristan Sloughter


TS: Rebar 2.x had parallel compilation of modules but in the majority of cases it would slow down the compilation of an application, not speed it up. So in adding this feature to rebar3 the prior work in rebar 2.x would help it along but we would not want it included unless it was smart enough to turn itself off if it would slow down compilation. This could be as simple as checking how many modules needs to be compiled and if < some number then just do them in sequence.


Additionally parallel compilation of applications would be a larger win for performance.



10. FIPS 140-2

Initially proposed by: Tristan Sloughter


TS: This is a federal requirements for cryptographic modules. I do not know the actual work required to make Erlang meet the requirements, but it is required for some uses in government and would benefit Erlang in that way.


About Industrial Erlang User Group

The Industrial Erlang User Group is a non-profit organization consisting of a group of enterprise Erlang users, funding a range of activities focused on developing the Erlang community and broader adoption.


For more information, please contact

Bruce Yinhe, Community Manager, tel: +46 72 3114389, email: community-manager (@)

Follow Erlang Central:

Have an Erlang Question?

Reach out to the Erlang community