[ILUG] Open Source Developers and Users Survey

[Patrick O'Connor]

On 01/07/07, Brian Foster <blf at utvinternet.ie> wrote:
>   | Date: Sun, 01 Jul 2007 18:02:43 +0100
>   | From: Kae Verens <kae at verens.com>
>   | Errors-To: ilug-bounces at linux.ie
>   |
>   | Patrick O'Connor wrote:
>   | > Thanks again Kae, I feel like an idiot for not testing it thoroughly
>   | > before release.  That is why I am in constant awe of good devs!! ;)
>   |
>   | I think I wouldn't be alone in saying that it's not usually the
>   | developer that notices the bugs!  I have a habit of writing code,
>   | testing only the bits I'm interested in, and publishing it.
>   | Thank $deity for bug testers that are not coders!
>
>  good developers tend to have (learn) a number of
>  habits.  perhaps the most critical is to keep
>  learning.  in particular, to learn from mistakes
>  (not only yer own, but those of others as well).
>
>  so, for instance in this case, if Patrick were
>  to ever do another survey, I'd hope he'd recall
>  this experience and (guessing here) try to check
>  (more of) the various decision paths.
>
>  the Really Good developers do more than just
>  learn.  they  (i) actively try to avoid mistakes;
>  and  (ii) actively try to ensure the (inevitable)
>  mistakes are easy to identify, root-cause, fix,
>  and (re-)test.  these are all closely related.
>
>  generally, this mean carefully thinking through
>  the design _and_ how to both test and debug the
>  implementation (and, when possible, the design
>  and/or model(s) itself).
>
>  that need not be complicated.  (and, in fact, it
>  should not be complicated, since, e.g., any debug
>  code must also be debugged.)  as one example, I'm
>  a huge fan of "asserts" (esp. for languages that
>  support the concept).  a design/implementation
>  with known entry/intermediate/exit conditions can
>  translate into a highly useful, and natural, set
>  of invariants (assertions).  I find that putting
>  effort into writing correct, not always trivial,
>  assertions helps to check the code as I write,
>  and flags up specific (additional) cases to be
>  tested.  plus, when a correct assert detonates,
>  because (my) code is liberally sprinkled with 'em,
>  the detected failure is often quite close to the
>  coding error.
>
>  ( however, I'm not saying that that approach is
>   necessarily viable in Patrick's current case. )
>
>  another part of this active process of problem
>  avoidance is to realise it never stops; or, to
>  put it another way, the tests et al. will have
>  to be, for whatever reasons (plural), repeated
>  more than once in the future.
>
>  what that translates into depends very much on
>  just what it is you need to test.  again using
>  myself as an example, in my last job, this was
>  "easy":  I worked on a compiler, and compilers
>  are very deterministic.  so there was a large
>  and ever-growing fully automated test suite.
>  the suite tended to test the rare and corner
>  cases, since (as Dr Knuth and others have
>  observed), the usual cases tend to take care
>  of themselves (and are often covered by the
>  rare and corner case testing).
>
>  more relevant is the effort put into the test
>  suite:  the rule-of-thumb was it took at least
>  as long to develop a suitable collection of
>  tests as it did to develop (or fix) the feature
>  being tested.  e.g., if it took a day to twiddle
>  the compiler, it'd take at least another day to
>  build a comprehensively adequate set of tests.
>  (this wasn't because the test suite was hard to
>  extend — it was easy (by design!) to extend — but
>  because non-trivial testing is, well, non-trivial.)
>
>  ( however, what repeating testing means in the
>   case of GUIs, such as Patrick's survey, seems
>   tricky?  I'm not a GUI person, so I'm not too
>   up on just what is possible or recommended. )
>
>  the upshot of learning from mistakes, designing
>  out defects, designing in tests and debugability,
>  and repeating testing is it can be "the coders"
>  who find (most of) the problems.
>
>  nonetheless, testers, test suites, et al., who
>  are not coders and developmental tests are still
>  critical.  but they are essentially a last resort
>  (or at least used as one); broadly, if they (or
>  the users/customers/clients) find a bug, it is
>  a lot harder/slower/expensive to fix.
>
>  which is one reason Really Really Good developers
>  try to "front load" the design and development.
>  the sooner (and quicker) an issue is identified,
>  the sooner, cheaper, and better it can be fixed
>  (or, if found soon enough, essentially avoided).
>
>  ( there are many different ways of front loading;
>   "rapid prototyping" is a popular technique ATM. )
>
>  then of course, in cases like Patrick's survey,
>  there's the issue of designing a useful survey
>  (and obtaining useful replies).  this can be
>  rather tricky!   I note Patrick's survey is
>  self-selecting (which can be Ok); this e-mailing
>  list is perhaps a biased collection of potential
>  respondents (which can be Ok); and (after quickly
>  looking at it) did not see  (1) any attempt to
>  check what "open source" means (to the respondent);
>  nor  (2) any attempt to quantify this mysterious
>  "open source" versus probable alternatives (e.g.,
>  proprietary, internal, non-computerised, et al.).

Thanks for your words Brian. In relation to the potential for bias,
the survey is to try and gain an insight into the motivations of open
source / free software developers and users specifically, not computer
users in general.
The paper I am writing is focussing on two elements of open source /
free software:
1. The tools open source  free software developers use to work in a
distributed environment
2. The motivations driving developers to create open source / free
software. Which the survey directly addresses.

As such, this survey is not really aimed at those who are ambivalent
towards what flavour of software they write / use etc. It also makes
the assumption that people responding to the survey know what the term
open source means. To keep everyone happy I suppose I should have used
the terms open source / free software ;)

Thanks again for taing the time to respond, I really appreciate all
your opinions.
>
>  apologies for rambling on.  and on.  and on!...  ;-)

I tend to be prone to that myself.. LOL
> cheers!
>         -blf-
> --
> ▶ ▶  I AM CURRENTLY LOOKING FOR A JOB!  ◀ ◀ | Brian Foster
> Experienced (>25 yrs) software engineer:    |        Montpellier, FRANCE
>  • Unix, Linux, embedded, design-for-test;  | Stop E$$o (ExxonMobile)!
>  • Software/hardware co-design, debugging;  |     http:/www.stopesso.com
>  • Kernels, drivers, filesystems, &tc;    Résumé (CV) & contact details:
>  • IDL, automated testing, process, &tc.   http://www.blf.utvinternet.ie
> --
> Irish Linux Users' Group mailing list
> About this list : http://mail.linux.ie/mailman/listinfo/ilug
> Who we are : http://www.linux.ie/
> Where we are : http://www.linux.ie/map/
>