<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">Hi Devin!</div><div class="gmail_extra"><br><div class="gmail_quote">On 3 April 2016 at 21:07, Devin Ulibarri <span dir="ltr"><<a href="mailto:devin@ulibarri.website" target="_blank">devin@ulibarri.website</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="overflow:hidden">I have been following this thread. These are my two cents.</div></blockquote><div><br></div><div>Thanks for speaking up - you say you don't have so much tech know-how, but considering policy doesn't require it and I'm glad to discuss this with you :) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="overflow:hidden">If it were me, I would have opted to keep everything on a server within</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="overflow:hidden">
Sugar Labs' community's control.<br></div></blockquote><div><br></div><div>This is a very reasonable proposal - and I had considered proposing this myself, before I proposed consolidating on Github, but I didn't explain why, so this is a good moment to :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="overflow:hidden">
Here is why:<br>
1. Control. The community would be able to do what they wish with their<br>
data. (the other benefits really come from this one)<br></div></blockquote><div><br></div><div>Most of the data on Github servers, and all the data that is uploaded to the servers by the community, is available to the community in full and unrestricted (and raw) form via the Github API.</div><div><br></div><div>There is a software freedom problem with <a href="http://github.com">github.com</a>, since it provides proprietary javascript software to run on your browser; but for me this software is pretty trivial and personally I don't mind it.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="overflow:hidden">
2. Avoid "Lock in". Probably, now we think "we have the code, we can<br>
pack our bags at any time we want", but as we use 3rd party services we<br>
are investing more and more--and would probably be reluctant to move if<br>
GitHub were to "go rogue" (advertisements, privacy problems, who knows<br>
what they will think of next problems). Instead, we would probably just<br>
adapt and adapt until--suddenly--the atmosphere became unbearable.<br></div></blockquote><div><br></div><div>SourceForge.org is exactly the nightmare scenario you describe - <a href="http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/">http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/</a> - and Github is widely admired in the floss community as an antithesis of sourceforge. Another large host of libre-software projects, <a href="http://code.google.com">code.google.com</a>, was shut down in the last year, with tools provided to migrate to Github. <br></div><div><br></div><div>The nature of git and the github API is that migrating to another system is easy enough, and while it is certainly possible that they could just turn everything off and we'd lose data stored only on their servers, it seems extremely unlikely to me that people of good will would do such a thing. I expect that if and when Github is shut down, it will provide tools to migrate. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="overflow:hidden">
3. It occurs to me that, if we maintain an option to issue bug reports<br>
anonymously (or even under an pseudonym) that we would be protecting<br>
data of minors. I do not want to contribute much more to a world where<br>
minors must identify themselves and thus all they say and do on the<br>
internet at 13 yrs. old is available to people to see when they are 40<br>
yrs. old.<br></div></blockquote><div><br></div><div>Github allows pseudonym accounts :)</div><div><br></div><div><br></div><div>So, why do I not recommend that Sugar is developed using infrastructure that Sugar Labs operates with free software? </div><div><br></div><div>Well, after a couple weeks poking around Sugar Labs, my subjective perspective is that the Sugar project is slowly drying up - sadly! :( <br></div><div><br></div><div>On the issue of issue tracking, James noted that we do not currently see any bug reports on the existing issue tracker. This could be an indicator of what I generally perceive, but actually I think this may be because all new tickets are being held for moderation by Samuel Cantero; I'll email the system list about this in a moment.<br></div><div><br></div><div>However, here are 2 graphs from <a href="https://activities.sugarlabs.org/en-US/statistics">https://activities.sugarlabs.org/en-US/statistics</a> that show a collapse in the number of downloads of Activities from ASLO, falling by 90% over the last 3 years:</div><div><br></div><div><br></div><div><img src="cid:ii_153def1c14ea36e3" alt="Inline images 2" width="562" height="156"><img src="cid:ii_153def1c2616f3ee" alt="Inline images 1" width="562" height="159"><br></div><div><br></div><div>(<a href="https://imgur.com/a/tyXS5">https://imgur.com/a/tyXS5</a>)<br></div><div><br></div><div>Samson prompted me to search for these graphs when, in <a href="http://lists.sugarlabs.org/archive/sugar-devel/2016-January/051258.html">http://lists.sugarlabs.org/archive/sugar-devel/2016-January/051258.html</a> , he said that "weekly downloads is falling like the price of crude oil" (lol :)<br></div><div><br></div><div>So I think it is urgent that the Sugar community begins to grow again.</div><div><br></div><div>The Sugar project doesn't exist in a vacuum, it exists in a social context of the wider floss community, and that community is - for now - overwhelmingly using Github for project hosting and issue tracker. <br></div><div><br></div><div><div>I think that using the same infrastructure as the majority of the rest of the floss community is an effective strategy to meet that goal; and I think that using our own infrastructure will make the project insular and deter growth. </div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="overflow:hidden">
This all being said, I have no technical know-how to fix the broken<br>
system. And the reason I use GitHub is because that was the system that<br>
was introduced to me. If the software on the Sugar server gets fixed, I<br>
will happily participate in that one.<br></div></blockquote><div><br></div><div>Well, this is sort of the point. The software on the sugar server is functioning fine (modulo a moderation queue misconfiguration :) and there was already an effort to move to Github. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="overflow:hidden">
Well, 4. If we can fix the problem and try to improve whatever software<br>
libre we are running server-side, we will be contributing to the<br>
advancement of software libre tools for the entire community (even if we<br>
are just filing bug reports, etc).<br></div></blockquote><div><br></div><div>Sugar is in the business of developing educational application-level software, and not wifi driver firmware software, nor software project hosting software. <br></div><div><br></div></div><div><div>I acknowledge that it is somewhat contradictory to advocate for software freedom as a general principle, yet use proprietary software. I've been a member of the floss community for about 17 years now, and myself and almost all software freedom advocates that I've met all around the world do embrace that contradiction to some extent. </div><div><br></div><div>Today there are a very few who use only X60/X200 laptops with libreboot and zero proprietary software installed, and browse the web with GNU IceCat so that no proprietary javascript programs are executed; they either work at FSF, Conservancy, or develop libreboot and sell such laptops :) I would be happy to hear otherwise, but I suspect that no-one contributing to Sugar uses only libre software. </div><div><br></div><div>I admit that I am right now typing this email into proprietary javascript program - GMail - on a Mac that runs Mac OS X. I explain this by saying that I have various needs, including for freedom, but also for convenience, community, and focus; and I'm willing to engage in strategies that meet some needs less than 100% in order to meet all needs somewhat. </div></div><div><br></div><div>I recommend this approach of considering the trade-offs to Sugar Labs, and being willing to compromise a little on software freedom where it matter less to gain other important capabilities. I offer that this is similar to how the XO laptops require proprietary firmware to use wifi. </div><div><br></div><div>If the need for freedom and autonomy in project hosting is strong, and alternatives to Github are sought, I recommend <a href="http://www.fossil-scm.org">http://www.fossil-scm.org</a> :)</div><div><br></div>-- <br><div>Cheers<br>Dave</div>
</div></div>