New project coming up...stay with Python, or go with a dot net language??? Your thoughts please!

[Paul Boddie]

Lasse Vågsæther Karlsen wrote:
> While Microsoft and other big software vendors might have a roadmap
> that ties you very tightly in with their budget, and also changes that
> roadmap from time to time which breaks your current software, a lot of
> open source projects have no roadmap at all.
>
> This means that a .x.y.2 upgrade might very well kill your software in
> the same way a 6-7 upgrade with VB might.

I think this explanation confuses the term roadmap with general release
discipline. A lot of open source projects are, well, open about things
like API stability and will label their stuff as "alpha" if things are
going to change frequently - one complaint heard relatively often is
that many open source projects are reluctant to put out a 1.0 release
because they don't consider their work to be finished. Meanwhile, many
open source projects do try and preserve consistency between
micro-releases, with any inconsistency being a fault that should be
raised with the maintainers - such faults being a phenomenon not
limited to open source software, either.

> The biggest reason for this, as far as I can tell, is that open source projects are very
> much built to integrate with other projects, simply because the source is
> available and it's thus far easier to integrate them, but that also
> means that unless you upgrade two integrated projects at the same time,
> you risk an upgrade in one breaking the other.

I'm not sure whether source availability is really the problem here.
I've experienced micro-release breakage and it was due to the
integration of lots of different libraries, many of which were upgraded
in the process of making the new micro-release of the software in
question, but with some of the more egregious breakage coming about
because in some micro-update of one of the libraries, the author
decided to radically change the available features of that library.
Since this was all Java-based, source availability really wasn't a
factor (these were all .jar files, after all); the problem could be
boiled down to good old release discipline: if one of your dependencies
plays fast and loose with API stability, expect some users to get
caught out.

If package maintainers make transitions of their software from release
2.4.2 to release 2.4.3 involve significant rewrites of your own
application, my advice involves either avoiding such packages from the
beginning or, if it's too late, considering what would be necessary to
maintain/subvert acceptably stable versions of them.

> I think a main point in a lot of projects is that unless you have to
> upgrade, don't. That way you can avoid a lot of problems by default.

This is good advice! The big difference between open source and
Microsoft, however, is that you can feasibly choose not to upgrade to
the next bloated/misguided release of some software and yet attempt to
roll in all the security updates and useful enhancements whose absence
would otherwise expose your applications to misuse or obsolescence.
Either path can involve a lot of hard work, but at least you get the
choice with open source software.

Paul