s***@gmail.com
2010-04-07 09:02:19 UTC
(I've initiated this discussion simultaneously on both mailinglists and
on the "Open Discussion" forum)
Hi all,
As you may have noticed, ALS has not been developed actively since last
summer / early autumn:
* http://sourceforge.net/apps/trac/openvpn-als/wiki/scrum_chatlogs
* http://dir.gmane.org/gmane.network.openvpn.als.devel
In addition, the lack of maintenance development since the fork (in May
2008) means some parts of the code are falling apart already due to
changes in Adito/ALS operating environment (the UNIX auth module, CIFS
support in networkplaces...). Also, there are at least two known
security vulnerabilities and expecting a fix would be unrealistic:
* <http://sourceforge.net/apps/trac/openvpn-als/ticket/2>
* <http://thread.gmane.org/gmane.network.openvpn.als.user/12>
I had hoped that OpenVPN Technologies Inc. - my current employer, btw -
would have allocated development resources into the project. However,
after having long discussions with James (CTO) and Francis (CEO) we
decided not to support OpenVPN ALS. Just for the record I fully agree
with them on this. The rationale behind our decision boils down to this:
* We already have a similar product, OpenVPN Access Server, which
- serves 90% of the same needs as ALS
- we know very well (as we wrote it)
- does not require hiring JavaEE developers
* We only need the reverse proxy / replacement proxy capabilities of
ALS, for which there other more lightweight solutions
* We do not wish to support) ALS as a separate product alongside Access
Server
There are many generic problems with monetizing on OpenVPN ALS - the
biggest problem being the GPLv2 license coupled with the lack of full
copyright to the whole codebase. This prevents 3sp-style proprietary
add-ons without going against the spirit of the license, e.g by trying
to circumvent the GPLv2 limitations in "NVIDIA style". I can't think of
any other commercial business model that would work for this particular
project. I don't think there has been any significant demand for
commercial support services, even though they've been available for a
long time now:
*
<http://sourceforge.net/apps/trac/openvpn-als/wiki/commercial_support_options>
To make things worse, the project is ill-suited for a community-driven
project. There are quite a few reasons for this:
* There's very little high-level documentation available
* Codebase is very large and the components are tightly integrated,
meaning that
- nobody really knows the codebase inside out well enough to help new
developers
- the barrier to entry for new developers is _very_ high
- application maintenance is very costly
* The application is built on a semi-obsolete JavaEE framework (Struts
Classic), which means that
- big parts would have to be rewritten soonish, probably in a couple
of years
- the code is very difficult to understand unless you know Struts
Classic conventions
* The scope of the application is very narrow which means that
- it can't be used as a building block for other projects (which
would increase development effort)
- the userbase (=number of potential contributors/developers) is
pretty small
Earlier I tried to organize s.c. "Joint commercial development" without
any success:
*
<http://sourceforge.net/apps/trac/openvpn-als/wiki/joint_commercial_openvpn-als_development>
The problem is that the companies that have SSL-Explorer/Adito/OpenVPN
ALS customers seem to be small and either don't have JavaEE programmers
on the payroll or can't allocate them to the project even part-time.
This prevents any developers ever reaching a level of skill which would
enable them to develop ALS itself, rather than just extensions. I have
to assume that the lack of skills in community-driven OSS development
also plays a part in this, so even if there are competent developers out
there, they do not participate in the project.
Now, what can we do? Personally I can only see three ways forward for
the project:
1) Discontinue the project and let it die slowly
2) Get a single entity to create a commercial version and give them our
full support
3) Get a single entity to support the community version, but gather
funding from the users
Currently we're clearly heading towards 1). Option 2) would probably
require circumventing the GPLv2 license and proprietary add-ons to make
commercial sense. I don't know of any company interested in that option,
either.
I think 3) is least unrealistic, but would be very difficult to organize
and manage. It's also quite difficult to make people pay for something
they get for free - it's much easier to just have a nice ride and jump
off when boat starts sinking.
on the "Open Discussion" forum)
Hi all,
As you may have noticed, ALS has not been developed actively since last
summer / early autumn:
* http://sourceforge.net/apps/trac/openvpn-als/wiki/scrum_chatlogs
* http://dir.gmane.org/gmane.network.openvpn.als.devel
In addition, the lack of maintenance development since the fork (in May
2008) means some parts of the code are falling apart already due to
changes in Adito/ALS operating environment (the UNIX auth module, CIFS
support in networkplaces...). Also, there are at least two known
security vulnerabilities and expecting a fix would be unrealistic:
* <http://sourceforge.net/apps/trac/openvpn-als/ticket/2>
* <http://thread.gmane.org/gmane.network.openvpn.als.user/12>
I had hoped that OpenVPN Technologies Inc. - my current employer, btw -
would have allocated development resources into the project. However,
after having long discussions with James (CTO) and Francis (CEO) we
decided not to support OpenVPN ALS. Just for the record I fully agree
with them on this. The rationale behind our decision boils down to this:
* We already have a similar product, OpenVPN Access Server, which
- serves 90% of the same needs as ALS
- we know very well (as we wrote it)
- does not require hiring JavaEE developers
* We only need the reverse proxy / replacement proxy capabilities of
ALS, for which there other more lightweight solutions
* We do not wish to support) ALS as a separate product alongside Access
Server
There are many generic problems with monetizing on OpenVPN ALS - the
biggest problem being the GPLv2 license coupled with the lack of full
copyright to the whole codebase. This prevents 3sp-style proprietary
add-ons without going against the spirit of the license, e.g by trying
to circumvent the GPLv2 limitations in "NVIDIA style". I can't think of
any other commercial business model that would work for this particular
project. I don't think there has been any significant demand for
commercial support services, even though they've been available for a
long time now:
*
<http://sourceforge.net/apps/trac/openvpn-als/wiki/commercial_support_options>
To make things worse, the project is ill-suited for a community-driven
project. There are quite a few reasons for this:
* There's very little high-level documentation available
* Codebase is very large and the components are tightly integrated,
meaning that
- nobody really knows the codebase inside out well enough to help new
developers
- the barrier to entry for new developers is _very_ high
- application maintenance is very costly
* The application is built on a semi-obsolete JavaEE framework (Struts
Classic), which means that
- big parts would have to be rewritten soonish, probably in a couple
of years
- the code is very difficult to understand unless you know Struts
Classic conventions
* The scope of the application is very narrow which means that
- it can't be used as a building block for other projects (which
would increase development effort)
- the userbase (=number of potential contributors/developers) is
pretty small
Earlier I tried to organize s.c. "Joint commercial development" without
any success:
*
<http://sourceforge.net/apps/trac/openvpn-als/wiki/joint_commercial_openvpn-als_development>
The problem is that the companies that have SSL-Explorer/Adito/OpenVPN
ALS customers seem to be small and either don't have JavaEE programmers
on the payroll or can't allocate them to the project even part-time.
This prevents any developers ever reaching a level of skill which would
enable them to develop ALS itself, rather than just extensions. I have
to assume that the lack of skills in community-driven OSS development
also plays a part in this, so even if there are competent developers out
there, they do not participate in the project.
Now, what can we do? Personally I can only see three ways forward for
the project:
1) Discontinue the project and let it die slowly
2) Get a single entity to create a commercial version and give them our
full support
3) Get a single entity to support the community version, but gather
funding from the users
Currently we're clearly heading towards 1). Option 2) would probably
require circumventing the GPLv2 license and proprietary add-ons to make
commercial sense. I don't know of any company interested in that option,
either.
I think 3) is least unrealistic, but would be very difficult to organize
and manage. It's also quite difficult to make people pay for something
they get for free - it's much easier to just have a nice ride and jump
off when boat starts sinking.