[erlang-questions] Erlang 10 years of Open Source; it is time for the next step

[Masklinn]

On 17 Mar 2008, at 16:39 , Massimo Cesaro wrote:

> On Mon, Mar 17, 2008 at 11:38 AM, Torbjorn Tornkvist <tobbe@REDACTED 
> >
> wrote:
>
>>
>> It is now 10 years (I think...) since Erlang became Open Source.
>> The last year, the interest in Erlang has exploded and I think
>> it is time to take the next step; open up the development of Erlang.
>>
>
> Please help me to understand: What are the real benefits in doing  
> this?

Note that the following are my guesses, or the benefits I would see

>
> Erlang and OTP are a good example of conceptual integrity, mostly  
> because
> they are designed to solve real world problems; what are the  
> benefits in
> allowing, for example, the forking of the build tree?

Having a full history, allowing people out of Ericsson to create  
patches (that could then be forwarded to the core team for inclusion)  
or to create temporary or permanent forks to test out features (that  
would probably be much rarer and harder).

The first suggestion is one that is extremely well supported by DVCS:  
any user can clone the repository (which is the equivalent of checking  
it out in e.g. Subversion), then hack around (patch bugs, try to find  
things to cleanup, or even just create documentation patches which are  
already invaluable), save everything in his local repository and when  
needed "patchbomb" an erlang dev list (basically send revision as  
inline patches) so that they can be reviewed and considered for  
inclusion.

The patchbomb step could be replaced by "attach patches to bugs" if a  
bug tracker is opened (the former is the way Mercurial development  
works, the latter is the way Django's works -- in the Python world)

Conceptual integrity would be preserved because only the people who  
already have commit rights now would still have it, and these people  
would therefore have veto power over patches and suggestions, being  
able to enforce design decisions or style issues (and possibly ignore  
patches altogether if they don't have the time).

DVCS would just make contributions easier by allowing everybody to  
hack around locally (with history) and have an history of the Erlang  
development for documentation as well as bug-finding (bisection  
search) purposes.

>
> The language and its libraries are not static, they are maintained by
> Ericsson in a win-win situation for the end user. Until now, the  
> Erlang
> maintainers were quite responsive to the Erlang community requests,  
> and the
> overall quality of their releases is close to excellence.

The quality wouldn't have any reason to drop as the people holding the  
"keys to the kingdom" now would still have it. But on the other hand  
the people having the desire to contribute patches or documentation  
would have an easier time doing it. Likewise, experiments based on  
erlang (loosely or tightly) would be easier for those not part of the  
core team.