[Chapter-delegates] make simple things complex again!

Madhav Negi M.J.Negi at ieee.org
Sat Jan 20 08:38:34 PST 2024


Hey folks, interesting conversation and my two cents.
Std. disclaimers - i am not trying to teach grandma to suck eggs.
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)
Recapping keywords/issues from previous emails reads like requirements.
1. Global  scale
2. our objectives -varying tactical initiatives locally, but a core
strategic mission.
3.  our complicated distributed, loosely coupled  structure and Community
nature.
4. cost, reputation etc.
5. Need to adhere to global data privacy and protection trends, clear
member Identity & access.
6. Fit for our purpose, features, functionality, ease of use, etc.


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.
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.
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.
3. Today the problem of a community collaboration system, at scale and
reasonable cost and data protection and privacy is a solved problem.
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 (everybody at isoc.org)
etc. at a *global* scale. e.g. - 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 at Google etc.

Almost any and all serious software are  converging on must have basic
feature set.
e.g. any tech support forum supports communities, discussions, document
uploading, search etc.

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.
Not saying operations are trivial. Obviously current pain is a result of
inefficient operations (read community collaboration) backbone.
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.

having said the above,
IMHO Facebook at 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.


cheers,

PS: Kindly pardon typo errors. I am visually impaired post covid and still
not mastered my tools.


Madhav *Negi*,
Hyderabad Chapter.


On Sat, Jan 20, 2024 at 3:45 PM Christian de Larrinaga via
Chapter-delegates <chapter-delegates at elists.isoc.org> wrote:

> inline below
>
> Andrew Sullivan via Chapter-delegates <chapter-delegates at elists.isoc.org>
> writes:
>
> > Hi,
> >
> > On Wed, Jan 17, 2024 at 12:19:06PM +0000, Christian de Larrinaga wrote:
> >>
> >>For instance the procurement you describe is "singular" perhaps "top
> >>down" where requirements are taken as a snapshot of features that are
> >>"complex" from a centralised perspective to a "set of requirements"
> >>rather than universal, inclusive and iterative over time. The first
> >>model is fair enough for a contiguous organisation.
> >
> > It is also the only one we can use in order to write a contract with
> > another party for a service that we can use.  That is true
> > irrespective of the software licenses involved.  Ultimately, one has
> > to pick one service in order to have one database.  And one member
> > database, along with some associated services to those members, is
> > ultimately what we have to get from any possible AMS.
> >
> >>Yet the community that you are trying to assist often sees itself as a
> >>collection of independent entities globally distributed coalescing
> >>around a common principle and a set of shared objectives. But having
> >>to maintain their own ways, communities and legal requirements locally.
> >
> > And that is true.  Chapters are indeed independent entities that are,
> > essentially, affiliated with the Internet Society according to a
> > fairly small number of governing principles.  Different chapters have
> > different priorities.  Some are made up of technical enthusiasts.
> > Others are much more focussed on access, or governance issues, or a
> > host of other things related to the Internet.  This is part of why the
> > independence of chapters is important.
> >
> >>I remember ISOC NL perhaps with NL Net help working on an open source
> >>chapter / ISOC community project with version control, branching and
> >>with infrastructure services such as DNS, hosting, application
> >>deployment and data management for membership services and so on. I got
> >>the impression ISOC ignored this. Perhaps a "not invented here" issue?
> >
> > I am not familiar with that work, so I can't comment on it,
>
> ISOC NL formally approached ISOC back in 2018 (from memory)
>
> > but the
> > issue is certainly not a "not invented here" issue from the point of
> > view of the Internet Society.  Fonteva, or any other system, wasn't
> > invented here either.  We don't have the technical staff necessary to
> > undertake such an invention, to be frank, much less the time to work
> > on it.
> >
>
> invention? But there are a lot of options already out there which with a
> relatively
> small amount of ISOC financial support could if necessary be branched by
> those
> who do have those skills.
>
> >>A singular model is not comfortable for a group who like to "eat our own
> dogfood"! As crazy as that
> >>might sound to some.
> >
> > I think you are eliding a basic issue here, however, which is that
> > we're not talking about one group, but many.  What looks like tasty
> > dogfood to one group of people is an unacceptable burden to others.
>
> which sort of confirms the point.
>
> > And the Internet Society staff have to provide support to all of those
> > groups.
>
> Support yes. But determine / impose a solution ? is that what you mean
> by support?
>
>
> > This naturally means that everyone will not be satisfied by
> > any choice. Best regards,
> >
>
> So we agree! :-)
>
> best C
> --
> Christian de Larrinaga
> _______________________________________________
> As an Internet Society Chapter Officer you are automatically subscribed
> to this list, which is regularly synchronized with the Internet Society
> Chapter Portal (AMS):
> https://admin.internetsociety.org/622619/User/Login
> View the Internet Society Code of Conduct:
> https://www.internetsociety.org/become-a-member/code-of-conduct/
>


-- 

regards
Madhav *Negi*,
2021 Interim Chair, Industrial Electronics Society, IEEE Hyderabad Section
2016 and 2018 IEEE MGA awardee for Hyderabad Section Outstanding Section
Membership Recruitment & Retention Performance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://elists.isoc.org/mailman/private/chapter-delegates/attachments/20240120/fede2661/attachment.htm>


More information about the Chapter-delegates mailing list