[mythtv-users] Feature request page on wiki

[Gary Buhrmaster]

On Mon, Jan 23, 2012 at 16:33, Tim Draper <veehexx at gmail.com> wrote:
...
> it seems I've mis-understood how the mythtv project works, but i see
> your POV. When i say 'works', i mean the way work is prioritized. i
> presumed it was done on a most-desired based list. it seems not.

my 2 cents....

I think of it as the people who contribute code have "super
majority voting shares", which, essentially, control the
effective priorities because it is what the contributors
have determined as most-desired (by them).  I will note
that some of the features being worked on (at least by
comments on the lists) may not even have entries on the
wiki (or the entry is only partially related), and some of
the changes are not user visible (but improve the system
itself).  Sometimes you are going to get something RSN
that you do not know you even wanted (until you get it).

That is what non-commercial open source is.  A group
of individuals who respond to their itch.  If there was
a "MythTV.com", who (for example) sold support, and
paid developers for do what their customers were asking
for, then I could see the feature priorities being different.

While I am not suggesting moving to a commercial
model, I would not be surprised that if some enterprising
person created a "feature bounty" fund for new features
some developer might decide to change his priorities
(or someone new to start developing for MythTV) if the
return was high enough.  Like it or not, positive
reinforcement in the form of money can influence
behavior, and even "spare time" has value.

I will also note that real bugs (and not changes/features)
are regularly fixed by developers, although the wide
variability of configurations makes reproducing some
failures hard (or sometimes the entire design must
change).  AFAIK there is no "mythtv lab" where all
distros, and all tuners, and all scheduling sources
exist to be able to do real regression testing and
feature validation.  Sometimes that means only one
or two people in the community can even look at a
particular problem (and they might happen to be busy
with their own life priorities).

As an occasional contributor to open source projects,
I try hard to either provide code to scratch my itch,
or a reliable reproducer so that the developer can use
the appropriate debugging tools when they have time
to look at a real bug.  If I want someone else to do that
work, I purchase a commercial support contract.

Gary