Hello,
I agree that a blind "ban them all right now" is not the way to go.
Now, the WMF by its own word aims to "provide the essential
infrastructure for free knowledge". Should this statement be taken
seriously, the foundation can not be light on the tools it chooses to
communicate with the community, and what tools it provides to addresses
the community needs.
Libre softwares are not perfect, for sure, they come with their own
caveats. Maybe (re)reading When Free Software Isn't (Practically)
Superior
<https://www.gnu.org/philosophy/when-free-software-isnt-practically-superior.html>
might worth our time here.
The question is not "will we meet issues if we use libre softwares?" Of
course we will! And using non-libre softwares, we would too. The point
is, on the long run, are we serious about "providing the essential
infrastructure for free knowledge". If that the case, it won't happen by
dodging all the difficulties that must be overcome to build such an
infrastructure. This won't be achieved without sometime going through
long hours of tedious learning by experience. If we coordinate well
however, we can leverage on each other successes and failures, without
giving exclusive privileges of this commonality to some exogenous actor.
Yes, sometime it might be easier on the short-term to take an
out-of-the-box non-libre solution – although there is guarantee in that
either. Sometime you will be better served on the short term with a
libre software that you deploy alone in your corner of the cyberspace.
Sometimes you'll be better served with a libre software that will be
deployed, maintained and improved with the help some commercial support.
Sometimes it might worth to have your own inhouse team to do all that
work on some specific libre software stacks that match your needs.
Cheers
Le 15/02/2021 à 02:08, Łukasz Garczewski a écrit :
With respect, Fae, if you're going to propose
banning an existing
solution, it is on you to propose a suitable alternative or at least a
process to find it before the ban takes effect.
I write this as a signatory of Free Software Foundation Europe's
Public Money? Public Code open letter
<https://publiccode.eu/openletter/>. I am wholeheartedly a proponent
of open source software.
At the same time, I am a firm believer in using the best available
tool for the job.
Our mission is too important to hold ourselves back at every step due
to a noble but often unrealistic wish to use open source solutions for
everything we do.
Last year, because of my drive to use proper open source solutions,
WMPL wasted hours and hours of staff time (mostly mine) and a not
insignificant amount of members' time because:
* Zeus, a widely used, cryptographically secure voting system is
impossible to setup and maintain and has very sparse documentation,
* CiviCRM, the premier open source CRM solution for NGOs, refuses to
work correctly after the Wordpress installation is moved to a new
URL, and documentation isn't helpful.
To my knowledge there are no suitable open source options that would
be easy-to-use and robust enough to support our needs in both cases
and be comparable to commercial counterparts.
I have wasted a ton of time (and therefore WMPL money), before I
decided to use state-of-the-art commercial solutions for the needs
described above. Don't be like me. Don't make other people think & act
like I did. Be smarter.
Should we use an _equivalent_ open source solution when one is
available? Yes.
Should we have a public list of open source tools needed? Yes.
Should we use programmes such as Google Summer of Code to build those
tools? Yes.
Should we waste time using sub-par solutions or doing work manually?
Hell no.
*So here's a constructive alternative idea:*
* Let's gather the needs and use cases for tools used by WMF and
affiliates,
* Let's build a list of potential open source replacements and map
what features are missing,
* Let's put the word out that we're looking for open source
replacements where there are none available,
* Let's embed Wikimedia liaisons in key open source projects to
ensure our needs and use cases are addressed promptly,
* Let's use initiatives such as Summer of Code to kickstart building
some of these tools.
I acknowledge the above is much harder to do than instituting a ban
via community consensus. It is, however, a much more productive
approach and will get us to your desired state eventually, and without
sabotaging the work that needs to happen in the meantime.
Oh, and in case anybody's wondering why we can't build these tools
in-house:
We could but really, really shouldn't. MediaWiki and the wider
Wikimedia tech infrastructure is still in need of huge improvements.
It would be really unwise to distract WMF's development and product
teams from these goals by requesting they build standard communication
or reporting tools.
On Sat, Feb 13, 2021 at 4:42 PM Fæ <faewik(a)gmail.com
<mailto:faewik@gmail.com>> wrote:
As a consequence of the promotion of a Google forms based survey this
week by a WMF representative, a proposal on Wikimedia Commons has been
started to ban the promotion of surveys which rely on third party
sites like Google Forms.[1]
Launched today, but already it appears likely that this proposal will
have a consensus to support. Considering that Commons is one of our
largest Wikimedia projects, there are potential repercussions of
banning the on-wiki promotion of surveys which use Google products or
other closed source third party products like SurveyMonkey.
Feedback is most welcome on the proposal discussion, or on this list
for handling impact, solutions, recommended alternatives that already
exist, or the future role of the WMF to support research and surveys
for the WMF and affiliates by using forking open source software and
self-hosting and self-managing data "locally".
Links
1.
https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Use_of_of…
<https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Use_of_off-wiki_surveys_using_third-party_tools>
Thanks
Fae
--
faewik(a)gmail.com <mailto:faewik@gmail.com>
https://commons.wikimedia.org/wiki/User:Fae
<https://commons.wikimedia.org/wiki/User:Fae>
#WearAMask
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
<https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines> and
https://meta.wikimedia.org/wiki/Wikimedia-l
<https://meta.wikimedia.org/wiki/Wikimedia-l>
New messages to: Wikimedia-l(a)lists.wikimedia.org
<mailto:Wikimedia-l@lists.wikimedia.org>
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>,
<mailto:wikimedia-l-request@lists.wikimedia.org
<mailto:wikimedia-l-request@lists.wikimedia.org>?subject=unsubscribe>
--
Z poważaniem · Kind regards
Łukasz Garczewski
Dyrektor ds. operacyjnych · Chief Operating Officer
Wikimedia Polska
tel: +48 601 827 937
e-mail: lukasz.garczewski(a)wikimedia.pl
<mailto:lukasz.garczewski@wikimedia.pl>
<http://wikimedia.pl>
Wesprzyj wolną wiedzę!Przekaż 1% podatku lub wpłać darowiznę na rzecz
Wikipedii <https://wikimedia.pl/>
ul. Tuwima 95, pok. 15 Łódź, Polska
KRS 0000244732
NIP 728-25-97-388
wikimedia.pl <http://wikimedia.pl>
Informacje na temat przetwarzania znajdują się w Polityce Prywatności
<https://pl.wikimedia.org/wiki/Polityka_prywatno%C5%9Bci>. Kontakt:
rodo(a)wikimedia.pl <mailto:rodo@wikimedia.pl>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>