<div dir="ltr"><div dir="ltr">Hey folks, interesting conversation and my two cents. <div>Std. disclaimers - i am not trying to teach grandma to suck eggs.</div><div>my observation from working as a volunteer and as an employee of large scale ( > 100,000 employee/member) and a student of organizational design (communities, for-profit, not-for-profit etc)</div><div>Recapping keywords/issues from previous emails reads like requirements. </div><div>1. Global  scale</div><div>2. our objectives -<span style="color:initial">varying tactical initiatives locally, but a core strategic mission. </span></div><div>3.  our complicated distributed, loosely coupled  structure and Community nature.</div><div>4. cost, reputation etc.</div><div>5. Need to adhere to global data privacy and protection trends, clear member Identity & access.</div><div>6. Fit for our purpose, features, functionality, ease of use, etc. </div><div><br></div><div><br></div><div>IMHO taking a 50000 feet or 15000 Mtrs  perspective and reiterating what we all with our collective centuries of experience have already faced and resolved. </div><div>1. our core strategic focus should lay precedence to operational distractions like building our own or customizet-o-our-own (apparently unique) requirements.  - like any successful global organization. </div><div>e.g. Microsoft uses SAP to manage operations, which in turn worked atop Oracle Database.  - point - they focussed on their value add and used the best of breed , off the shelf for operations. and still beat the S*** out of the competition. </div><div>3. Today the problem of a community collaboration system, at scale and reasonable cost and data protection and privacy is a solved problem. </div><div>With required features like supporting Communities, global addressbook and member directory, Single SignOn,  simple projects trackers,  knowledge management (cloud spaces like google drive etc), collaobration workspaces - realtime, async, or virtual sync, branded email domain (<a href="mailto:everybody@isoc.org">everybody@isoc.org</a>) etc. at a *global* scale. e.g.<span style="color:initial"> - Facebook at Work (most of us know the interface), IEEE Collabratec built on top of Yammer (until MS bought it and morphed it into Viva Engagement) or Apps@Google etc.</span></div><div><span style="color:initial"> </span></div><div><span style="color:initial">Almost any and all serious software are  converging on must have basic feature set. </span></div><div><span style="color:initial">e.g. any tech support forum supports communities, discussions, document uploading, search etc. </span></div><div><span style="color:initial"><br></span></div><div><span style="color:initial">the proposition - being, like Microsoft (like it or not!  :-) ), use off the shelf components for running our operations allowing and freeing us to focus on our Mission.  </span></div><div>Not saying operations are trivial. Obviously current pain is a result of </div><div><span style="color:initial">inefficient operations (read community collaboration) backbone. </span></div><div><span style="color:initial">Lets choose the best off the shelf,(ignoring the cons as every decision will have them) pay the reasonable cost and not have to revisit the issue for the next 5 years. No matter what is chosen, adoption of the solution will take time. </span></div><div><span style="color:initial"><br></span></div><div><span style="color:initial">having said the above, </span></div><div><span style="color:initial">IMHO Facebook@Work ecosystem matches our Community driven  structure, focus and thus our requirements. I have no idea of the costs involved. But if it helps our focus on Mission , its worth paying the price. </span></div><div><span style="color:initial"><br></span></div><div><span style="color:initial"><br></span></div><div><span style="color:initial">cheers, </span></div><div><span style="color:initial"><br></span></div><div><span style="color:initial">PS: Kindly pardon typo errors. I am visually impaired post covid and still not mastered my tools. </span></div><div><span style="color:initial"><br></span></div><div><span style="color:initial"><br></span></div><div><span style="color:initial">Madhav <u style="font-weight:bold">Negi</u>, </span></div><div><span style="color:initial">Hyderabad Chapter. </span></div><div><span style="color:initial"><br></span></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 20, 2024 at 3:45 PM Christian de Larrinaga via Chapter-delegates <<a href="mailto:chapter-delegates@elists.isoc.org">chapter-delegates@elists.isoc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">inline below<br>
<br>
Andrew Sullivan via Chapter-delegates <<a href="mailto:chapter-delegates@elists.isoc.org" target="_blank">chapter-delegates@elists.isoc.org</a>> writes:<br>
<br>
> Hi,<br>
><br>
> On Wed, Jan 17, 2024 at 12:19:06PM +0000, Christian de Larrinaga wrote:<br>
>><br>
>>For instance the procurement you describe is "singular" perhaps "top<br>
>>down" where requirements are taken as a snapshot of features that are<br>
>>"complex" from a centralised perspective to a "set of requirements"<br>
>>rather than universal, inclusive and iterative over time. The first<br>
>>model is fair enough for a contiguous organisation.<br>
><br>
> It is also the only one we can use in order to write a contract with<br>
> another party for a service that we can use.  That is true<br>
> irrespective of the software licenses involved.  Ultimately, one has<br>
> to pick one service in order to have one database.  And one member<br>
> database, along with some associated services to those members, is<br>
> ultimately what we have to get from any possible AMS.<br>
><br>
>>Yet the community that you are trying to assist often sees itself as a<br>
>>collection of independent entities globally distributed coalescing<br>
>>around a common principle and a set of shared objectives. But having<br>
>>to maintain their own ways, communities and legal requirements locally.<br>
><br>
> And that is true.  Chapters are indeed independent entities that are,<br>
> essentially, affiliated with the Internet Society according to a<br>
> fairly small number of governing principles.  Different chapters have<br>
> different priorities.  Some are made up of technical enthusiasts.<br>
> Others are much more focussed on access, or governance issues, or a<br>
> host of other things related to the Internet.  This is part of why the<br>
> independence of chapters is important.<br>
><br>
>>I remember ISOC NL perhaps with NL Net help working on an open source<br>
>>chapter / ISOC community project with version control, branching and<br>
>>with infrastructure services such as DNS, hosting, application<br>
>>deployment and data management for membership services and so on. I got<br>
>>the impression ISOC ignored this. Perhaps a "not invented here" issue?<br>
><br>
> I am not familiar with that work, so I can't comment on it,<br>
<br>
ISOC NL formally approached ISOC back in 2018 (from memory)<br>
<br>
> but the<br>
> issue is certainly not a "not invented here" issue from the point of<br>
> view of the Internet Society.  Fonteva, or any other system, wasn't<br>
> invented here either.  We don't have the technical staff necessary to<br>
> undertake such an invention, to be frank, much less the time to work<br>
> on it.<br>
><br>
<br>
invention? But there are a lot of options already out there which with a relatively<br>
small amount of ISOC financial support could if necessary be branched by those<br>
who do have those skills. <br>
<br>
>>A singular model is not comfortable for a group who like to "eat our own dogfood"! As crazy as that<br>
>>might sound to some.<br>
><br>
> I think you are eliding a basic issue here, however, which is that<br>
> we're not talking about one group, but many.  What looks like tasty<br>
> dogfood to one group of people is an unacceptable burden to others. <br>
<br>
which sort of confirms the point.<br>
<br>
> And the Internet Society staff have to provide support to all of those<br>
> groups.<br>
<br>
Support yes. But determine / impose a solution ? is that what you mean<br>
by support?<br>
<br>
<br>
> This naturally means that everyone will not be satisfied by<br>
> any choice. Best regards,<br>
><br>
<br>
So we agree! :-) <br>
<br>
best C<br>
-- <br>
Christian de Larrinaga <br>
_______________________________________________<br>
As an Internet Society Chapter Officer you are automatically subscribed<br>
to this list, which is regularly synchronized with the Internet Society Chapter Portal (AMS):<br>
<a href="https://admin.internetsociety.org/622619/User/Login" rel="noreferrer" target="_blank">https://admin.internetsociety.org/622619/User/Login</a><br>
View the Internet Society Code of Conduct: <a href="https://www.internetsociety.org/become-a-member/code-of-conduct/" rel="noreferrer" target="_blank">https://www.internetsociety.org/become-a-member/code-of-conduct/</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><br>regards<br>Madhav <b>Negi</b>, <br>2021 Interim Chair, Industrial Electronics Society, IEEE Hyderabad Section<br>2016 and 2018 IEEE MGA awardee for Hyderabad Section Outstanding Section Membership Recruitment & Retention Performance<br></div></div>