Community: How to deal with attempts at sabotage

26 views
Skip to first unread message

Luke Kanies

unread,
Mar 4, 2009, 4:32:22 PM3/4/09
to puppet...@googlegroups.com
Hi all,

The underlying assumption of membership in any community is that your
participation is at worst neutral, and if possible positive.
Communities, online or off, generally do what they can to protect
themselves from detrimental influences, which is where policies,
politeness, moderators, and all that come into play.

Puppet's community has been both fortunate and awesome, in that it
requires almost no moderation or control; we've only had to kick a
couple of people out of our IRC channel and they were clearly just
insane or spammers, and we've never had to remove anyone from our
mailing list other than spammers.

We've recently had some problems where one or two people are
maintaining their presence in the Puppet community solely as a way to
recruit people out of Puppet and into their community, at the expense
of ours, and I think we need a straightforward community policy on this.

Overlapping communities are awesome, and I'm all for your encouraging
Puppet community members to join other communities *in addition to
ours*, but it seems a bit insane for us to support people coming into
our community just to evangelize competing products and communities.

My take is that if your participation in our community is *solely* for
purposes of shrinking it by drawing people into your community at the
expense of ours, then you should be kicked from our community.

What do others think? Should it be acceptable to privately contact
members of our community, encouraging them to leave?

--
Love is the triumph of imagination over intelligence.
-- H. L. Mencken
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

Ben Beuchler

unread,
Mar 4, 2009, 4:57:42 PM3/4/09
to puppet...@googlegroups.com
> What do others think?  Should it be acceptable to privately contact
> members of our community, encouraging them to leave?

It may be rude, but as long as they're not being threatening or
interfering with the communication flow, it seems it would be silly to
ban them. To do so would seem to be saying that either:

1) the community members are too stupid to make their own decisions
and must be protected from the dangerous teachings of the dissidents,
or
2) the other community is, in fact, superior and you need to block
communications in order to retain your own community.

We're grown ups. If someone is bugging us out-of-band, we can tell
them to go away, block their email, or decide to accompany them to
their fabulous World of Wonder and Excitement.

Out of curiosity, which other group is trying to snipe people away? Chef?

-Ben

Stephen John Smoogen

unread,
Mar 4, 2009, 5:03:30 PM3/4/09
to puppet...@googlegroups.com

The free speech side of things could say that it is a basic right
because its up to the person being contacted to choose to leave or
not. Throwing people out without solid evidence is too prone to
lawsuits, bad publicity for the people throwing, and can easily be
made into a "They just don't want competitors on their lists" kind of
game.. Also who decides, what evidence is it based off? Hearsay,
emails that could have been forged [been done before].. it can devolve
quickly into High School cliques of who's in and not. And that worst
of all drives away potential customers who are looking for
professionalism before they would want to use or be part of the
community.

Calling people on their behavior seems to be much more effective in
that it inoculates the community that they will be aware of it. In the
end it is still up to the individuals to leave/stay in a community.

--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

Jason Slagle

unread,
Mar 4, 2009, 5:14:29 PM3/4/09
to puppet...@googlegroups.com
On Wed, 4 Mar 2009, Ben Beuchler wrote:

> It may be rude, but as long as they're not being threatening or
> interfering with the communication flow, it seems it would be silly to
> ban them. To do so would seem to be saying that either:
>
> 1) the community members are too stupid to make their own decisions
> and must be protected from the dangerous teachings of the dissidents,
> or
> 2) the other community is, in fact, superior and you need to block
> communications in order to retain your own community.
>
> We're grown ups. If someone is bugging us out-of-band, we can tell
> them to go away, block their email, or decide to accompany them to
> their fabulous World of Wonder and Excitement.
>
> Out of curiosity, which other group is trying to snipe people away? Chef?

At the risk of naming names, I would guess it's chef amd fujin in
particular he's talking about.

I'll say, that as someone who has been new at this and has had trouble,
noone attempted to steer me towards them. I actually had to specifically
msg him and ask him what it was he was speaking of to get it out of him.

And after all that, and complaining in channel and on list that puppet was
driving me crazy because it's anti-programmy, I stuck with it and didn't
go to chef.

As you said, we're all grown ups. I looked at the availability of
examples and the userbase and decided even with it's shortcomings (and
you're blind to think there aren't any), puppet was the way for me right
now.

Anyone who it doesn't work for will eventually find chef anyways. There
is a class of people it clearly works for. To me Ruby is a language I
don't want to learn enough of to utilize Chef to it's fullest, but that I
may be willing to learn enough to work around some of the puppet quirks
that bother me.

Just my 2c.

Jason

--
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ / ASCII Ribbon Campaign .
X - NO HTML/RTF in e-mail .
/ \ - NO Word docs in e-mail .

Tom D. Davidson

unread,
Mar 4, 2009, 5:25:07 PM3/4/09
to puppet...@googlegroups.com
I do not think rights of free speech matter in this context. What matters is the type of community you want to foster and develop. I think open source communities should strive for openness and transparency. I will not use or ever recommend SugarCRM because of the posts over the vTiger fork of mine and others that were "moderated". PBX-in-a-Flash "moderated" my questions concerning the use of GPL code and their shareware install scripts. In neither case was I trying to damage the communities, but someone thought that my questions would damage their community "market share".

I think the two example communities are damaged far more by the "moderation" than by the content of my post. If principles like freedom and openness are good, then I say they are always good - even when used for things we do not like.

In the spirit of transparency, I see not problem with a wiki posting of community "members" that have/had practiced "bad form", but I am still slow to recommend the evaluation of individual members.

-Tom

Luke Kanies

unread,
Mar 4, 2009, 5:59:46 PM3/4/09
to puppet...@googlegroups.com
On Mar 4, 2009, at 3:57 PM, Ben Beuchler wrote:

>
>> What do others think? Should it be acceptable to privately contact
>> members of our community, encouraging them to leave?
>
> It may be rude, but as long as they're not being threatening or
> interfering with the communication flow, it seems it would be silly to
> ban them. To do so would seem to be saying that either:
>
> 1) the community members are too stupid to make their own decisions
> and must be protected from the dangerous teachings of the dissidents,
> or
> 2) the other community is, in fact, superior and you need to block
> communications in order to retain your own community.

While I can't disagree with what you're saying, it seems to me that
there's something qualitively different between discussions on the
list about other projects and using the list as a marketing resource
for competing projects, which is essentially what's going on here.

I actually have no problem at all with people talking about Chef or
Cfengine or Quattor or whatever (including commercial tools like
BladeLogic or OpsWare) on the list, and in many ways I encourage it -
I think our product and community can and should stand against any of
them, and if it starts to fall down there I want to know so I can fix
it.

It's when people trawl the list looking for conversion targets whom
they then contact privately that I start to get a bit put out.

>
> We're grown ups. If someone is bugging us out-of-band, we can tell
> them to go away, block their email, or decide to accompany them to
> their fabulous World of Wonder and Excitement.

I expect this will be the general consensus.

I hate having to behave like an adult, rather than a petulant, jealous
9 year old. :)

>
> Out of curiosity, which other group is trying to snipe people away?
> Chef?

Importantly, it's not a group, it's an individual member of the Chef
community, AJ/fujin.

--
God loved the birds and invented trees. Man loved the birds and
invented cages. -- Jacques Deval

David Lutterkort

unread,
Mar 4, 2009, 6:45:46 PM3/4/09
to puppet...@googlegroups.com
On Wed, 2009-03-04 at 16:59 -0600, Luke Kanies wrote:
> >
> > We're grown ups. If someone is bugging us out-of-band, we can tell
> > them to go away, block their email, or decide to accompany them to
> > their fabulous World of Wonder and Excitement.
>
> I expect this will be the general consensus.

I think the only workable solution is to ignore it - not because it's a
good solution, but because all the others are even less palatable. And
if you are at the receiving end of what feels like an improper
recruitment attempt, send your reply to the list. Ultimately, such
attempts are much more damaging to the other community than to puppet's.

> I hate having to behave like an adult, rather than a petulant, jealous
> 9 year old. :)

Don't we all ? And yet, nothing drives my 2.5 year old madder than being
ignored.

> > Out of curiosity, which other group is trying to snipe people away?
> > Chef?
>
> Importantly, it's not a group, it's an individual member of the Chef
> community, AJ/fujin.

I can't speak to anything he may or may not have done (certainly not
from first-hand experience) - one thing that has been sorely missing
though is more discussion around the technical merits of one over the
other (polite, reasoned discussion !).

I certainly don't know enough about the two why they have to be entirely
separate projects, instead of having another frontend for Puppet;
looking at the bigger picture, I don't understand why Chef can't be
another frontend for Puppet, nor do I think that this split is in the
best interest of either community or OSS config mgmt in general.

David


Luke Kanies

unread,
Mar 4, 2009, 6:55:43 PM3/4/09
to puppet...@googlegroups.com
On Mar 4, 2009, at 5:45 PM, David Lutterkort wrote:

>
> On Wed, 2009-03-04 at 16:59 -0600, Luke Kanies wrote:
>>>
>>> We're grown ups. If someone is bugging us out-of-band, we can tell
>>> them to go away, block their email, or decide to accompany them to
>>> their fabulous World of Wonder and Excitement.
>>
>> I expect this will be the general consensus.
>
> I think the only workable solution is to ignore it - not because
> it's a
> good solution, but because all the others are even less palatable. And
> if you are at the receiving end of what feels like an improper
> recruitment attempt, send your reply to the list. Ultimately, such
> attempts are much more damaging to the other community than to
> puppet's.

That's a great idea - just replying publicly to those private emails.

>
>> I hate having to behave like an adult, rather than a petulant,
>> jealous
>> 9 year old. :)
>
> Don't we all ? And yet, nothing drives my 2.5 year old madder than
> being
> ignored.

Heh. My kids seem to get maddest when being locked in the basement,
but YMMV. :)

>
>>> Out of curiosity, which other group is trying to snipe people away?
>>> Chef?
>>
>> Importantly, it's not a group, it's an individual member of the Chef
>> community, AJ/fujin.
>
> I can't speak to anything he may or may not have done (certainly not
> from first-hand experience) - one thing that has been sorely missing
> though is more discussion around the technical merits of one over the
> other (polite, reasoned discussion !).
>
> I certainly don't know enough about the two why they have to be
> entirely
> separate projects, instead of having another frontend for Puppet;
> looking at the bigger picture, I don't understand why Chef can't be
> another frontend for Puppet, nor do I think that this split is in the
> best interest of either community or OSS config mgmt in general.

I have the same confusion, but the initial publication of Chef was
made with many claims that it was just easier for them to start again
than to try to understand Puppet's code base or to try to participate
as developers. Of course, this is a development truism: It's *always*
easier to start from scratch, it's just not not always better.

--
It is well to remember that the entire universe, with one trifling
exception, is composed of others. --John Andrew Holmes

Frank Sweetser

unread,
Mar 4, 2009, 6:58:36 PM3/4/09
to puppet...@googlegroups.com
Luke Kanies wrote:

> I have the same confusion, but the initial publication of Chef was
> made with many claims that it was just easier for them to start again
> than to try to understand Puppet's code base or to try to participate
> as developers. Of course, this is a development truism: It's *always*
> easier to start from scratch, it's just not not always better.

Starting is easy; finishing is harder.

--
Frank Sweetser fs at wpi.edu | For every problem, there is a solution that
WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken
GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC

Michael Robinson

unread,
Mar 5, 2009, 4:12:48 AM3/5/09
to puppet...@googlegroups.com
> I have the same confusion, but the initial publication of Chef was
> made with many claims that it was just easier for them to start again
> than to try to understand Puppet's code base or to try to participate
> as developers. Of course, this is a development truism: It's *always*
> easier to start from scratch, it's just not not always better.

AFAICT, and without having spent a lot of time investigating, Chef has
a vastly different set of requirements. Chef implements:

1. a system that is essentially a Ruby library, rather than a stand
alone language; and

2. has a fixed evaluation order, a la cfengine, rather than relying on
declared dependencies and a topological sort of the dependency graph.
(ie, the system evaluates recipes in order of declaration, rather than
dependency order)

Either would seem to make the system rather different to Puppet,
sufficiently so that they may indeed be correct that it is easier to
start again.

Michael.

paul matthews

unread,
Mar 5, 2009, 5:13:38 AM3/5/09
to puppet...@googlegroups.com
Aside from the various commendable points about free speech and tolerance, I would like to offer an alternate viewpoint in support of Luke's position. This is a chap who, whilst supporting a young family, has worked immeasurably hard creating this jewel of a product for (presumably) little financial gain. Now at the crucial point where Puppet is becoming established and commercially viable, he finds not only his ideas but also a lot of the terminology taken to form a competing product that claims in the strap-line of the home page to be "building the best infrastructure automation platform on the planet." Chef stands as a genuine rival in marketing terms and if I were him I would  find this somewhat galling. As I see it, his restraint, even to the point of asking his community for advice on this matter, has been commendable.

Obviously in open source forks occur. Often this is when the project leader is an autocrat who insists on absolute control but from my experience of Luke's postings he is a decent chap, who answers a huge number of postings and always in a helpful manner regardless of the fact that the same question may have been asked many times.
Sometimes the fork occurs for sound technical reasons but in this instance I can't see it, the products look just too similar. As an earlier contributor stated it would be good to air that discussion separately so that newcomers to configuration management do not just veer to Chef  as they assume the the newest  must be the best. If the reason, as I suspect is purely commercial and opportunistic, then I believe Luke deserves our support. These things happen, I know and hardly ever in a way that does not harm the original project. In my mind taking someones ideas and using them to benefit yourself to the likely detriment of others is rude. As Luke is a decent bloke and does not deserve to be taken advantage of, it's doubly so.

I think if you want to go ahead and ban these people, Luke, even if its for no other reason then making yourself feel better you should do so. You have my support for one

Paul


2009/3/4 Frank Sweetser <f...@wpi.edu>



--
Paul Matthews
----------------------------------------------------------------------

Joe McDonagh

unread,
Mar 5, 2009, 12:31:05 PM3/5/09
to puppet...@googlegroups.com
I'm with Luke on the whole Order-of-operations thing he had posted on
his blog at some point (I think in the history of puppet). I just think
it's a better design, and one of the main reasons why I didn't choose
cfengine to whip my inherited infrastructure into line. May have been
easier to start from scratch from the chef's dev POV, but the users of
cfg mgmt software are ops engs for the most part like me, and IDK about
the rest of you guys/gals who are users, but I seriously cannot maintain
order of operations that way... without losing my tiny bit of sanity
that I have left.

Michael Robinson

unread,
Mar 5, 2009, 3:42:21 PM3/5/09
to puppet...@googlegroups.com
Oh, I quite agree with you. It's why I stopped investigating Chef.

Just to be clear, the order of operation thing isn't like cfengine's
multiple passes; it is more like recipes are executed in the order
defined, and if you need to "depend" on something, you include the
other recipe.

Kent Tenney

unread,
Mar 5, 2009, 11:18:40 AM3/5/09
to puppet...@googlegroups.com
On Thu, Mar 5, 2009 at 5:45 PM, David Lutterkort <lut...@redhat.com> wrote:
>
> On Wed, 2009-03-04 at 16:59 -0600, Luke Kanies wrote:
>> >
>> > We're grown ups.  If someone is bugging us out-of-band, we can tell
>> > them to go away, block their email, or decide to accompany them to
>> > their fabulous World of Wonder and Excitement.
>>
>> I expect this will be the general consensus.
>
> I think the only workable solution is to ignore it - not because it's a
> good solution, but because all the others are even less palatable. And
> if you are at the receiving end of what feels like an improper
> recruitment attempt, send your reply to the list. Ultimately, such
> attempts are much more damaging to the other community than to puppet's.

Fascinating stuff.

As you said, my interest in Chef is now reduced to "what kind of
sleaze do they engage in?", and I've lost any interest in their technical
merits.

Had the efforts been well presented on list, I probably would have
investigated, being a sucker for shiny and new.

The secretive aspect also tells me the software is inferior, good
software wants a higher profile, not secrecy.

Thanks,
Kent

Paul Lathrop

unread,
Mar 5, 2009, 5:50:05 PM3/5/09
to puppet...@googlegroups.com

Having been waffling a bit on this question myself, I'd like to say
that I agree with those who say ignore it. Community members should
publicize attempts to speak to them that they feel are in poor taste,
by responding on-list. The Puppet community is pretty chill and
welcoming, let us strive to maintain that. I don't think a specific
effort needs to be made to make non-contributing folks who evangelize
for another project go away -- this is a self-limiting problem, people
only have so much patience for that crap.

Reductive Labs as a company should deal with attempts to snipe their
clients away however they see fit; that's not as much a Puppet
community issue (but feel free to tell us about it, because it's
sleazy as hell and enough to make me evangelize *against* the
perpetrators.)

My $.02, of course.

--Another Paul

Trevor Vaughan

unread,
Mar 5, 2009, 9:16:05 PM3/5/09
to puppet...@googlegroups.com
I finally got a chance to look at Chef and I must agree with Michael.
If I wanted to go this way, I would push forth with Cfengine. The big
advantage with Chef over Cfengine is that I can hack it in Ruby
instead of C.

The DSL in Puppet still holds trumps for me in terms of usability and
the community has been extremely responsive.

Trevor

Andrew Shafer

unread,
Mar 6, 2009, 1:27:23 AM3/6/09
to puppet...@googlegroups.com

The voice of reason has mostly prevailed in my opinion, which is the sentiment that the right approach is not to worry.

Trying to be as objective as possible, AJ has contributed to the Puppet community. He has submitted patches, triaged bugs and been helpful in both IRC and email. He is still quite helpful in #puppet, and though sometimes a tad snarky, he's not overtly subversive. He made a comment when chef was only about a week old that he was surprised that more people weren't changing or interested in chef from Puppet (I believe this was in #chef, which I usually join and occasionally participate in). There is a psychlogy to constantly convincing others of things in order to convince ourselves. *shrug*

The bottom line is chef exists for a complicated set of social, economic and technical reasons. I won't pretend to understand them all or that some of the circumstances are not personally emotive. That's all spilt milk under the bridge, as it were...

While some of the motivation for chef is clearly economic, I think 'sleazy' is a bit harsh. Both of these frameworks are released as free and open source. What long term business models evolve from that remain to be seen. Is Ruby stealing people from Python or C++? The long term value of Reductive Labs and Opscode are going to be determined by execution and intangibles, not subtle differences in how to solve a technology problem. And to be clear, that's really what we are talking about.

I have read enough chef code, cookbooks and discussion, in addition to having the context of discussions in this mailing list, to know chef admittedly learned a lot of lessons from Puppet. In my opinion, there were also some lessons that were ignored.

The fact is this is 2009. Information flows at the speed of light. With just a tiny bit of effort, people can find whatever they want, plus everything related to that in seconds. I can't fully explain what I mean by this now, but Puppet has and will derived benefit from chef and Opscode, directly and indirectly. If nothing else, chef helped us to focus. There is plenty of stuff going on behind the scenes and there is no point trying to police the flow of information on public lists and channels.

Puppet is awesome, except when it isn't, and the best way to move things forward is to address those and get back to making more awesome. That's what we need to be worried about. Just more awesome, this is not a zero sum game.

0.02
Andrew

Paul Lathrop

unread,
Mar 6, 2009, 12:52:11 PM3/6/09
to puppet...@googlegroups.com

*applause*

Gary Law

unread,
Mar 9, 2009, 5:11:17 AM3/9/09
to puppet...@googlegroups.com
2009/3/4 Luke Kanies <lu...@madstop.com>



What do others think?  Should it be acceptable to privately contact
members of our community, encouraging them to leave?

I'm quite comfortable with people talking about other products/approaches on the list. Even if that seems to be their only contribution to the group.

I'm not at all comfortable with people using list membership to email people off list. This has nothing to do with open source software specifically, this would be the case for any mailing list I'm on (eg my local cinema club; if someone started mailing me directly about things on at another cinema, I'd feel that was an abuse of the list). I would expect the list owner to warn them against it, and, if they continued, boot them off.

Gary


--
Gary Law
Email: gar...@garylaw.net
Chat googletalk/messenger: gary...@gmail.com
iChat/jabber/AIM: gary...@mac.com
Reply all
Reply to author
Forward
0 new messages