couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wenk <>
Subject Re: Marketing suggestion
Date Mon, 03 Feb 2014 10:09:58 GMT
On 3 February 2014 10:46, Benoit Chesneau <> wrote:

> On Mon, Feb 3, 2014 at 10:27 AM, Andy Wenk <> wrote:
>> On 3 February 2014 10:14, Benoit Chesneau <> wrote:
>>> On Mon, Feb 3, 2014 at 10:03 AM, Andy Wenk <> wrote:
>>>> On 3 February 2014 08:42, Benoit Chesneau <> wrote:
>>>>> On Sun, Feb 2, 2014 at 3:16 PM, Noah Slater <>wrote:
>>>>>> Ashley,
>>>>>> Wrt marketing plans: yes, but half way between my head, and my private
>>>>>> notes. Unfortunately, my private notes also contain things from
>>>>>> private conversations with people. Major mistake on my part. Apologies
>>>>>> to the community.
>>>>>> I've just sent an email giving a few people notice that I plan to
>>>>>> start moving things over to the wiki. Hopefully over the next week
>>>>>> so I can get all of our existing marketing ideas in a communal space
>>>>>> so we can start to discuss it.
>>>>>> As for the marketing@ list: great. So what we'll do now is wait
>>>>>> another day or two. If nobody objects, we can make the list. (This
>>>>>> how we make most of our decisions on the project.
>>>>> I am not sure it's a good idea to have a marketing list. Marketing
>>>>> should be linked to dev and vice-versa . It's important that marketing
>>>>> follows dev discussion and that dev follows and interact with the
>>>>> marketing. Having 2 mailing-lists will create a disconnection. Which
>>>>> good path to the failure in tech. Also due to the low volumes of mails
>>>>> @dev this shouldn't be a problem.
>>>>> - benoit
>>>> hm ... I understand exactly what you mean and I agree, if we would
>>>> speak of a company with different big departments here. But in our project
>>>> I think it is totally ok that we have two different lists and the people
>>>> who are strongly interested in both parts should subscribe both lists. The
>>>> advantage imho is to not flood the dev@ list with unrelated stuff ...
>>> Why do you think it would be different because we are an opensource
>>> project? If marketing people don't want to follow all devs discussion then
>>> there is some perspective problem imo. The same for devs that ignore the
>>> users perspectives. Marketing should be elaborated with all the devs, not
>>> in a side corner. At least this what we learn in management schools. And
>>> this is really true for a **neutral**  opensource project which has no
>>> business perspective (and shouldn't have).
>>> - benoit
>> I did not mean to see it differently because we are an OpenSource project
>> but because of the size of the project. I don't think that we will have the
>> situation, that the marketing activities are going into a different
>> direction because of having two lists. I still believe that everything is
>> very transparent. Having more lists does not lead to in-transparencies but
>> will lead in more focused discussions. The connection between marketing and
>> development targets is created by the interest people have - and they
>> should be interested in both and should therefor subscribe both lists ...
>> if they don't they are not interested in marketing activities (what is ok
>> for me). But I agree that if no dev will subscribe the marketing list, we
>> will have the marketing activities in a side corner ...
> this is the " if they don't they are not interested in marketing
> activities"  which is problematic. By marketing in a community project, I
> often mean every actions taken to grow the community. I can't imagine a dev
> not interested by it. Having a marketing list is also quite uncommon in an
> opensource projects. But to be more concrete I often take the zeromq
> project as a template to build a successful community, When you see the
> mailing-lists attached to the project [1] you only have 2. If you take a
> recent success in communication, the docker project, this is the same [2].

Imo this is part of its success. While it's totally fine to multiply the
> annonces channels, I do think that a community and its members  should act
> together when it's about core community discussions. Part of these core
> discussions are:
> - dev discussions : features/roadmap/status
> - community discussions
> - users discussions about some features

I can't say too much about how to create a successful community because
CouchDB is just the second I actively take part. On the other hand I have
quite a lot ideas how to help doing it. But I am wondering why we then have
already way more than two lists. I suppose the discussion is coming up
because you consider

- we already have too much lists
- marketing should not be included in the dev@ list (what we are actually
speaking about)

I can understand both points very well. But on the other hand I don't have
the feeling, that having these lists is problematic. But I have subscribed
to all lists and therefor do not miss anything.  I don't wanna throw "he
look here is my example" in the discussion. But let me just say, that the
PostgreSQL project has many many lists and I guess it's working well. So my
conclusion is first, that each project will find a best working way and
second the success is partially related to the lists as a great part but
also to many many other things.

> Also lot of peopple are already subscribed to more than XXX list, to
> follow N projetcs daily (customer purpose, survey...). When a project
> starts to have more than 2 lists it starts to be really annoying to track
> and quite expensive.

This is a fair point! I use GMail and filter all incoming list messages and
give them labels. But I believe if I had 20 more, I would go crazy and miss
stuff at the end.

I can fully understand your concerns but on the other hand I don't think
it's problematic to have a marketing list. So my suggestion is to wait for
thoughts by other community members ...

> - benoit

> [1]
> [2]

Andy Wenk
Hamburg - Germany

GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message