State of Pidgin: Attracting and Maintaining New Contributors

[Gary Kramlich]

On Wed, Oct 4, 2017 at 10:45 AM, Matej Cepl <mcepl at cepl.eu> wrote:
> (replying just to you, so I don’t flame the useless thread)

Added back to the thread because you started the flames there and they
should be resolved there.  If you didn't intend to.. well maybe you
should have chosen a different tactic..

> On 04/10/17 02:57, Gary Kramlich wrote:
>> If we were to make that easier by using the mythical github unicorn
>> you claim exists, we would be doing both the contributors and
>> ourselves a disservice.
>
> First of all, I completely understand that you still suffer from bruises
> from previous you-must-turn-to-git-or-else discussions (ehm, I had a
> pleasure to argue with felipec too). I am not member of the pidgin
> project, so anything I see is just a comment of uninvolved observer
> (albeit, happy user, thank you!).

This has nothing to do with felipec, it is based on objective
reasoning and that mono cultures, while convenient, are a bad thing.

> Also, I have never said anything about unicorns. What I have said is
> that by insisting on out-of-fashion VC you push yourself to minority
> hosting service and keeping higher barriers of entry.

The implication your making is that "you'll get more contributors if
you move to github".  While this might be true, our code base is not
nice to newcomers.  I have stated this in the video which is pretty
clear you haven't watched and even in this email thread that it
appears you haven't read either.

If I were to attempt to follow the logic behind your comments about
"out-of-fashion vc" and "minority hosting service" I would have to
start wondering why anyone would use a "heavy" application (web apps,
including electron, are in style) like Pidgin to connect to anything
other than Slack (the now dominate chat platform).  See how silly this
sounds?  If we were to follow this logic fallacy we should just give
up on the project.  We're not going to do that and we're not going to
give into the git/github mono culture either.

> Meanwhile you have explained to me that you believe in unicorns of your
> own: mythical contributors who long to work on your project so much,
> they won't mind Bitbucket and Mercurial, only to be allowed to provide
> you with high quality contributions. I wish you met many such contributors.

You can call them unicorns, we just give them a developer title.  They
do exist and with a code base as complicated as our is right now
dealing with abstractions across numerous proprietary protocols, it's
required.  For example, say someone wants to implement threaded
messages for slack/mattermost.  How many drive by contributors are
going to take the time to go through and learn how the core/ui is
split, devise a design that'll work, and then implement it in both
libpurple and at least one of our ui's...?  For what you're telling me
about people won't contribute because they can't spend the tens
minutes to learn the tiny differences between git and mercurial [1], I
can only assume that number is going to be zero.

To try to put a metaphor around the "i don't want to learn mercurial"
thing... You never hear people say "I don't want to use this car
because I use my car every day and I'm uncomfortable in anything
else."  It's like saying you can't drive a car with a floor mounted
gear shift because your daily car has it mounted on the steering
column.

Yet you hear this argument in these debates over and over again.  It's
become a self fulfilling prophecy.  People refuse to learn it because
it's different and in doing so never learn how similar they are.  They
get hung up on the object database and the "power it provides", and
the reflog, etc.  But what's under the hood doesn't matter, what
matters is the user interface and your interactions with it.  And in
the case of git and hg, they're extremely similar (see [1]).  But even
then, the git community knows the interface is bad, see cogito, tig,
and gitless.  Not to mention the git man page generator [2].  Yet,
people persist in insisting it's the best because it's popular.  It
blows my mind and is why you'll sometimes hear me refer to it as
Stockholm syndrome :)

> And no, I don't think it is about crowds of unwashed masses who would
> start to bother you with drive-by one-line stupid fixes. I think it is
> more about that first impression. People who insist on the minority VCS,
> who are not on GitHub, are suspicious to be one of those people.
> Opinionated, argumentative, difficult to cooperate with. I would
> hesitate to work with you, because you seem from distance like those
> people who have their own very strict and strange stylesheet (opening
> brace on the same line, except for "else"), etc. You know such people,
> do you?

If you've watched any of my streams, watched the State of Pidgin
video, or read the emails, you'd see I am not argumentative or
difficult to work with.  However I am opinionated, but I am
objectively opinionated.  I have been around for a long time, I have
worked through the problems (hopefully correctly, but 100% willing to
admit I'm wrong when I am), and am open to any suggestion if it makes
sense.

I did not comment on a mailing list thread by ignoring all of the
content in the thread and starting a new conversation about a topic
without trying to understand the problem being solved and while making
that argument provide minimal evidence to defend my argument.

As for the coding style guide.. They are amazing when done right.  Ask
any golang programmer where the tooling has made it automatic.  It's
amazing!!  So I guess you'll be disappointed to know that clang-format
is one of the next things on my list once the repository is split :)

>> There's nothing more than that.  Once we're in a position where we
>> can support those contributors, sure it'll be considered.
>
> That’s nonsense, if you are not willing to accept fast small
> contributions now, you will never be. There is either cathedral or
> bazaar, either you want to have GNU/Emacs or Linux kernel. Either you
> are willing to fast accept small contributions, hoping that something
> more substantial will come in future, or you require every patch to be a
> precious gem ready to be presented as a dissertation thesis. That is
> matter of opinion and not of the external circumstances, that position
> will never change. There is nothing wrong with building GNU/Emacs (or
> coreutils; did you try to contribute there?) with just few of your
> friends, but it is wrong not to have clear strategy of development, or
> to lie to yourself, that you want to have bazaar, when it is actually
> cathedral what you build. And yes, for cathedral, there is not much
> reason to have popular VCS. You could stay with Monotone, FWIW.

I never said we don't want drive by contributors.  I said we can't
support them *right now*.  Those are two completely different things.
If you bothered to watch the video or read all of the emails, you
would understand that we're trying to get the big ugly road blocks in
the project out of the way.  We're doing these now, when contributions
are low because it's easier for everyone.  It's almost like
bootstrapping a new project.  You have to get it to a point where it
is self sufficient.  We are *NOT* there.  Until we are, we have to
weigh every contribution that comes through and decide how much
support to give it.

>> But it's crap like this from the git-bros that are irritating as
>> hell.  Next thing I know you're going to be telling me that I'll
>> only get contributors if I enforce a requirement that contributors
>> must use a specific editor...
>
> Of course, don’t tell me that anybody is allowed to use anything else
> than vi (not vim, original BSD vi only with single-level undo)!
>
>> That aside, you still seem to be insisting that github is this magic
>> place where people just fix your stuff for you.  I would love to see
>> some real data on it from someone that makes this claim, but to
>> date, no one has been able to provide it.
>
> I don’t have numbers, just current experience. I took over maintenance
> of M2Crypto (the most complete Python bindings for OpenSSL) two years
> ago, which finally died when OSA died and even its bugzilla was shutdown
> (we lost quite number of bugs and patches that way). I am a big fan of
> host-your-own-server strategy (all my emails, calendars, addressbooks
> are in my OwnCloud on my VPS), so I had perfectly working set of gitweb
> + bugzilla on my own server. Not only some people refused to file a bug
> because they would have to create yet another stupid account, but mostly
> it seemed just didn’t know about new maintenance and expected the
> project to be just dead (although all contact information was available
> on M2Crypto’s PyPI page). As the final act of resignation, I have moved
> whole project to GitLab (https://gitlab.com/m2crypto/m2crypto/) and the
> situation started to change. Slowly but surely, number of issues from
> unknown reporters rises, and number of contributions rises as well
> (small, or not so small … port to OpenSSL 1.1.0 was mostly from somebody
> who just shown up with the patch). I am not completely happy, but it
> seems that this is the world we live in.

That's great!  I am genuinely happy that it worked out for you.  But
Pidgin is nothing like your project.  It's a complex spaghetti mess of
450,000 lines of C code (according to coverity) that is in a state of
moving from ad hoc OOP in C to structed OOP in C using GObject (this
was mentioned in the State of Pidgin video).  Until that is dealt
with, until there is documentation explaining the structure of the
project, until things are name spaced properly, until the code feels
like a single cohesive project (this will probably never be 100% but I
can dream!!), new contributors are going to have a very difficult and
frustrating experience.  Supporting them through that, while possible,
is a huge strain multiplied by that fact that we're trying to
eliminate as many of these issues as possible.

I'm not saying we won't support them, what I am saying is that with
the very limited resources we have to attack those problems.  We have
to make hard decisions on how to proceed.  All the while keeping in
mind that they're going to need help navigating the code, they're
going to get frustrated because they have to rewrite patches because
we have a more intimate knowledge of the code base, they're going to
tell us to move to github because they can't "do" mercurial.  All of
this is putting additional strain on those limited resources, slows
everything else down, and burns people out.  These are obviously
things we're trying to avoid and to do so, we have fix the underlying
problems before we start working on the cosmetic of fashionable
problems.

> Happy hacking!
>
> Matěj
>
> --
> https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> Quod fuimus, estis; quod sumus, vos eritis.
>

[1] https://confluence.atlassian.com/get-started-with-bitbucket/git-and-mercurial-commands-860009656.html
[2] https://git-man-page-generator.lokaltog.net/

-- 
Thanks,

--
Gary Kramlich <grim at reaperworld.com>