[asterisk-dev] Asterisk Beacon Module Proposal

[Russell Bryant]

On Mon, Jun 8, 2015 at 9:57 AM, Leif Madsen <leif.madsen at avoxi.com> wrote:

> On Mon, Jun 8, 2015 at 9:35 AM, Russell Bryant <russell at russellbryant.net>
> wrote:
>
>> On Tue, Jun 2, 2015 at 8:05 PM, Matthew Jordan <mjordan at digium.com>
>> wrote:
>>
>>> Personally, I'd like some way to present any user of Asterisk with a
>>>
>> one-time only, non-annoying "please help the project and opt in"
>>> question, and then move on forever. Unfortunately, I don't have a good
>>> idea on making this suggestion work. If the only way to opt in is to
>>> provide a .conf file and set "enable = true", then I can't see
>>> anywhere near sufficient numbers of people being aware of the
>>> configuration choice, much less making the choice to enable it, to
>>> justify the creation of the module itself.
>>>
>>> If someone has a good proposal on making the suggestion work, then I'd
>>> love to entertain it further.
>>>
>>
>> I feel that "opt-out" is fundamentally wrong from a privacy perspective.
>> Further, I think the potential backlash and resulting damage to the project
>> is pretty severe.
>>
>> I also don't think "opt-in is hard" is an acceptable reason not to do
>> it.  If it's too hard to make an opt-in solution useful, then maybe it
>> shouldn't be done at all.  This sort of thing really doesn't seem very
>> common, and this is probably a big reason why.
>>
>> One alternative would be to issue periodic user surveys that are promoted
>> on the mailing lists, twitter, etc.  I don't think you'll ever get a
>> reliable "absolute numbers" measure.  A survey could still produce useful
>> relative numbers and help identify some trends over time.
>>
>
> First, I think the idea of a quarterly survey makes a lot of sense. You
> would probably get a bunch of useful information in one go rather than a
> slow trickle of information. You could also make this something people do
> on the website when downloading Asterisk from there.
>
> Other projects I've seen this on (Bower for example), do it during the
> installation process. The way I would picture this working with the
> Makefile is that you provide a prompt with a Y/N selection asking if you
> want to opt-in. If someone wants to automate this process, provide a flag
> option that allows them to --opt-in or --opt-out in order to provide a
> selection while also skipping human input. Then you can "override" that
> compiled in default with the below suggestion.
>

As Matt pointed out, not everyone installs from source.  I'd say the vast
majority do not.  I think any packager that chose to compile Asterisk with
this stuff enabled by default should be flamed.  It's just plain wrong.

>
> Around the configuration file approach (which I think is also useful for
> those wanting to override the default compile time option, which will be
> selected during SOME sort of compile time process, whether that be on the
> machine, or during the package creation process), I would expect it to be a
> file provided via the 'make samples' option.
>
> Then on the console when you connect, you could provide output that looks
> similar to the following:
>
> $ asterisk -r
> Asterisk 1.8.11-cert9, Copyright (C) 1999 - 2012 Digium, Inc. and others.
> Created by Mark Spencer <markster at digium.com>
> Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for
> details.
> This is free software, with components licensed under the GNU General
> Public
> License version 2 and other licenses; you are welcome to redistribute it
> under
> certain conditions. Type 'core show license' for details.
> =========================================================================
> Connected to Asterisk 1.8.11-cert9 currently running on localhost (pid =
> 4364)
> Verbosity is at least 5
> Asterisk Beacon: Enabled (see core show help beacon)
> *CLI>
>
> With a separate configuration file and module, you could then provide the
> following option:
>
> beacon set opt in
> beacon set opt out
>
> This would then write out to the configuration beacon.conf with
> enabled=yes or no and reload the module.
>

So, all of this is about making opt-in easier.  That's fine, but folks will
have to decide if it's still useful enough to do the work and run the
server side infrastructure.  I suspect not, personally.

-- 
Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150608/e7d3a672/attachment.html>