of suggestions that hopefully will help you to write a more engaging proposal and we

crowd sourced this list because we've been reviewing 800 proposals in the last couple of months and yeah, we'll kick off with a quick introduction of ourselves. Is this? Oh, hello. I'm Dan with the Open Technology Fund, known as Dan Blau or Dan Meredith as my

parents named me. So really quickly, Open Technology Fund is a technology centric fund that we essentially we write a grant to the US government that gives us money then we then re-grant that back out to other projects that are developing open source technologies, in particular those that are supporting free expression and free speech.

So a little bit more narrow compared to what they'll describe what they're doing, but a lot of the same principles as far as the kinds of technologies and the nature of the technology. So I'll stop right there. We've been around for five years and we've got thousands of applications that we've reviewed as well.

And we're Lisa and Julia from the prototype fund, a program from Germany focusing on civic tech, data security, data literacy and infrastructure. So in a nutshell, we are supporting people in projects that work on tools, software for public good and we grant sums up to 30,000 euros for six months and the prototype fund,

the money comes from the Ministry of Education and Research and we started a program because we were very frustrated how hard it is, how much bureaucracy it takes to submit a proposal as an individual and there are not really any programs out there for individuals

to access public grants. So that's why we started the fund. So yeah, we want you to get the funding and for this reason we'd like to share some of the insights on how you can tweak your project idea and how to make it better and maybe which traps to avoid.

So we've put together our seven most favorite insights that we've gathered by reading through. For you it was more than a thousand, for us it was several hundreds of proposals and at least for me it was quite a change of perspective to not being the person to write a proposal but to be the person to read through a proposal and it really makes you

understand the aspects of a good proposal better. So we want to share what we've learned in the process. So here's trap number one. This is a quote, I know this is something you're not supposed to say but for this project it's true.

The user is simply everybody. I mean this is such a tempting trap and I know where it comes from. Of course I want the whole world to be my user and to use my solution but well unless maybe you're I don't know a plant that produces oxygen, your solution will never

fit everybody. There just is no one size fits all if we are true to ourselves and especially not in tech tools. So tools that try to suit everybody tend not to work very well for anyone. So here's our first bit of advice. Know the user and put some effort into getting to know them and what exactly they

need and the answer might actually surprise you. We encourage all projects to follow a human centered approach in every step of their work so we really want people to start with a proper user research and go through user centered design or human centered design and end up with user experience design.

At least that is our experience. Yeah and you'll get the rhythm here. I'm going to provide an antidote every time there's one of these things that comes up from our experience and they'll provide some evidence from theirs. From the open technology standpoint, we first and foremost stick to folks that are

dealing with some sort of repression, like freedom of expression or free speech. And the most ideal project for us, and we ask people this all the time, is one that is being developed by those who are most affected by that situation. But if you're talking about more of a civil society situation, you know, if you've got an idea to stop potholes, make sure that you're actually experiencing the problem

of potholes. Like you have a car, it's really troubling your bicycle and it's like a really personal thing for you. And that's the most ideal sort of applicant and you're focused on just those specific people. Not everyone's going to care, but those most affected will. Okay, trap number two.

In politics, nobody ever listens, I want to change that. I know this feeling, we all know this feeling, but as a statement in a funding proposal, it might be too much of a feeling and way too general unless it's your teaser to grab attention. Then it's great. But we've experienced that in a lot of proposals, people make assumptions and then

never conclude or tell us how they came to this assumption. So we all know most ideas start out as gut feelings, but it helps to give some evidence to prove your point, and it also helps you to check your point, right? If you cannot back it up with premises, it's probably not as true as you might have

thought. And it's really not a rare case. We have assumptions similar like this one in probably one out of three proposals, I don't know. Same, same. I mean, it's one of those situations where, especially when you're dealing with technology and mostly technologists, there's a sort of like a build it and they will come.

It's like, I've got a really great idea. It's great. It's the best. Everyone needs to know about this idea. Can't tell you why, but it's my good idea. And it's sort of related to the first one, and a lot of the proposals, in particular the ones that are very strong, again, come up with not necessarily like a large data,

even if it's just anecdotal, as in you know that this is true for a few people, this is what it is, and you can sort of document that. That goes a long way to strengthening up what it is that you're proposing. And if you're doing something where the people using the technology are other software developers who are then engaging with people, and so it's removed from those end users,

that's fine. Just go and try to demonstrate and show how your code is being used by other developers that are engaging with people, and just do a little bit of that, and it goes a long way. Yeah, that's a good point. I think we're going to chime in with that several times, because it's such an important point. So, this is a statement. There is no usable email client for Android open source.

I'm sorry. I think these slides are great, by the way. I haven't seen the edits. I love all these little quotes. Thanks. Yeah, well, they're not from us, so yeah, so this is trap number three, just getting it wrong. I understand also where this comes from. So when I have an idea, I want to get started immediately, and I want to work through

with it. And I don't want to do research on what other people have done, because you know, I think I have, this is my problem. I know how to solve it, right? So, but it pays off to take some time and put some research into finding out what other people have done so far. And I mean, if you are open source, for developers especially, I don't need to tell

you this. But still, this comes up very often. Open source is all about collaboration, about forking, and redeployment. So please do the research, and which similar tools are already out there. And I'm sure your idea is valid, but then tell us what makes your idea special, and

why it's better or different or more focused than the existing solutions that are out there. And if you find that actually and honestly, it would be enough, or maybe even better, to contribute to an existing project, then you might consider doing it.

Yeah, just, you know, for our application process, you're going to see in there, there's a section that says you have to know something about what's complementary or competitive to the ecosystem that you're trying to get involved in. This idea that you're a special unicorn, no, sorry, it's probably a good idea, but it's definitely not so wholly unique that no one else has thought about it, or that

someone else hasn't done it. And you strengthen yourself by talking about the ecosystem that you're in, and how you're complementary or competitive to that, and what your value add is. But everyone's standing on the toes of giants here, and someone's going to stand on your toes and you're standing on someone else's. So just come into that knowing that that's true will strengthen your chances often.

I will build a platform that will. That's an all-time classic. Sometimes it seems a bit like software development, or the aspiration of software development is building platforms. Build one and it will magically make things better.

But yeah, that's the trap number four, because platforms by themselves do not solve problems, right? They do not magically bring people together. They do not magically bring solutions and problems together. So if you build it, there will not be a guarantee that anyone will come.

So a lot of times, building the technology, and I think that's true for a lot of projects, building the technology is not the hard part. The hard part is to engage with communities, to figure out communication strategies, and to not only focus on your tech solution, but what comes after the tech solution and

before it, and what's the context, and how does it fit into that context? Yeah, I'm sorry, I'm just laughing at all of these because I'm guilty of every single one of them so far. I've done and made all these statements at different points in my life making technology, and I have a dog that does exactly that same thing. So this is just, I'm loving it.

I mean, we're going to obviously emphasize the human-centeredness of this over and over and over again. The ubiquity of actual platforms that you're building technology on and how accessible they are to everyone can't be overstated. So again, the novelty of what you think you're doing technologically versus the uniqueness

of how it's helping people or engaging people, that's where the real novelty is, at least for us as folks who are literally seeing thousands of applications a year for technology. They're not as unique as you might think, and one of the things I think we're both

committed to, just to add a little side of this, is making that much more transparent and accountable so that you can see what it is that we see in a responsible way. And no offense, realize how, where the special things are and where the special things are. Yeah, absolutely. So this is trap number five, which I like a lot.

I built something like Tinder, bot 4, X, Y, Z, and you can replace Tinder with every other tech hype we've had in the past 500 years, I guess, so people have always been saying that, right? But I mean, this is a no-brainer, but a mechanism that works in one context doesn't necessarily work in another, and so this is one of our mantras.

You know, all the saying that form follows function, right? So our mantra is method follows problem, and it should be that way around and not the other. So I know that sometimes you want to be playful, yeah, there's a gift with a beer. I mean, hey, what else can you want?

So yeah, I know that sometimes you just want to try, you know, how this works. You want to analyze it from a technical way, but if you want to develop a helpful tool, okay, this is not a helpful gift, I guess. This is a great gift. Then you should work the other way around. You should analyze the problem first and then find a fitting solution and choose the

method accordingly and not the other way around. This is really something that I would like to stress. Yeah, I mean, I think that, again, you can see on our website the projects that we've supported, and when you go look at some of these projects in particular, thinking

of some of the really big ones like Signal or Tor that we've supported, you'll find in their community a lot of people that are thinking in the challenge space and constantly themselves having to reconvince that the thing that they're working on is the thing that's solving the problems that they care most about as a sort of, you know, a cognitive dissidence.

They don't want it. They're always trying to reconvince themselves every time they come to apply or look for things like that. So, you know, again, these are some of these really good things that just keep you out of your own head and assuming that, like, the thing that you're building is the best thing to build. Just don't trust yourself and always be looking at community to help you do that. And also sometimes it works out, right?

Like building, like applying this method to something very unusual might work out. It's not, we're not saying that it's not working at all, but, like, to, yeah, think about it. Next. A command line tool checking SQL statements sounds a bit geeky, huh? And it is, but the geeky part is not necessarily the bad thing about this statement.

The problem is that it's really just for a tiny group of users. I call tools or proposals like this, like proposals for the one percent, and by one percent I don't mean billionaires. I'm aware that these tools can be important, but please help us understand why they're

important, what the larger impact of these tools is, because otherwise, like, our fund is money. It's basically tax money that we're handing out, so it's difficult to fund, like, tools for the one percent. We actually don't want to, like, yeah, we are looking for stuff that really has impact.

Yeah, and, you know, I totally get that there's a little bit of a toss between the first one, which is like focus on a narrow group, but at the same time not so narrow. And I think that that's, again, it's going to come back to know, you know, your, know your tools. If you look at OTF, I'll just call myself out for some really bad decisions we made

in like five years ago. Some of the first tools we supported were definitely in this category. And then we learned and realized how that's not good for people and end users and have since learned with colleagues like this how to ask better questions and make sure that you find that right balance. So, you know, it's not going to be perfect every time.

So yeah, that's the last piece of advice, and I think it basically explains itself. So my tool is the pebble that will start a landslide. Wow. There. That's a bold statement. Right. And as bold statements go, this is definitely not the only one that we've read. So I mean, sure, it's good to be confident, but well, too much is too much.

And be realistic and come as you are. Your proposal doesn't have to impress us with with salesmanship, with bold claims, but with content. And it's there. We know this. So focus on the content and not on the exaggeration. We believe in your idea and there is no need to exaggerate that much.

Your proposal will be more convincing if there is a realistic assessment of its success and of its impact. And I also just want to recognize that for most of the folks that you're trying to get money from, they really love a good pitch that sounds unrealistic. And even though they mostly know that that's not what they're looking for as well,

but I will tell you the projects that I've seen are the most successful, whether it's a social, a civic or an entrepreneurial based goal, those projects that know exactly what it is that they want aren't afraid to convey that in a very honest and realistic terms. And essentially, at the cost of getting money, the money that they do get

from the funders that do fund them is much better money to have. It's so much better money to have because you're not sitting there racing against some unrealistic thing that you said because you pitched someone an elevator and got them really excited. You're working with someone who totally gets what it is that you're trying to do with realistic timelines and realistic constraints. So I just can't overstate how important it is to know yourself and make sure the

people you're working with understand you as well. And there's no unrealism about it. Yeah, and here we are making a cut because after lecturing you on how to make your proposals better and more perfect. And like Dennis Wright, like we're guilty of all of this, too.

Like we've written proposals, the Tinder, 4X, a platform, la, la, la. It might be a helpful checklist if you write a proposal to run like through the slides and like figure out what is stuff that that helps me to get my proposal better. And yet I'm saying cut because now we're going to talk about

like stuff that did not work out or like stuff where we've not that that has not worked out for us or like where we like have to like where we've made like big mistakes. And the thing is that we're we're not interested in pointing out mistakes. Our main interest and one of the biggest challenges is it to create a culture in which it's allowed to make mistakes, in which it's good to make

mistakes and to talk about mistakes and to tell us like what the programs are not like doing good, what they could do better. So here are two fail stories. And the first one is really great.

There are so many fail stories about OTF. I can't even like I wouldn't know where to begin. And so I sort of I wanted to take like a decision that we made that wasn't good from a project standpoint. But we there's a very well known messaging app, for example, that you all are probably used or very familiar with or are using. Even right now, it's sending notifications to your

phone. We had this opportunity. It's not an open source project, sadly. And we don't only support open source, but we've never supported a proprietary thing before. We just haven't made a good no one's made a good case for it to us yet. But back in like 2012 ish before it was

really well known, there was an opportunity for us to do something to introduce end to end encryption so that it had off the record messages before. It's much more. It wasn't as widespread as it is now. We don't all have it on WhatsApp and what other other applications. And, you know, they they they were like sort of excited about it, but it wasn't really within their remit. And so they said, well, it'll

cost a few hundred thousand dollars or a couple hundred thousand dollars, a very small amount of money. We're like, oh, but man, that's a proprietary project. Who's really going to use this application? No one's using it now. No one is going to. Why would someone use it? It's a replacement for email. What like IRC? What like who's going to use this application? So we we politely declined and

said, no, we don't we don't see how it's going to be used. Of course, like a year and a half, two years later, we're not only the only one. We're using it. Everyone is using it. Everyone is all over it all the time. We go back to my hey, you think maybe we could come back to a couple hundred thousand dollars? You think we can get into an encrypted? They're like, oh, no, no, no, no, no. Now, now we're talking about like a, you know, seven figure high like number to do this. Are you still

interested? I don't have that much money. So all is to say is despite all this rhetoric, even in our experience of thinking like we've got good rubrics for knowing what's realistic, what users are going to use, we're going to mess up a whole bunch. And at the end of the day, you know, your applications and the information you give us is how we learn when we're failing and how we can be better. So I just wanted to

make sure as much as I laugh, we've made plenty of mistakes, at least at OTF. Absolutely. Well, we haven't had one of these content fails. I would like to call it like that because we're just too young. So check again next year at Republica, we have probably some stories to tell them. But we have failed in technical

ways already, which are especially embarrassing for us. Because we want to fund privacy tools. And we claim that protecting your privacy is really, really important and crucial in these days. So here's the story of my biggest embarrassment so far. I didn't realize that our SSL

certificate used SHA-1 somewhere up the chain. And it wasn't the cert for our just plain info website, but for the submission form where we ask you to submit all your personal data and private information. So luckily for us, in fact, at the time when we opened the submissions, most

browsers, especially those that are not the Internet Explorer, stopped displaying websites like ours. And there was just a big warning sign there. So this is not trustworthy. You don't go there. And we got some very immediate and direct feedback from people who wanted to submit their ideas. And so

yeah, thanks to us. Sorry, thanks to you really telling us that this doesn't work. And this is not okay. And we're not going to submit any content through a website that is not secure. Just give gave us the possibility to improve and to check on that. And yeah, without you, we wouldn't have

been able to fix it so fast. So yeah, this is how we really also need you to work together and to improve together. I think this is where I'm supposed to talk more about that. I can't tell you how, at least I know this is true for both of our programs, because we've both been very open. That last point that you stressed is we're nothing

without a the applications that you submit to us and we're different than like a traditional startup. And then you know, we have an we have an open call. It's very competitive. And we're supporting open source technologies without actually seeking a return on any of the successes or money that you might make. That's the first step. The second step is I can't tell

you how much we change just on the conversations that we're going to hopefully have later. And the three o'clock meetup, we're there just to answer any of the questions you have. I'm going to bring my laptop, I'm gonna be logged into our website. And if you point out something that's like wrong about that, I'm going to make that change right there. I've done that probably five times since I've been at this conference in the last two days where someone is like, you're saying a thing that doesn't make any sense to

me. And I'm like, you're totally right. When I say that out loud, it doesn't make any sense to me either. And then we change it, and then it makes sense. And so the community feedback, the pointing out what we're not doing good enough for you, and then being accountable and showing you how we've changed, and then empowering you to keep doing that over and over and over and faster

again, is is the only way that we're relevant and useful here. And we kind of we constantly want to know how we can be better. So, you know, just supporting that culture, we're trying to make it true to our core. Oh, yeah, right. Okay, so here's the deal. We ended a

little bit, we got two minutes. We're not going to do Q&A now, and we don't like that. We want to, like, ask your questions, but we got this whole other meet up at 3 p.m. But what we're interested in doing right now is if you have questions, we would love for you just to make it, I mean, really, really quickly say it. So no comments, please, now, unless you've got a question. But

just so that you all can hear what everyone else is thinking, and also for the live recording that's being being done here, if you want to really quickly ask your question, just for the record, we will answer those questions at 3 p.m. And if you come, we will, we will, we will be yours for as long as you can stand to be around us. Okay, so really quickly, who's got questions that they want to? Okay, we got one.

Anybody else? Come on, it's got to be more than one. Real quickie, do you also support open hardware projects? Was it just software? Not yet, not yet. Don't answer the question. Not yet. We're like, other questions? But

there's a longer answer to that. So come to the meet up, really, like, okay, okay. Since we've got another minute, you can also make a comment as long as you make it really quickly. No comments? We love your presentation. Thank you. That is all of

them. Okay, thank you all. Thank you very much. Thanks. They've just the place. Can you tell us where meetup red is? I don't know where meetup red is.

You know where meetup red is? I think meetup red used to be in the relax zone, and now it's somewhere close to stage four. Does anybody know? So let's all find out together and meet there at meetup red at three o'clock, right? It's like a scavenger hunt. Someone knows?

The info point. Yes, the info point should not know it.