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

[Brian Granger]

>  Open source does not translate into "better quality" software.  One
>  can simply look at freshmeat or any of the other open source projects
>  out there to see that for every one or two quality open source
>  projects there are literally thousands that are horrible.  As stated
>  by a few others on this discussion most open source projects are coded
>  by people who "pray and spray" and who do not go through the rigors of
>  true testing for a production environment.  I know that not everyone
>  falls into this category, nor am I categorizing people on this list as
>  such.

Very true, but the same can be said about closed source software.  The
reality is that many (most?) open _and_ closed source software has
poor software engineering and testing behind it.  One nice thing about
projects that have open development models, is that you can quickly
get a sense of the quality of the software by looking at the test
suite, development practices.

For companies considering using Erlang, this matters.  Especially when
it comes to bug tracking and testing.  In these areas, transparency
leads to trust.  Trust of this form leads to more users.

>  Lets look at the cost of what it would take Ericsson to open up the
>  repository as is being discussed.
>
>  - Employee time spent moving things out of clearcase into another
>  repository while maintaining source history.  Yes, one can argue that
>  simply taking a snapshot of the current state and starting a new
>  repository might be acceptable but I doubt that would be acceptable to
>  them.  This takes a serious amount of time from an employee who would
>  otherwise be working on things that directly provide revenue for a
>  company (primary purpose of companies is to make money for the
>  shareholders).  This is a one to two week investment just to get the
>  ball rolling.

This is a time consuming thing, but it is a one time cost.

>  - Now, for every patch that is submitted through the process, an
>  employee has to review the submission, verify whether it is acceptable
>  or not, approve or reject it, write a note to the submitter if its
>  been rejected (or check-in comment), and roll it into the baseline if
>  it is.  This is for EVERY submission regardless of whether or not it
>  is part of the business goals of the company.  Based on my experience
>  with having been the make mom for a bunch of good size projects, this
>  can take a huge amount of time.  Very quickly it gets to the point
>  where that person is doing nothing but dealing with patches.
>  Interviews with Linus Torvalds indicate that the bulk of his time on
>  the kernel isn't spent doing coding, its dealing with submissions.

I'm sure that Linus is completely annoyed to have to deal with all
those contributors to Linux ;-).

But seriously, most software projects (open and closed source) I know
of would _love_ to have more top notch contributors - especially ones
that work for free.  I am not talking about hackers that submit buggy,
half baked code, but truly good ones.  It is true that as a
development team grows, you have to spend more time coming up with a
good process - for instance one that distributes code review and
testing over a larger set of people.

But, one of the big benefits of opening up development is the
possibility of attracting some really good developers.  In my mind,
this is a good thing, not a bad thing.

>  So the overall cost to start something like this is basically
>  allocating one whole person to it.  In the companies I typically work
>  with (Washington DC area software shops) this is roughly $200K

Again, I would view it as a truly great thing if people were
submitting so many patches to Erlang that such a person had to be
hired.

>  What are the benefits:
>
>  - Quicker inclusion of new capabilities.
>   True, but are these capabilities that help Ericsson?  Does a new
>  wrapper around a vector graphics library (libcairo) help a company
>  that writes the embedded software for network hardware?  There are
>  some fantastic libraries out there but what percentage of them are
>  suitable for Ericsson's goals?

True, but isn't this a straw man argument.  I can also think of many
improvements that Ericsson would potentially be interested in:

- An implementation of the erlang network protocol that runs over high
speed interconnects like infiniband (maybe this already exists?)

- SMP performance optimizations

- Better tools for integrating Erlang with other languages

Opening up the dev process could bring people out of the woodwork to
work on interesting things like this.

>  - Better code quality
>   Maybe.  Most code I've seen written on the net does not do nearly
>  the job required for testing that I require for production quality
>  code my team releases.  If you're Ericsson, and you're achieving 7 or
>  9-9s of system uptime, a single bug can introduce serious problems.
>  Do you trust the most software developers out there to be rigorous
>  enough to do this?  Its tedious, hard, unsexy work and most people
>  just don't do it.

I fully agree with this.  But, I think this is why an open development
process is important.  When people make an important choice - like
what language to use for a project, it is important for them to be
able to judge the quality of the language implementation and the
overall health of the language.  With an open source language like
Python, it is very easy to get a sense of both of these things.
People like that.