Conversations about FOSS

[rahulporuri]

I have been having conversations on/around FOSS over the past few months, some of which felt relevant to a broader audience. I also wanted to solicit community opinion on the conversation. I will be documenting a few pertinent conversations from the recent past and future conversations as and when they happen.

---

On behalf of FOSS United, I recently gave a talk at a major Government Institute. A faculty member from the institute invited me to talk about FOSS and I presented on how Government Institutions can adopt FOSS. After the session, one of the audience members asked me a question (remarked) about FOSS adoption. Specifically, they mentioned that the cost of migrating away from their existing software (primarily closed-source) is very high i.e. the users are comfortable with the software that they are currently using, and in some cases have been using it for decades. They also mentioned that the cost of creating the training material and running the necessary training exercises to migrate away from closed-source software to FOSS software will be significant.

I thanked the audience member for the meaningful question and gave two answers.

First, the institute should be able to do a quick back-of-the-envelope calculation to guesstimate the cost of creating the training material and running the necessary training exercises. This can now be compared meaningfully to the recurring cost of closed-source software and the recurring cost (if any) of FOSS software. In doing so, we will be able to understand the break-even point i.e. at what point in the future will the reduced software expenditure pay for the initial training.

Secondly, and more importantly, I highlighted the fact a number of (not all) closed-source software providers have intentionally allowed software piracy to continue because it meant that a user base is created and sustained, whom they can eventually monetize. There are examples of closed-source software being provided at a discount or free-of-cost to college students, ensuring that the students become comfortable and competent with the software, eventually ensuring that a significant number of them will continue to use (and even demand) the software at their employer. It is important to identify this “incentive” for the long-term cost that it actually is and incorporate it into the overall cost of closed-source software.

Another audience member pointed out the large scale of disruption that can happen at the institute and its activities because of a widespread adoption of FOSS.

I responded to the audience member by stating that FOSS adoption is not binary, FOSS adoption can be a journey. In the talk, I mentioned that there are different axes/depths of FOSS adoption i.e.

• FOSS OS
• FOSS day-to-day tools e.g. Firefox, Thunderbird, LibreOffice/Open Office
• FOSS tools tangential to the mission of the institute e.g. admin/HR/management
• domain-specific FOSS tools, relevant to the mission of the institute

I agree with the audience member that the institute pursuing a complete overhaul of its IT infrastructure by replacing all closed-source software with FOSS in one go will be extremely painful for the institute, potentially leaving a very bad taste for people at the institute, and in the worst case scenario halt mission-critical activity at the institute. No one wants this outcome

I mentioned that the institute can take a staged approach to FOSS adoption e.g. identify and evaluate small islands within the institute for potential FOSS adoption. Depending on the day-to-day usage of software by the individuals, it might be easy to migrate to FOSS OS but still use closed-source software on the FOSS OS. Alternatively, replace most/all closed-source day-to-day tools with relevant FOSS tools. Or don’t make changes to existing software installations but mandate that all new software usage/adoption will be FOSS-only or FOSS-first.

FOSS adoption is a brilliant choose-your-own adventure. The end goal is full FOSS adoption. Based on our context, we get to decide the specific path that we choose to get there.

Thoughts?

[idlethread]

I have a constant feeling of deja vu at ‘adoption of foss’ talks. I’ve seen similar questions raised since at least 1995 when I first got involved with Linux.

As a curmudgeon, one piece of history that might bear repeating is that Linux did not just storm all the mobile phones, chromebooks and running most major web service deployments on day 1. It started as skunkworks projects inside large and small organisations - a print server here, a DNS server there, an email server elsewhere.

There will need to be a few renegades inside these organisations that need to drive the change thru small efforts at first. The policy makers are too hand-in-glove with the proprietary sw vendors to drive this - they get free sponsored labs to keep the status quo. Those free labs look good on brochures and during re-election.

These discussions all start with -

1. What are your biggest licensing costs?
2. Why going proprietary on some key software is holding you back?

For 1, the answer might very well be that proprietary software is ‘free’ for many educational institutes as a hook for later as you said, and more importantly to keep students from getting a taste of FOSS at all and keep them from tinkering.

Perhaps the job and technology creation angle could be used with 2 to allow some limited experimentation?

[Akhil1]

The major cost involved in adopting FOSS is you are on your own in setting up and maintaining systems. Atleast the IT team should be capable in solving software implementation and maintenance issues. Majority of Foss companies don’t have large distribution network and supporting partners to help others adopting their products as it involves huge marketing and training costs.

[rahulporuri]

@idlethread

As a curmudgeon, one piece of history that might bear repeating is that Linux did not just storm all the mobile phones, chromebooks and running most major web service deployments on day 1. It started as skunkworks projects inside large and small organisations - a print server here, a DNS server there, an email server elsewhere.

Absolutely right. Instead of pushing for top-down adoption, I advocated for skunkworks projects within departments, with decentralized decision-making on what tools to adopt and a small budget to do the migration. The small budget and the small scope makes it easy for the institution to swallow any “failures”. Grand, top-down approaches are usually a recipe for prominent and costly failures, FOSS or not, because the people making decisions at the top are too far away from the people actually using the tools on the ground.

@idlethread

The policy makers are too hand-in-glove with the proprietary sw vendors to drive this - they get free sponsored labs to keep the status quo. Those free labs look good on brochures and during re-election.

If you’re talking about policy makers as in elected representatives, I would likely agree. If you’re referring to policy makers as in people who make policy decisions for an organization, I am inclined to attribute ignorance instead of malice. Too many institutional policy makers don’t have the project/usage information needed to meaningfully create top-down FOSS adoption policies. Org policy makers should focus on pushing experiments to the ground and letting feedback flow to the top, creating a meaningful feedback cycle for org-specific FOSS adoption.

@idlethread

Why going proprietary on some key software is holding you back?

@idlethread

Perhaps the job and technology creation angle could be used with 2 to allow some limited experimentation?

This answer is simple and I didn’t even have to answer it because the org answered it for me. The org is already struggling with proprietary software (and hardware) whose vendors don’t exist anymore. Or the vendors exist but the software (and hardware) products aren’t supported and the cost to update is ginormous. Or multiple vendors who provide hardware products that don’t work together instead of adopting a standard to ensure cross-compatibility. Infact, it was explicitly mentioned that their focus should likely be to ensure the adoption of open standards by external vendors. I brought up the example of the Open Document Format instead of adopting the proprietary MS Document format, to ensure that the documents can be used with FOSS tools along with proprietary tools if necessary.

@Akhil1

The major cost involved in adopting FOSS is you are on your own in setting up and maintaining systems. Atleast the IT team should be capable in solving software implementation and maintenance issues.

I fully agree and I explicitly conveyed the same - that their in-house capability needs to improve to manage the FOSS deployments within the org. The good thing about improving in-house capacity is the added benefit of unlocking new directions/better adoption/additional cost-savings for the org (stolen advice from a talk that @realvinay re Zerodha FOSS usage)

[idlethread]

@rahulporuri

The org is already struggling with proprietary software (and hardware) whose vendors don’t exist anymore. Or the vendors exist but the software (and hardware) products aren’t supported and the cost to update is ginormous. Or multiple vendors who provide hardware products that don’t work together instead of adopting a standard to ensure cross-compatibility.

Are the list of software and hardware in such a state at this org public information? It would be interesting to know.

[rahulporuri]

@idlethread

Are the list of software and hardware in such a state at this org public information? It would be interesting to know.

Ha. If only. Maybe in the long term, we’ll be able to coax this information out of them, and see it in the public domain. Or we might indirectly be able to piece it together by looking at public tenders.