<div dir="auto"><div dir="auto"></div>I agree with Rick that Free Software organizations, and that includes OSI, should make use of entirely free software run for them by a non-profit that contributes its modifications back to the projects. But I don't know who that would be today. Should we be putting together crowdfunding to create such a thing? I would certainly pay for such a service for my company and personal use.<div dir="auto"><br></div><div dir="auto">Thanks</div><div dir="auto"><br></div><div dir="auto">Bruce<br><div dir="auto"><br></div><div dir="auto"><br><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Jun 4, 2019, 17:18 Rick Moen <<a href="mailto:rick@linuxmafia.com" target="_blank" rel="noreferrer">rick@linuxmafia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Luis Villa (<a href="mailto:luis@lu.is" rel="noreferrer noreferrer" target="_blank">luis@lu.is</a>):<br>
<br>
> People who have asked questions of the list have certainly been told that,<br>
> both explicitly and by implication ("well, it isn't written down anywhere<br>
> else, so...") Usually politely, but polite terrible news is still terrible<br>
> news.<br>
<br>
That's regrettable and it would certainly be better to be able to point<br>
to a summary in some suitable non-mailing-list ticket. As with the SVLUG <br>
example, there is a tendency to rely on an existing tool for unsuitable<br>
uses, if that's what is on hand, and I imagine people get lazy and don't<br>
want to spend time getting and providing the right per-message<br>
Pipermail archive URL.<br>
<br>
Well, at least this was not an OSI statement or (I gather) from an OSI<br>
Board member, which was the impression I got from your initial footnote.<br>
<br>
> <a href="https://github.com/OpenSourceOrg/" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/OpenSourceOrg/</a> has existed, and been relied on, for some<br>
> time. And that's purely proprietary.<br>
<br>
Although past regrettable decisions are, in my opinion, best not used to<br>
justify future ones, I have the pleasure today of bringing good news: <br>
<br>
The proprietary GitHub service and the theoretically open source &<br>
self-hostable but extremely ponderous and overengineered GitLab codebase<br>
have, for some years, had excellent, modestly scoped, open source<br>
alternative codebases, fully suitable for self-hosting and devoid of bloat. <br>
In particular, _Gitea_ is excellent and increasingly in use by Linux<br>
distributions for their own code repositories, in managing their software<br>
development teams. (If you want an example: Devuan Project. There are<br>
others.)<br>
<br>
<a href="https://gitea.io/" rel="noreferrer noreferrer noreferrer" target="_blank">https://gitea.io/</a><br>
<br>
So, today's the day OSI can start migrating that repo off proprietary<br>
software, and onto something less horribly overfeatured than is<br>
Microsoft's GitHub service, to boot, on any OSI static IP.<br>
(Administrative burden, you say? But this isn't corporate bloatware, so<br>
please check the Gitea docs, and you'll see there's rather little.)<br>
<br>
<br>
> More generally, SaaS is a massive channel for open source these days, and<br>
> the org has very limited organizational bandwidth. It would seem odd to<br>
> insist on both avoiding one of (the?) predominant open source distribution<br>
> model, and imposing overhead on the org.<br>
<br>
Is is not the least bit odd to model the suitability of open source to<br>
be in control of one's computing infrastructure -- the way businesses<br>
control business risk by deploying autonomous open source -- by doing so. <br>
(Example: A year from now, Civilized Discourse Construction Kit, Inc.<br>
advises that it's shutting down its free hosting. Is OSI able and <br>
prepared to migrate everything? To where? Uh-oh. Yes, theoretically <br>
the Discourse Web-forum software is open source hence migratable, but <br>
in practice it's about as vendor-locked-in as is GitLab data.)<br>
<br>
On the other hand, it's entirely impossible to compete with the zero<br>
administrative overhead of outsourcing to third-party hosted software,<br>
so if that's the criterion OSI wants to apply, then outsourcing will<br>
automatically win, every time.</blockquote></div></div></div></div></div>