10 – The Options by Context Principles Set

The IDEMS Principle
The IDEMS Principle
10 – The Options by Context Principles Set


Danny and David discuss the second set of principles: Options by Context. They present all the principles in this set, and discuss how they relate to each other, their motivation and history.

[00:00:00] David: Hi, and welcome to the IDEMS Principle. I’m David Stern, and I’m here with my co founder, Danny Parsons.

Hi, Danny.

[00:00:14] Danny: Hi, David.

[00:00:15] David: What’s our topic today? We’re going to have a go at our second set of principles, the Options by Context set. This has broadly the principles Options by Context, of course, which is a really important one for us, and we’ll dig into that.

[00:00:32] Danny: Yep.

[00:00:33] David: Open by Default, which everyone seems to misinterpret, so that’s another good one for us to discuss.

[00:00:39] Danny: Okay.

[00:00:40] David: Local Innovation and Continually Evolving. I must say this is one of my favorite set of principles.

[00:00:48] Danny: I feel they, they fit together nicely in a set. They all do in some ways, but this really feels like a very coherent set.

[00:00:55] David: Yeah and Options by Context, we haven’t come up with this, but this has come out of our collaborations with both the McKnight Foundation and the Collaborative Crops Research Programme, which is now the Global Collaborations for Resilient Food Systems. And that’s really where I believe this idea has emerged.

But also our PICSA work, where this is central to the PICSA approach. PICSA of course stands for Participatory Integrated Climate Services for Agriculture. And both those programs, which we’re deeply embedded in, very involved in, have Options by Context as part of their principles or founding concepts.

[00:01:40] Danny: Yeah, and I like the foundation of that idea because it’s, it comes from something very concrete.

[00:01:47] David: Yeah.

[00:01:48] Danny: This is this agriculture setting and specifically working with large numbers of farmers and treating them as individual farmers as well. And I think it’s something that I think makes a lot of sense to people as well.

[00:01:59] David: Yeah.

[00:02:00] Danny: When you explain it, this idea of, different options being appropriate for different contexts that farmers are in and the context can be quite varied, not just geographic and things like this, but more sort of social contexts as well and things like this. I’m always a bit, a little bit surprised at how well it translates to so many other things because it did come from this very specific context.

[00:02:24] David: Well, it’s a generalization of G by E which is genotype by environment interactions, where in breeding for new varieties of a crop, there was a recognition you can’t have one variety for all environments. You need to consider the environmental context when you do your breeding. It seems obvious, but it was actually a big step forward in breeding trials and breeding as pipelines, if you want, And then, actually, I believe Ric Coe was part of the team that, who’s one of our collaborators, he was one of the core part of the team that sort of said actually, this applies much more broadly.

And really, we should be thinking about these options by context in many different scenarios, not just for breeding, but across the spectrum of management practices, but also outside of agriculture.

[00:03:24] Danny: Yeah, and I think the sort of last bit of how we describe this is really important as well, where we say that this precludes the search for single blanket solutions, and I think that’s really important now as we’re thinking of this generally in how it relates to all of the IDEMS work as well.

It really, I feel, has an impact on all of our projects quite thoroughly. It makes our life harder, I was going to say that, and it could be seen as a bit disappointing in some ways, that we’re not just looking for a very simple single solution to solve all problems.

And that is what happens a lot of times that these things get proposed and something new comes along, which is seen as the solution to everything in some specific domain. But I think, from our experience and from our work, we know these things don’t really exist.

[00:04:14] David: It is true, especially in technology. And this is where we come across this a lot. It is true that if you have a new, good solution, it can scale very far, very fast. But it will still not be right for everyone. It will need to have adaptation to be able to be appropriate for others in their context.

[00:04:34] Danny: Yeah. And I think from a sort of more business perspective, you’re more interested in that 70, 80, 90 percent of people or whatever who are going to be using your product. And if it doesn’t work for, a small section you just want to make that as big as possible, but, coming from a sort of development perspective as well, it’s that group at the end which are actually more important often because they’re the ones who are always left out.

[00:05:00] David: It’s the margins, developing for the margins.

[00:05:02] Danny: Yeah. And not that your solution for the rest, isn’t still valid, but you’re not trying to impose a single solution on everyone just because it works for most people.

[00:05:13] David: Absolutely. And this is we find this so powerful, but it does put us in opposition quite often with a lot of our collaborators.

[00:05:21] Danny: Yeah, I guess it’s quite inefficient in the sense of if your goal is just to reach as many people as cheaply as possible then this is very inefficient to think about lots of different contexts and from a sort of profitability perspective then, we see this with people that we’ve worked with before…

I remember who are, collaborators we’ve had who are more used to working with mainly commercial partners and they’re wanting us to avoid these sort of complex things because this isn’t going to be good for you. This isn’t going to help. You’re making our lives more difficult for yourself, which we are, but for good reason.

[00:05:54] David: And many of those partners actually then recognise that actually they need it because a lot of them are trying to work in low resource environments. And they recognise a little bit further down the line how grateful they are that we put that extra effort in.

[00:06:10] Danny: Yeah.

[00:06:10] David: Because it’s exactly what enables us to then change and transform and adapt to their new needs.

And so actually a lot of our long term relationships have gone on that evolution pathway, Continually Evolving. This is part of it, of course. Where they thought they were looking for a single solution. We just want to digitize our program and get it out to everyone. It probably isn’t going to work. Let’s try and understand, and yes, think about a particular audience, work towards that audience, and then adapt it for others, and so on.

[00:06:46] Danny: Yeah, and I think then this really relates to the Local Innovation.

[00:06:49] David: Yes.

[00:06:49] Danny: It can have these general solutions and generalized ideas that, work for a lot of people, but then they’re adaptable and they can be tailored to local contexts. And I think about some of our work even before IDEMS, but often finding things in… especially in education, that are just not tailored for use in a lot of African countries that we were working in.

And that sort of not being able to locally adapt things and innovate locally just means they’re stuck, the only thing that’s left is these sort of things that come from other countries. And you find they are actually adapted quite well to other contexts.

They’re not developed as global products. They’re adapted to the US market or the European market or the UK market or something like that. And so they are adapted, but then the sort of marginalized or the areas where it’s seen as less, less of a market, doesn’t get that local adaptation.

[00:07:50] David: Because it would be too expensive.

[00:07:51] Danny: Yep.

[00:07:52] David: Because there’s too many different marginalised contexts. And that’s, I think, at the heart of a lot of what this thinking has led us to. Broadly, these ideas, as you say, we had this set of principles pretty much nailed before IDEMS started. This has come out of our experiences, as you say, a lot of it from education, but we’ve seen it in other domains being relevant as well.

[00:08:19] Danny: Such as agriculture, for the agriculture by context.

[00:08:22] David: Exactly, and climate, and anyway, so yes, a whole range of areas. And yet it’s now forming the foundation of how we’re building tech, we see it differently.

[00:08:37] Danny: Yeah, and I think we haven’t mentioned Open by Default, which is one of my favourites in a sense to talk about. That obviously relates to all of them, but the Local Innovation, things can’t be adapted if the source material isn’t openly available to be able to be adapted. And so that’s just one of the reasons why this openness is quite important.

And of course open comes from lots of areas, but in software development, it’s well established about open source software that has had a lot of support and then a lot of bigger companies supporting it. And a lot of kind of work on the licenses of different kind of open source licenses. But yeah, all areas, education as well, it’s big as well.

[00:09:20] David: Although often in the education area, it feels younger, the openness, whereas in open source, they’ve gone through the pains on the licenses, and they’re now pretty well understood. If you actually have proper open licenses, then it’s well understood, and there’s no real discussions or arguments.

[00:09:40] Danny: Yeah.

[00:09:40] David: Whereas in the educational resources I’ve continually banged my head against the wall with partners who think a license means one thing.

[00:09:49] Danny: Yeah. And even just generally, I think. Although I suppose open is quite widely used and used and misused in lots of different ways.

[00:09:58] David: Open AI.

[00:09:59] Danny: Open AI. But I think people equate open with free. And I think you discussed this before, why that’s not the same, and a few other different kind of things that people think of as open.

[00:10:11] David: Yeah the element about , under the Creative Commons licences, they have their Creative Commons licences and people think of all of those as being open, but actually they also have this sort of I think it’s a cultural public good concept where not all of the creative common licenses actually satisfy that.

And in the sort of software sense, only those public goods would be considered open. The other licenses wouldn’t be open. And it’s really interesting, again, those details really matter.

[00:10:42] Danny: Yeah, and I think it’s also, some people would also think of it as there’s no rules, and it’s just no one owns it, it’s just out there, and there’s a lot of people being against it, for it being seen as quite uncontrolled, and you don’t have any quality control and things like this.

[00:10:57] David: Which is the opposite.

[00:10:58] Danny: Yeah. Yeah because it’s open.

[00:11:00] David: Because it’s open. If you have closed software, there is no quality control because nobody knows what it’s doing.

[00:11:06] Danny: Yeah, it’s all closed off and it’s not externally verified and validated and it really is this sort of letting the community decide what’s best, in a sense, in terms of choosing products.

[00:11:16] David: I think it’s not decide what’s best. This is the key thing. Every good open solution that I know in the software side has a relatively small set of decision makers, but it has a big community of people who contribute.

[00:11:30] Danny: Yes, and I’m also talking about from the user side, it can be evaluated by the users and they can do that on their own if they want to and decide then what’s the best to use.

[00:11:43] David: But not all users want to be that involved as contributors.

[00:11:46] Danny: No and I think the way we phrase the principle of by default is also a bit unique for us because there’s a..

[00:11:54] David: You can’t be a bit unique.

[00:11:55] Danny: A bit unique, yeah.

[00:11:57] David: Either you’re unique or you’re a bit different.

[00:12:00] Danny: Let’s say a bit different. Because there are organizations where, open is their fundamental sort of aim and goal. They completely focus on this, and everything is open, and they use and create is open, and we’re we’re not on that extreme.

[00:12:17] David: No, not at all, and I don’t believe you should be.

[00:12:19] Danny: Yeah.

[00:12:19] David: There are good reasons why certain things shouldn’t be open.

[00:12:23] Danny: And I think, open isn’t our aim, isn’t our end goal. And so this is why I think it’s really important that yes, it’s something we believe in and want to support in lots of ways, but it’s by default, and so when there’s good reasons not to, then we’re happy to not go for the open option, whatever, whether that’s things we use or things we produce.

[00:12:45] David: I had this very recently where ,in one of the projects we were looking at, people were wanting to look at visualisation tools. And nothing competes with Tableau, it’s just beautiful, and in many different ways. And so that is the tool that they are now considering using with our support. And so supporting people to use a tool which isn’t open because it’s the best tool for the job. Absolutely sensible.

[00:13:10] Danny: Yeah, that’s a good way I feel that, yeah, Open by Default is another way, choosing the best tool for the job.

[00:13:16] David: Yeah.

[00:13:16] Danny: Which is what we want to do. We don’t want to compromise our work or our projects or our impact because of the openness. It’s not more important than that. I think it was in the podcast on this, it was described as the choice, you don’t have to think about the choice. I think of it slightly differently, in that it’s, you need a justification not to choose this option.

[00:13:37] David: But we also need to think of it the other way on. Why might we produce things which are not open and be happy with that? And we work with universities and many universities, their business is really around the education that they give, and so they don’t want to have all their intellectual property being open.

And we’re very happy to work with them to support them. We don’t want to force them to be open. We’re happy to work with them. That’s just a service we can offer. We don’t feel that our views should impact what their business model or what their views are.

[00:14:10] Danny: Yeah, and I like this practically in how we can carry out things that if we are producing things for people and they’re happy for them to be open, we can reuse them in other ways, then we can maybe invest more into that.

[00:14:22] David: We can make a contribution in kind, which means that they get more out of us because we get more out of what we’re building for them.

[00:14:30] Danny: Yeah. But as you say, if not, and there’s reasons why different organisations can’t do this and so on, then that’s fine as well.

[00:14:38] David: Absolutely. We believe that open is really valuable in many contexts, but this is about the context. It’s Options by Context. Not all contexts are served by open.

[00:14:51] Danny: Yeah.

[00:14:51] David: And so if you’ve got options by context, part of this is, and I love the Open by Default as a way to think of this in terms of options by context, because there are many contexts, most contexts we believe open is the right answer, but not all contexts. And so having open options and having closed options, in that context, as being the best option is absolutely sensible.

[00:15:17] Danny: Yeah, and having said that, the way that it links to the other principles, I think, is really interesting as well, this sort of allowing that local innovation. You can just take things that are open and adapt them and change them as well, in this Continually Evolving. And yeah, I think one of the arguments I remember hearing is which found really convincing was that, if you have a sort of closed product, and then suddenly the people developing it decide they don’t want to develop it anymore, then there’s nothing you can do, that product’s gone, or it’s just stayed stable, yeah.

[00:15:50] David: TinkerPlot, it wasn’t that the developers decided that, it was that it was sold on and the people who bought it didn’t care about it. It was just packaged up with something else and left to rot. The best statistical education software in the world was just lost, just like that, because it wasn’t open.

[00:16:07] Danny: Yeah. And so that kind of openness gives you, I think it gives you a lot of confidence. At least you can make more of a commitment towards it. Because, okay, it’s not easy to take over a product maybe that’s been abandoned, but at least if it’s open, then, and it’s good enough, if it’s really useful enough for enough people, then they will, find a way to keep it going, at least.

And of course, then, things split off from open projects as well. You don’t have to continue in the same direction. You will say, yeah, I quite like this, but I want to go in this direction with it, because for my needs, it’s like this, or my set of users, and that happens all the time.

[00:16:45] David: OpenOffice, LibreOffice.

[00:16:47] Danny: Yeah.

[00:16:47] David: And I’m not going to enter into any debates about that. But some people see that as a disadvantage. Others recognize that as the sustainable advantage that it is in the long term. That disputes don’t lead to roadblocks.

[00:17:04] Danny: Yeah, it does bring in complexity, and the same with the options by context, that instead of just being given one choice that everyone uses and has to use you’ve got choices to make and that adds complexity.

[00:17:16] David: Absolutely.

[00:17:16] Danny: It doesn’t always make your life easier.

[00:17:19] David: No. And I think that’s a really important point that actually many of these principles are about dealing with complexity. This is what really I would argue this set of principles, Options by Context, Open by Default, Local Innovation, Continually Evolving. It’s all because we’re living and dealing with complexity that these are really powerful principles for us. They’re not good for everyone, but if you’re living in complexity, if you’re working in complex situations, they really provide the tools you need to take on that complexity.

[00:17:58] Danny: Yeah, I think so, and to get a handle of it, you can get them paralysed by complexity of things and having so many possibilities. I think this gives you or, and it gives us, a bit of a framework to, to try to tackle those things.

[00:18:14] David: And to maybe continually evolve as part of that, we’re not looking for the solution, we’re looking for something which is going to evolve over time, based on how other people use it, based on the needs. So we’re looking to develop those things which are going to be continually evolving. There’s not an end point that we’re aiming for.

[00:18:33] Danny: Yeah.

[00:18:33] David: I always think of wicked problems when I think about this.

[00:18:35] Danny: Yes, and it’s very different, I think, from maybe a pure kind of commercial mindset as well, that you get your one thing out there, and then you can keep incrementing it, occasionally, just to keep going, but you’re not really, evolving and looking for new things.

[00:18:51] David: No, because, most business models on closed products have an update business model, which is an evolution, and they are looking for that continual evolution, because that’s how they actually get people to buy it again.

[00:19:04] Danny: Yeah, I guess that’s true. In some cases you see that sort of fake, they have to bring out something every year, so they just, you know, they add new things to it, but artificially new things, but not always.

[00:19:17] David: No, there’s, there is the element that tech is just evolving, and good software has to be continually evolving. So that’s not new in the software industry. The software industry recognizes this, that if you’re not always updating regularly, you’re going to be having problems with security updates. Continually evolving is well recognised in software.

We don’t just apply it to software. That’s the point. We also think of this when we’re thinking about interventions. If we go back to pre IDEMS, the maths camps, which we’ve mentioned. In many ways, a lot of these principles relate back to our experiences with the maths camp, where we had a core idea. We then had recognized how it was implemented differently in different contexts. Ethiopia and Kenya couldn’t be more different in some ways, but the same core idea is implemented. So that’s the options by context. We needed the open to be able to go from one context to the other, sensibly, to be able to have that sort of scaling that happened, to go to Ghana, to go to all the other countries which have taken it up.

[00:20:27] Danny: Yeah, and local innovation then to really adapt it in each country.

[00:20:32] David: Exactly.

[00:20:32] Danny: It’s really been very different in, in, in every place that it’s been implemented. But yeah, we’re coming from the same sort of core idea.

[00:20:39] David: And having the same core, maintaining a common core with so much local innovation that really is adapting to each context.

[00:20:47] Danny: Yeah.

[00:20:48] David: And not just adapting to exist, but adapting over time. That continual evolution in every context has been, central to it. So I think this set of principles really, for us feels, or for me anyway, you can speak for yourself, but it feels very personal, that it really relates to our experiences.

[00:21:13] Danny: Yeah, and it feels maybe very natural or something to me, in a sense maybe just, yeah, from those experiences. It just feels like this is the way that, that we kind of work.

[00:21:25] David: So that’s interesting because I feel, and maybe this is a bit about our relationship pre IDEMS, that I was establishing the maths camps, whereas, you came into the maths camps, and so that naturalness is because that’s how you’ve been working. Whereas actually maybe I’ve been more conscious in establishing this way of working.

But I think this set of principles, I think, for us, this is central in many ways. And it’s things which are, even our fellow staff are struggling with.

[00:21:57] Danny: Yeah, you know, they appear that they could just relate to specific things, the openness, just the software and so on. Yeah, I think there is a lot of depth to this and it does seem to permeate into all the elements of our work quite deeply embedded in that.

[00:22:13] David: Yes, and I think, in many ways, often this is the set of principles that we pick other people up on within our team.

[00:22:23] Danny: Yeah.

[00:22:24] David: When we suggested new software to use, when we think about how we’re going to take on a project. These are the principles that really come back and that we keep referring to, I think.

[00:22:37] Danny: Yeah, I agree. And yeah, it’s been good to talk about them.

[00:22:40] David: Yes, thank you.

Maybe the last one I’d just to get your thoughts on a little bit more is around the local innovation. Part of this related to how we started or this vision we had when we started R-Instat, with this idea of it being developed locally in the environment in which it was needed. Do you want to just say a little bit more about your perspective on that local innovation?

[00:23:06] Danny: Yeah, we started developing R-Instat under this African Data Initiative banner and it was really a sort of core part of how we were selling the idea of R-Instat in the beginning of why it should be developed. And I think it’s been really important throughout the development and then as we’ve used it and how people see it as well.

And I think it was, one of the main points was developing things in Africa for Africa.

[00:23:33] David: Not just for Africa.

[00:23:35] Danny: Yeah, exactly. Yeah. Not just for Africa. But developed kind of tailored to the needs of the places where we were going to think this software was going to be used and really impactful. And, it led to a lot of decisions that were non standard and would be quite different in the sort of UK based kind of software development.

And it’s been challenging, but I think it’s really helped us to have a focus for decision making. I still remember specific discussions about how the software should be, you should be able to get it running offline and things like this. And that led to things that seemed a bit odd, the size of what you have to install was very large then, and there were lots of easier solutions in the sense that you could have gone around this, but then you would have had to need it online and have to download stuff when you start it up and things like this. And we knew that just wasn’t sensible for the local context.

And I think it helped us to thinking about that. That kind of as a principle helped us in the decision making as well. Even when it looked like it was not a typical decision, I think it gave us the sort of conviction to say, yes, we know this is right because we’ve got this behind it.

[00:24:52] David: And what I think is so interesting, of course, is that if you think of that set of decisions, this predates IDEMS, but we’ve taken that experience into IDEMS, of actually trying to build software that way, of trying to build software in the environments where it was most needed.

[00:25:12] Danny: Yeah. And now we’ve then gone on and adapted it, as you say, it’s not, the vision was never just for Africa, but we, we knew there was this specific need for the statistics software in this specific way in a lot of the places we work in Africa. But we’ve seen it being used in other places and in the UK and Europe and elsewhere. And there are then different requests that come in and different needs and we can unadapt and say, okay we can have other options which are more suited where, okay, these people are always online, they don’t care about, they just want something that’s the easiest. Okay, we can add that in, but we’re not then removing the sort of core elements that we had in the first place. And we can have these, adaptable components.

[00:25:55] David: And this is I think the big thing that I’ve taken away, which is now central to our thinking on this, is that by thinking that way round, it’s really easy to add the functionality which makes it work really well, and you know exactly what won’t work in other environments. And you can still make sure that most things, everything that should work does work. It’s just the things that can’t work which don’t. Whereas, when you build the other way on, then there’s all sorts of things that get caught on and lost.

[00:26:25] Danny: Yeah, I think it’s that, that, thinking of that 10 percent or whatever, it’s not, maybe not necessarily that small in this case, in terms of our audience. But it is thinking of what will work for everyone and making that work. And then we can have things that work for only 90%, only 80%, only 50%, whatever, who have extra, but then they’re extras. They’re not they’re not fundamental and they don’t stop you using the product to do what you want to do, they are enhancements.

[00:26:53] David: Absolutely. And this idea then of actually there being different versions for different contexts is exactly back to that local innovation leading to options by context. And that’s where we’re heading with a lot of the software we’re now building. We’re a long way to go still. But It is exciting that those core ideas are now translating. R-Instat still has a long way to go, but if we take the apps from the digital ecosystem with parenting work, those, we are seeing this same process in action, working. It’s exciting.

[00:27:27] Danny: Yeah, it is.

[00:27:29] David: Thank you very much. I think that’s probably as much as we should be talking about for today. I look forward to discussing the systems thinking set as a next set of principles.