Profile

Cover photo
sankarshan mukhopadhyay
Lives in Bengaluru
117,458 views
AboutPostsCollections

Stream

sankarshan mukhopadhyay

Shared publicly  - 
 
This morning I was slightly amused with the CfP for the OpenStack meeting (cf. https://twitter.com/sankarshan/status/617927591836655616) The CfP, which is available from https://docs.google.com/forms/d/1bBehzshHhVuwdH2XrX3O9wsLb16mEcSK3fFO6yrJoxI/viewform?c=0&w=1 states "Request to Speakers: Please submit your talk which is in true spirits of open source community in simple terms avoid product pitch & demo/talk on proprietary components of OpenStack. Duration of Talk is 30 minutes"

I am amused because it misses breaking the sentence up (eg. "Please submit your talk which is in true spirits of open source community. In simple terms, avoid product pitch & demo/talk on proprietary components of OpenStack". I am puzzled because it uses a phrase that is ill-understood and less easily defined "in true spirits of open source community". 

It would be useful to recall that the PyCon India team had an experience during a previous iteration and had to step up and address this. The result can be read in the CfP, specifically (a) Proposal content shouldn't have company name through out the content. Mention of employer is allowed only in the beginning of the content (presentation/pdf). and (b) Background image/wallpaper shouldn't contain company name/logos (see. https://in.pycon.org/cfp/pycon-india-2015/proposals/)

Being able to clearly and precisely articulate the demands from the organizer is a big first step towards ensuring a way to weed out submissions deemed "undesirable". Creative phrasing like 'true spirits' and so forth make the analysis subjective and hence cause issues.
1
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
 
I would challenge the "BSD Cathedral" premise by saying that what really happened in that particular logical thread is that the best of the best BSD hackers had already been strip-mined from the development team, working at companies like Sun Microsystems, NetApp, etc.  That's not to say that all good BSD hackers were off the market, but enough were that it mattered.  Linux, by contrast, was organically building its stable of the best of the best, and when Red Hat hired many of them (with generous pre-IPO stock grants) both the GPL and Red Hat's liberal employee agreements (which really do protect and actually encourages continued participation in the open source community) meant that Linux lost nothing when Red Hat went public.  Thus, the BSD community suffered a Silicon Valley zero-sum game, whereas Linux enjoyed a GPL-enabled positive-sum game.

I very much agree that the legal issues around BSD were also crucial for wrecking its potential first-mover advantages in the open source OS realm.
If you use a free and open source operating system, it's almost certainly based on the Linux kernel and GNU software. But these were not the first freely redistributable platforms, nor were they the most professional or widely commercialized. The Berkeley Software Distribution, or BSD, beat GNU/Linux on all of these counts. So why has BSD been consigned to the margins of the open source ecosystem, while GNU/Linux distributions rose to fantastic p...
5 comments on original post
1
2
Kartik Singhal's profile photoNandan Vaidya's profile photo
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
[This is the long-form version of my #fudconin  spiel]

While responding to the CfP for FUDCon.in 2015 I took a bit of time to think whether it would be a nice thing to talk about. All things considered, The Fedora Project has been a place for some great and continuing friendships and gently peeling apart the existing ways is not the best thing to do at a party.

Here's what the publicly available abstract for "Community Architecture - a different perspective" read as:

"The Fedora Community in India has evolved through a number of iterations of community building. The constant theme has been to demand a strong focus on "making". Continuing with the hacker principles which are typical to any Free and Open Source Software Community, the diverse opportunities within The Fedora Project offers an unique set of entry-points to all participants. This session proposal intends to investigate the existing approaches and generate some discussion around new methods to build a community of excellence."

See more at: http://fudconin15.shdlr.com/grid#sthash.YBHvSz04.dpuf

There's a somewhat pragmatic reason to this approach. I've started to notice patterns across various communities I have dipped a toe into. And I believe that these patterns are not conducive to creating excellent and vibrant communities. To begin to understand and deconstruct these patterns it is useful to look back within the community I've seen from close - the Fedora Community in India. The community has evolved through "cycles of objectives". The application of the design principle of 'form follows function' can be understood by investigation of the cycles.

During the period of the first FUDCon (coinciding with the LinuxAsia conference), the goal was to create an awareness. Those who have been around would remember that the usage/awareness of the 'Fedora' distribution was not specifically high. And the methods selected for outreach were standard, well-tested and known to produce adequate results - installation fests and workshops; sprints across specific well understood areas (viz. translation and packaging etc); working in small numbers with specific interest groups and so forth. The good parts of these efforts are seen today as contributors who have stayed on and grown into established personalities within the larger project. However, there are also a couple of mistakes which we ended up doing. Two of which can be called out - (a) we limited our focus to 'Fedora as an operating system' (or, download/obtain and install Fedora and then use it); (b) we depended too much on free distribution of media (or, distribution of binary bits via Freemedia and similar). The compounded effect of these is that we continue to see a high number of requests for Freemedia Project out of India and, we put more stress on the hubs to feed content to the spokes. The altruism demanded by the Freemedia project has in fact prevented us from actively pursuing other means of making bits available. There was a point in time when we tried to build local mirrors (which fell apart fairly quickly). But aside from these, we seem to receive some comfort that a method from the earliest days of FOSS would continue to serve our purpose even if we scaled up.

This brings us to the second FUDCon in 2011. By this point the focus had moved to on-boarding participants across a wider spectrum of projects viz. i18n, QA/Testing, more SIGs, Security, Design, Spins etc. The gradual availability of the askbot based infrastructure provided an interesting alternative to mailing lists as the only means of communication and collaboration. The Fedora Ambassador teams had put together a reasonably simple method to on-board new Ambassadors and all these "low-floor; wide-shelf" approach did create a mix of new contributors across the breadth of The Fedora Project. The mistakes which deserve to be highlighted are (a) that there were far too many things to focus upon and (b) we did not have enough mentors and coaches who were strong presence in those projects to drive an increase in adoption and contribution. I also feel that we didn't do enough with the askbot content to make it a valuable resource for the first time user. Letting the community sprawl around a few prolific posters was a mistake in itself.

Taking the FUDCons as the mile-markers is merely a convenient construct. The events provided a defined inflection point to rework plans and tweak improvements. And with this third FUDCon in 2015, I believe that the time is right to think about the old ways. I am not advocating an immediate trashing of the old ways but we do need to think about where we want to go. Also, if you remember "mobilis in mobili" (Captain Nemo's crest in Verne's novel), we would need to respond to the change that we see. The world around us is changing in terms of technology and social impact. The mainstream media has a consensus around "Linux is mainstream".  Add to this the inevitable aspect of (L)UGs (ie. the user groups) becoming a thing of the past. In fact, barring the LUGs at Pune and Chennai, I cannot quickly recall any user group (a) meeting regularly; and (b) publishing reports of their activities.

The long years before this FUDCon were heavily invested in evangelism - the need to make the audience aware of the technology; the creative need to make a narrative/story which would resonate with their day-to-day requirements. I state that the need for such evangelism is past us. Our audience has moved away from the 'users of desktop' to groups of individuals who tinker with various pieces of technology like language and web-frameworks. The sweeping coverage provided by the LUGs have now become niche groups focusing on programming languages (Python, PHP, Ruby, Golang etc), frameworks (various Javascript frameworks), management and configuration, orchestration and container technologies (Docker, CoreOS etc). And with that comes the need to move away from looking at "Fedora as an operating system" to "Fedora as a platform". The important aspect of this switch is to stop considering the package compose as a "bag of parts". The various 'rings' imply a functional aspect to the consumption of Fedora. What I am suggesting is the complement - devising a form of the community that is highly agile to meet and expand on this engineering design change.

The need to move away from "meeting to talk" to "meeting to solve problems" has its roots in the need to create the communities of makers. Such communities would be expected to be polymaths and be naturally present across groups like CentOS, RDO and even functional tooling groups like Ansible, Puppet, Splunk and so forth. This decision would break down the large and somewhat amorphous "Fedora Community in India" into a real set of hyper-local hubs. Along with this granularity there needs to be a semblance of self-organization. The real issue with a large heterogeneous community is the creation of a vision that is sticky for everyone. Adopting the vision of the but enabling the small groups to self-govern and organize would allow a method of quick reach out without administrative overhead. In recent times I've been increasingly concerned with the inability of the "Fedora Community in India" to evolve into a much better self-organized and self-governed group. I agree that a part of the reason for that is in the few individuals leading this are 'spread too thin'. My proposed solution thus is to break down the hubs into smaller hubs. And I do have a precedent. If you could look at how the maker communities of Arduino, Raspberry Pi etc work, they seem to have it figured out. Smaller local communities should also facilitate an increased level of participation across diverse projects. For example, working with academics who are porting curriculum content to work with Open Source and then helping create a work-lab for their student batches. This provides the method to identify a problem and create a solution that includes various parts of The Fedora Project. And thus we move away from the cycle of install fests and introductory workshops.

In short, what I am suggesting as an experiment is very small and (hyper)local meetings which are announced. These come with an objective and have a reasonably clear idea about the paths to travel in order to meet those goals. Meetings and similar process should be pared down to a level of simplicity that detaches them from the need to have logistics issues of funding, grant and approvals. This would seem like going back in time. And it is exactly what it is. To homestead new frontiers one needs to start off with lightweight experiments and make progress.

The somewhat immediate question is - what is then the nature of the larger events and constructs like FUDCon? I think it is too early to sign a death warrant for such events. FUDCon was created and designed to address a need; as was Flock and so forth. But then the success of such constructs works against them as communities tend to rationalize the idea that events are the measure of progress and health. Numbers, metrics and dashboard are important - but they indicate the health of the community or, identify symptoms of stasis. By themselves they do not provide much by way of improving the life of the community. I believe that the community in India is well placed to run a few of these ideas as a pilot and report back to The Fedora Project on the success/failure of it. It is needed to engage more continuously with the project governance and leadership and not be bogged down into the India -> APAC -> NA linear chain.

(Note: Not all of the above were part of my talk. And some of the concepts would require more specific objectives to be devised and assigned. The thrust of this piece is to create a momentum using this FUDCon as the inflection point and think about where the community in India would like to go and how can we reach there.)
1
1
sankarshan mukhopadhyay's profile photo
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
An empty state, or zero-data state, is an afterthought for many designers. The thing you design last—if at all—because it’s a temporary or minor part of the user experience.
1
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
Not very sure as to why there'd be a jetstream over Sinhagad 
1
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
"When frameworks are small, and you can move fast, it’s nice: you get to feel like a revolutionary. You get to feel a brand-new team coalesce around you, a team whose culture easily fits yours. You aren’t beholden to, and responsible for, the community members who are as yet a twinkle in your eye. The reality of maintainership on a mature framework is equal parts tedious drudgery and soothing panicked strangers. In early frameworks, you still get to write code. You can focus on the theoretical purity you don’t have time to achieve in industry code. You talk to friends new and old, just like you, about immutability, or union types, or whatever the theoretical foundation of your framework is. You don’t need to talk about diversity. There aren’t any women yet to get irritated at you for avoiding the subject."

https://modelviewculture.com/pieces/the-life-cycle-of-programming-languages
1
1
Kartik Singhal's profile photo
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
+Siddhesh Poyarekar does a nice summary post for FUDCon.in at http://journal.siddhesh.in/posts/fudcon-where-friends-meet.html I do fear that I have let loose a monster by saying "Evangelism has had its day" and following it up with the never-actually-stated part of 'large conferences need to be thought over' [more at https://plus.google.com/u/0/+sankarshanmukhopadhyay/posts/5fnxbQNvmxp]. He writes "There were also questions of whether such large conferences were relevant anymore. Some stated their preference for micro-conferences that focussed on a specific subset of the technology landscape, but others argued that having 10 conferences for 10 different technologies was taxing for budgets since it is not uncommon for an individual to be interested in more than 1 technology. In any case, this will shape the future of FUDCon and maybe even Flock, since with such a concentration of focus, Flock could end up becoming a meetup where contributors talk only about governance issues and matters specific to the Fedora project and not the broader technology spectrum that makes Fedora products."

I think it is too early to ask these questions and think about the relevance of FUDCon and Flock. I believe the question that needs to be asked is whether individuals who are driving and influencing projects (like +Siddhesh Poyarekar or, +Kushal Das or, +Humble Devassy Chirammal et al) are being provided with the space and infrastructure constructs to build up the microcosm of the community they want to have for their areas of interest. I'd propose that using Fedora, CentOS, RDO, Atomic etc to enable such micro-systems would lead to a richer community of contributors (who are "doing things" and not just "talking about things"). These spaces can and perhaps should inherit methods that are well-tested (eg. workshops, video meetings, podcasts etc). But the basic idea is to pare down the growth drivers from large conferences to smaller sub-groups.
The madness is over. FUDCon Pune 2015 happened between 26-28 June 2015, and we successfully hosted a large number of people at MIT College of Engineering. This was not without challenges though and we met yesterday to understand what went well for us (i.e. the FUDCon volunteer team) and what ...
3
2
Siddhesh Poyarekar's profile photosankarshan mukhopadhyay's profile photoJoerg Simon's profile photoHumble Devassy Chirammal's profile photo
2 comments
 
+Siddhesh Poyarekar I'd say that it isn't only about system-level talks.

For example, +Nilamdyuti Goswami and others organized a Documentation workshop. Now, technical documentation and creation of content is often considered a "niche" area and STC etc are predominantly the organizations coordinating this space. However, if you look at the recent post from +Mikey Ariel around the concepts being adopted by the authors within RHT [more at https://opensource.com/business/15/6/documentation-content-strategy], it makes perfect sense to seek their feedback on a public blog post. And then follow it up with the chance of organizing something like "Write The Docs". +Nigel Babu selected content for his narrative that makes a perfect launch-pad to consider this approach.

My point is that the community building needs to be separated from the proselytism and it needs a smaller space focused on work. And this approach provides us with a smaller minefield to experiment with than a larger community event where we usually take less risks. FUDCon is a great event, but the organizing committee usually plays it safe, straight and keeps to the less risky parts of community architecture.
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
 
[This is the long-form version of my #fudconin  spiel]

While responding to the CfP for FUDCon.in 2015 I took a bit of time to think whether it would be a nice thing to talk about. All things considered, The Fedora Project has been a place for some great and continuing friendships and gently peeling apart the existing ways is not the best thing to do at a party.

Here's what the publicly available abstract for "Community Architecture - a different perspective" read as:

"The Fedora Community in India has evolved through a number of iterations of community building. The constant theme has been to demand a strong focus on "making". Continuing with the hacker principles which are typical to any Free and Open Source Software Community, the diverse opportunities within The Fedora Project offers an unique set of entry-points to all participants. This session proposal intends to investigate the existing approaches and generate some discussion around new methods to build a community of excellence."

See more at: http://fudconin15.shdlr.com/grid#sthash.YBHvSz04.dpuf

There's a somewhat pragmatic reason to this approach. I've started to notice patterns across various communities I have dipped a toe into. And I believe that these patterns are not conducive to creating excellent and vibrant communities. To begin to understand and deconstruct these patterns it is useful to look back within the community I've seen from close - the Fedora Community in India. The community has evolved through "cycles of objectives". The application of the design principle of 'form follows function' can be understood by investigation of the cycles.

During the period of the first FUDCon (coinciding with the LinuxAsia conference), the goal was to create an awareness. Those who have been around would remember that the usage/awareness of the 'Fedora' distribution was not specifically high. And the methods selected for outreach were standard and known to produce adequate results - installation fests and workshops; sprints across specific well understood areas (viz. translation and packaging etc); working in small numbers with specific interest groups and so forth. The good parts of these efforts are seen today as contributors who have stayed on and grown into established personalities within the larger project. However, there are also a couple of mistakes which we ended up doing. Two of which can be called out - (a) we limited our focus to 'Fedora as an operating system' (or, download/obtain and install Fedora and then use it); (b) we depended too much on free distribution of media (or, distribution of binary bits via Freemedia and similar). The compounded effect of these is that we continue to see a high number of requests for Freemedia Project out of India and, we put more stress on the hubs to feed content into the spokes.

This brings us to the second FUDCon in 2011. By this point the focus had moved to on-boarding participants across a wider spectrum of projects viz. i18n, QA/Testing, more SIGs, Security, Design, Spins etc. The gradual availability of the askbot based infrastructure provided an interesting alternative to mailing lists as the only means of communication and collaboration. The Fedora Ambassador teams had put together a reasonably simple method to on-board new Ambassadors and all these "low-floor; wide-shelf" approach did create a mix of new contributors across the breadth of The Fedora Project. The mistakes which deserve to be highlighted are (a) that there were far too many things to focus upon and (b) we did not have enough mentors and coaches who were strong presence in those projects to drive an increase in adoption and contribution.

Taking the FUDCons as the mile-markers is merely a convenient construct. The events provided a defined inflection point to rework plans and tweak improvements. And with this third FUDCon in 2015, I believe that the time is right to think about the old ways. I am not advocating an immediate trashing of the old ways but we do need to think about where we want to go. Also, if you remember "mobilis in mobili" (Captain Nemo's crest in Verne's novel), we would need to respond to the change that we see. The world around us is changing in terms of technology and social impact. The mainstream media has a consensus around "Linux is mainstream".  Add to this the inevitable aspect of (L)UGs (ie. the user groups) becoming a thing of the past. In fact, barring the LUGs at Pune and Chennai, I cannot quickly recall any user group (a) meeting regularly; and (b) publishing reports of their activities.

The long years before this FUDCon were heavily invested in evangelism - the need to make the audience aware of the technology; the creative need to make a narrative/story which would resonate with their day-to-day requirements. I state that the need for such evangelism is past us. Our audience has moved away from the 'users of desktop' to groups of individuals who tinker with various pieces of technology like language and web-frameworks. The sweeping coverage provided by the LUGs have now become niche groups focusing on programming languages (Python, PHP, Ruby, Golang etc), frameworks (various Javascript frameworks), management and configuration, orchestration and container technologies (Docker, CoreOS etc). And with that comes the need to move away from looking at "Fedora as an operating system" to "Fedora as a platform". The important aspect of this switch is to stop considering the package compose as a "bag of parts". The various 'rings' imply a functional aspect to the consumption of Fedora. What I am suggesting is the complement - devising a form of the community that is highly agile to meet and expand on this engineering design change.

The need to move away from "meeting to talk" to "meeting to solve problems" has its roots in the need to create the communities of makers. Such communities would be expected to be polymaths and be naturally present across groups like CentOS, RDO and even functional tooling groups like Ansible, Puppet, Splunk and so forth. This decision would break down the large and somewhat amorphous "Fedora Community in India" into a real set of hyper-local hubs. Along with this granularity there needs to be a semblance of self-organization. The real issue with a large heterogeneous community is the creation of a vision that is sticky for everyone. Adopting the vision of the but enabling the small groups to self-govern and organize would allow a method of quick reach out without administrative overhead. In recent times I've been increasingly concerned with the inability of the "Fedora Community in India" to evolve into a much better self-organized and self-governed group. I agree that a part of the reason for that is in the few individuals leading this are 'spread too thin'. My proposed solution thus is to break down the hubs into smaller hubs. And I do have a precedent. If you could look at how the maker communities of Arduino, Raspberry Pi etc work, they seem to have it figured out. Smaller local communities should also facilitate an increased level of participation across diverse projects. For example, working with academics who are porting curriculum content to work with Open Source and then helping create a work-lab for their student batches. This provides the method to identify a problem and create a solution that includes various parts of The Fedora Project. And thus we move away from the cycle of install fests and introductory workshops.

The somewhat immediate question is - what is then the nature of the larger events and constructs like FUDCon? I think it is too early to sign a death warrant for such events. FUDCon was created and designed to address a need; as was Flock and so forth. But then the success of such constructs works against them as communities tend to rationalize the idea that events are the measure of progress and health. Numbers, metrics and dashboard are important - but they indicate the health of the community or, identify symptoms of stasis. By themselves they do not provide much by way of improving the life of the community. I believe that the community in India is well placed to run a few of these ideas as a pilot and report back to The Fedora Project on the success/failure of it. It is needed to engage more continuously with the project governance and leadership and not be bogged down into the India -> APAC -> NA linear chain.

(Note: Not all of the above were part of my talk. And some of the concepts would require more specific objectives to be devised and assigned. The thrust of this piece is to create a momentum using this FUDCon as the inflection point and think about where the community in India would like to go and how can we reach there.)
View original post
1
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
I've been trying the Saavn app for the past couple of days. And I have to say that this particular app is by far the most vendor-centric anti-user app I've seen in a while.

The Saavn app is excellent for a couple of specific things - (a) setting up your account and logging in; (b) downloading music; (c) sharing what you are listening to via social media extensions. Any activity that is beyond these leads to disappointment.

For example, you can download songs. However, the app does not allow any specific method to categorise the download songs (eg. Singer, Film, Album, Genre, Year etc). So, what you end up with is a long list of alphabetically arranged songs that can be added to the Queue/Playlist or, Played. As a music player the Saavn app is inadequate - it downloads the songs (in an Android specified location) but in a manner that is opaque to other players. Which would be fine if the Saavn player was capable of handling equalizer or, volume control in a reasonable manner.

The 'music player' part of Saavn app looks tacky and merely held together as a "it did download music and should be able to play it back" kind of user experience. The inability to handle tagging of music is also a limitation that is imposed on the search UI. You'd be expected to have a precise knowledge of what you are looking for. The app does not like serendipity. This is not 1997! And even back then the available (and popular) player had enough going to make it easy for the user. I have my own specific set of reservations around the Spotify player but Saavn app designers could have spent some time on the flow before settling upon this abomination of an user experience.

The fact that a downloaded library of songs can only be scrolled alphabetically is so hilarious that I might sprain a side muscle. Add to it the very idea that there exists nothing by way of controlling sound or, creating one's own private playlists in offline mode. Stating that this is a joke would be overstating the fact.
1
Arin Basu's profile photo
 
Vendor centric anti user app, :-), loved that phrase Best review!
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
The CIS-A2K team has recently announced a "Mediawiki Train The Trainer" Program. More detail can be found at https://meta.wikimedia.org/wiki/CIS-A2K/Events/MediaWiki_Train_the_Trainer_Program A central theme to this initiative seems to be addressing the gap in "tech leadership in Indic language communities." 

There have been previous instances of 'Train The Trainer' efforts (cf. https://meta.wikimedia.org/wiki/CIS-A2K/Events/Train_the_Trainer_Program). The two programs share a bit of commonality when one reads the "Overview" section. It is encouraging to see CIS continue with the 'TTT' approach because it resonates well with the participants and the communities.

Now that this model has been adopted for multiple iterations, it would be useful to see if there is a need to tweak, improve the method of offering. Also, the efficacy of this model needs to be assessed. For example, how have the participants from the previous cycle drawn benefit? Have their continued contributions been enriched because of the TTT framework? Are they being able to do hyper-local TTTs within their own communities without waiting for CIS-A2K to come up and create the funding outlay? Are they sharing their knowledge and experience in publicly available forums and discussing the shortcomings (if any)?

It is important to note that the growth of technical leadership and effective community building should not become a labor of CIS-A2K. That task needs to be distributed and be empowered right down into the local community level. So, if the MW-TTT wants to focus on Working with Mediwiki internals; Bot frameworks with an emphasis on pywikibot; Bug triage, bug life cycle, raising a bug, fixing a bug etc. it should be inclusive of the various MW developer groups that exist across India. Coaching participants in how to provide reproducers on a bug report is a great step forward; fixing the bug itself is a next big step. But again, CIS-A2K cannot be the 'last man standing' in this work. 

During the previous iteration of the TTT I'd asked the team to make public on a regular basis the feedback and measurements of the TTT model. While that is yet to happen, one would hope that the MW-TTT workshop is not an one-off gathering with no focus on long term benefits to the community in India.
3
Kartik Mistry's profile photosankarshan mukhopadhyay's profile photo
2 comments
 
There was a tweet during the initial days of the training about coaching participants on setting the priority of the defect filed. I found it a misleading bit to coach since the reporter should be more focused on providing enough structured data to help a reproducer and should never be bothered with priority. That's basic bug filing hygiene.

I see that Andre K has been doing what it takes on those tickets. Might have been a good idea for CIS-A2K to actually have him do the Phabricator coaching.
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
“On #WorldEnvironmentDay, here is an example of how a thoughtless engineering disaster, the #FarakkaBarrage, has horrific social and environmental knock-on…”
1
Add a comment...

sankarshan mukhopadhyay

Shared publicly  - 
 
“Complain about no rain; take pictures of downpour next morning :) #LenkaCam”
1
Add a comment...
sankarshan's Collections
Collections sankarshan is following
Work
Occupation
Being curious about what makes everything tick !
Basic Information
Gender
Male
Looking for
Networking
Story
Tagline
Husband, friend, book reviewer and, an all round nice guy
Introduction
i hope for a time when neither magic and nor sufficiently advanced technology will be unavailable to a large section of the society

i post on G+ and am available at sankarshan at pobox dot com. www.linkedin.com/in/sankarshan is my LinkedIn profile.

To catch me on IRC, try Freenode and, look for sankarshan or, _sankarshan
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Bengaluru
Previously
Pune,Maharashra,India - Kolkata - Delhi - Mumbai - Kolkata - Pune
Contact Information
Home
Email