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@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_off-wiki_surveys_using_third-party_tools <https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Use_of_off-wiki_surveys_using_third-party_tools> Thanks Fae -- faewik@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@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@wikimedia.pl mailto:lukasz.garczewski@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe