New language discussion?
arthur.barrett at march-hare.com
Wed Oct 31 19:40:19 UTC 2007
Thanks to all who have replied. I'd like to address a couple of the
main Q's that everyone seems to be asking without replying to each post
1. Why C++?
It solves a particular business problem for us. As a commercial
software vendor our interest is in what our customers can deploy easily
and (particularly for large customers) software that has as few
dependencies as possible. We found this with our core open source CVSNT
as well - commercial customers do NOT want perl script triggers - they
want them in a DLL/.so. If you've ever tried installing MySQL and Perl
on HPUX or Windows then you'd know why, or if you've ever dealt with
security audits... We've had a lot of customers reject using our
Bugzilla integration because Bugzilla needs Perl (usually windows
customers) or the need to install MySQL (usually unix/linux customers
who want to keep an oracle only, or DB2 only shop - I know some progress
is being made in bugzilla towards database independance).
And yes - since CVSNT and EVS are both written in C++ we have lots of
C++ skills available to do this (and very few perl skills).
2. Why Windows as the first target.
Our customers when counted "by numbers" are split evenly across windows
and unix/linux however the biggest complaints that we have about
Bugzilla is from the windows customers. I'd like to stress though that
CVSNT and EVS runs cross platform - it's just a project management
decision to kill the linux/unix builds until after release 1 to
3. Asking for help to write non-open source
This is/was NOT my intention. What I am saying is that LOTS of our
(other) code is LGPL, and the bugzilla rewrite could be too IF I had
evidence to suggest that it would represent less work (ie: there are
people with time/skills clamouring to help but cannot/will not due to
the licnese). Responses this far suggest that we are currently
following the best path in keeping development closed.
I am not a fan of rewrites, and I'd only marginally call what we are
doing a rewrite. Release 1 will not re-implement the full feature set
of bugzilla, but it will use the (latest) Bugzilla data model. This
means that for people who want a bug tracking system that "can grow"
then they can start with ours that works "out of the box" and later
install the "full" Bugzilla on top.
Yes our next beta will use an old data model, but the intention is to
change that ASAP. We'll most likely start with a VERY minor subset of
implemented functionality and let our customers decide which are the
"critical" missing features.
I'm not even sure if we have a name - the idea of EVS is it is a CM
system, rather than needing SCM+defect tracking+audit+build+etc etc,
it's just all in one. I'm sure we'll market it as "data model
compatible with Bugzilla, but that doesn't infringe any trademark I
6. if we did go open source...
Our main open source project is CVSNT, which was essentially a fork from
CVS. One of the main things that drew people to CVSNT initially was
that the developers would accept almost any change and put it right into
the next build within a few days. We still give out write access to our
repo very quickly... If we did go open source with this "rewrite", then
that would be the same. I hate to see a company the size of AMD want to
contribute but not able to contribute due to the perception that the
open source management gets in the way.
7. bugzilla project
I personally think the bugzilla project is a great one - a true open
source success story. I am hoping our work means more people adopt it
because our software is "an easy way to start" (see point 4 above). As
I wrote earlier - we don't have much in the way of Perl expertise in
house, so contributing to a Perl based Bugzilla has never really been an
option for us. On the up side - by only supporting defect integration
to Bugzilla I know a lot of companies that have gone ahead with
Feel free to ask me any questions that you don't feel I've answered
More information about the developers