Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8 December 2016 at 15:31, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:

>> >   * maximum PR and user growth
>> How is less PR (only one event per year) instead of two lead into
>> "maximum PR" ?
>
> Two releases a year ends up barely being an "event", so it's hard to
> drum up new enthusiasm. I think that adds up to less interest total
> than we'd get for an annual release. I don't have data for it, but as
> someone working to do the drumming I'm inclined to give some weight to
> my own intuition.

I am going to agree that 2 major releases a year won't be an event,
but that is mainly because distros aren't really interesting to anyone
anymore. Computer operating systems are the indoor plumbing of the
late 20th and 21st century. We were really exciting in the 1880's when
we first came out and everyone had to go see that someone had put a
toilet in their house (and it didn't explode). You might even upgrade
your toilet every year to the latest model as they were always fixing
and adding some new feature. (Also because you were extremely wealthy
and having the newest model was expected) But by the 1910's it was
pretty much a done deal. You can move around the parts some amount but
people knew what their kind of toilet was and wouldn't want one that
looked or was different. No one updated it yearly just because the
1917 crapper had a pivot handle and last year was just a chain.
Instead you liked your chain and you would keep it even if no one made
them anymore.

We are going to have to come to terms that our day in exciting the
masses to switch is well past us. It doesn't mean we can't and
shouldn't work on marketing ourselves.. just that we should be aware
that doing multiple events a year aren't going to be big wins in
growth.

[This post was made possible by a grant from the odd searches one does
when your plumbing is broken.]

-- 
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux