State of Pidgin: Reverse Engineering FUD

[Gary Kramlich]

Greetings Programs!

If you have not yet seen the introduction email with a subject of "State of
Pidgin: Introduction", please go read it first.

On a few occasions now, I have had individuals contact me in regards to
wanting to contribute to the project but are weary of the legality of some
of our code.  The code in question is of course the proprietary protocol
implementations.

It has also been brought to my attention that employers won't allow their
employees to contribute due to the gray area that our protocol plugins
exist in as well.  This is unfortunate as it starts to limit our
contributor base which as we're all aware could use

We've skirted around these concerns in the past, but I would like to
honestly put them behind us.  What I am proposing is theoretically simple,
but a kind of a logistical nightmare.  What I would like to see is
libpurple ship with just open standard protocols in tree.  That is IRC,
SILC, XMPP, Matrix.org and maybe Zephyr which is simple enough.  We would
then put all of the proprietary protocols into their own repositories which
creates the logistical nightmare.

The first pass to deal with the logistical nightmare would be to release
the protocols to our repositories on packagecloud.io and bintray.com.  Both
of which are not currently in use.  This gives us the extra benefit of
letting us release updates to them immediately when something changes and
users have a simple upgrade path; use their package manager.  We can even
trigger builds in Bamboo or any other CI when libpurple updates to make
sure they're not broken.  Having the This would also allow us to remove
Zephyr from the mainline tree if we so desired.

The second pass would be to have someone finish any one of the attempts at
a plugin website/store.  With the existing infrastructure of the CI system
and the package repositories this task becomes much much easier as the site
is basically a database with a frontend.

I have a lot more thoughts on the matter, but this should be enough to get
the discussing rolling for now.

Please discuss.

Thanks,

--
Gary Kramlich <grim at reaperworld.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20171003/e61303aa/attachment.html>