I had breakfast with Cate Huston and I told her that I was working on a blog post called “Should you build an app or a website?” She opined that perhaps mobile apps, both native and web, are better because they have constraints. When you have a small screen, you have to have a good UI. You can’t offer users every possibility, you have to make some decisions and choices for them on what they might want to do.
Cate talked about an art teacher who constrains kids to black and white charcoal, then to a drawing started to someone else and then to a drawing torn in half. They are more creative and come up with more inspired work because they have artificial constraints.
When I think about really single purpose, simple websites, I think about Google’s home page.
There’s a few apps like that too.
What do you think? What would your website look like if you knew that everyone had to look at it through a 640×320 screen and could only interact with it using touch sensitive gloves because it was raining ice chunks outside?
Can read or can’t eat books?
What I love about open source is that it’s a “can” world by default. You can do anything you think needs doing and nobody will tell you that you can’t. (They may not take your patch but they won’t tell you that you can’t create it!)
It’s often easier to define things by what they are not or what we can’t do. And the danger of that is you create a culture of “can’t”. Any one who has raised kids or animals knows this. “No, don’t jump.” You can’t jump on people. “No, off the sofa.” You can’t be on the furniture. “No, don’t lick!” You can’t slobber on me. And hopefully when you realize it, you can fix it. “You can have this stuffed animal (instead of my favorite shoe). Good dog!”
Often when we aren’t sure how to do something, we fill the world with can’ts. “I don’t know how we should do this, but I know you can’t do that on a proprietary mailing list.” “I don’t know how I should lose weight, but I know you can’t have dessert.” I don’t know. Can’t. Don’t know. Can’t. Unsure. Can’t.
Watch the world around you. Is your world full of can’ts or full of “can do”s? Can you change it for the better?
Many app developers are secretly hoping to win the lottery. You know all those horrible free apps full of ads? I bet most of them were hoping to be the next Flappy Bird app. (The Flappy Bird author was making $50K/day from ads for a while.)
The problem is that when you are that focused on making millions, you are not focused on making a good app that people actually want. When you add ads before you add value, you’ll end up with no users no matter how strategically placed your ads are.
So, the secret to making millions with your app?
- Find a need or problem that people have that you can solve.
- Solve the problem.
- Make your users awesome. Luke first sent me a pointer to Kathy Sierra’s idea of making your users awesome. Instagram let people create awesome pictures. Then their friends asked them how they did it …
- Then monetize. (You can think about this earlier but don’t focus on it until you are doing well.)
If you are a good app developer or web developer, you’ll probably find it easier to do well financially helping small businesses around you create the apps and web pages they need than you will trying to randomly guess what game people might like. (If you have a good idea for a game, that you are sure you and your friends and then perhaps others would like to play, go for it!)
Traditionally, open source software has relied primarily on asynchronous communication. While there are probably quite a few synchronous conversations on irc, most project discussions and decisions will happen on asynchronous channels like mailing lists, bug tracking tools and blogs.
I think there’s another reason for this. Synchronous communication is difficult for an open source project. For any project where people are distributed. Synchronous conversations are:
- Inconvenient. It’s hard to schedule synchronous meetings across time zones. Just try to pick a good time for Australia, Europe and California.
- Logistically difficult. It’s hard to schedule a meeting for people that are working on a project at odd hours that might vary every day depending on when they can fit in their hobby or volunteer job.
- Slower. If you have more than 2-3 people you need to get together every time you make a decision, things will move slower. I currently have a project right now that we are kicking off and the team wants to do everything in meetings. We had a meeting last week and one this week. Asynchronously we could have had several rounds of discussion by now.
- Expensive for many people. When I first started at GNOME, it was hard to get some of our board members on a phone call. They couldn’t call international numbers, or couldn’t afford an international call and they didn’t have enough bandwidth for an internet voice call. We ended up using a conference call line from one of our sponsor companies. Now it’s video.
- Logistically difficult. Mozilla does most of our meetings as video meetings. Video is still really hard for many people. Even with my pretty expensive, supposedly high end internet in a developed country, I often have bandwidth problems when participating in video calls. Now imagine I’m a volunteer from Nigeria. My electricity might not work all the time, much less my high speed internet.
- Language. Open source software projects work primarily in English and most of the world does not speak English as their first language. Asynchronous communication gives them a chance to compose their messages, look up words and communicate more effectively.
- Confusing. Discussions and decisions are often made by a subset of the project and unless the team members are very diligent the decisions and rationale are often not communicated out broadly or effectively. You lose the history behind decisions that way too.
There are some major benefits to synchronous conversation:
- Relationships. You build relationships faster. It’s much easier to get to know the person.
- Understanding. Questions and answers happen much faster, especially if the question is hard to formulate or understand. You can quickly go back and forth and get clarity on both sides. They are also really good for difficult topics that might be easily misinterpreted or misunderstood over email where you don’t have tone and body language to help convey the message.
- Quicker. If you only have 2-3 people, it’s faster to talk to them then to type it all out. Once you have more than 2-3, you lose that advantage.
I think as new technologies, both synchronous and asynchronous become main stream, open source software projects will have to figure out how to incorporate them. For example, at Mozilla, we’ve been working on how video can be a part of our projects. Unfortunately, they usually just add more synchronous conversations that are hard to share widely but we work on taking notes, sending notes to mailing lists and recording meetings to try to get the relationship and communication benefits of video meetings while maintaining good open source software project practices. I personally would like to see us use more asynchronous tools as I think video and synchronous tools benefit full time employees at the expense of volunteer involvement.
How does your open source software project use asynchronous and synchronous communication tools? How’s the balance working for you?
A recent conversation on a Mozilla mailing list about whether IRC channels should be archived or not shows what a commitment it is to remain open. It’s hard work and not always comfortable to work completely in the open.
Most of us in open source are used to “working in the open”. Everything we send to a mailing list is not only public, but archived and searchable via Google or Yahoo! forever. Five years later, you can go back and see how I did my job as Executive Director of GNOME. Not only did I blog about it, but many of the conversations I had were on open mailing lists and irc channels.
There are many benefits to being open.
Being open means that anybody can participate, so you get much more help and diversity.
Being open means that you are transparent and accountable.
Being open means you have history. You can also go back and see exactly why a decision was made, what the pros and cons were and see if any of the circumstances have changed.
But it’s not easy.
Being open means that when you have a disagreement, the world can follow along. We warn teenagers about not putting too much on social media, but can you imagine every disagreement you’ve ever had at work being visible to all your future employers. (And spouses!)
But those of us working in open source have made a commitment to be open and we try hard.
Many of us get used to working in the open, and we think it feels comfortable and we think we’re good at it. And then something will remind us that it is a lot of work and it’s not always comfortable. Like a conversation about whether irc conversations should be archived or not. IRC conversations are public but not always archived. So people treat them as a place where anyone can drop in but the conversation is bounded in time and limited to the people you can see in the room. The fact that these informal conversations might be archived and read by anyone and everyone later means that you now have to think a lot more about what you are saying. It’s less of a chat and more of a weighed conversation.
The fact that people steeped in open source are having a heated debate about whether Mozilla IRC channels should be archived or not shows that it’s not easy being open. It takes a lot of work and a lot of commitment.
We have an Amazon Echo. It’s been a lot of fun and a bit frustrating and a bit creepy.
- My youngest loves walking into the room and saying “Alexa, play Alvin and the Chipmunks”.
- I like saying “Alexa, set a 10 minute timer.”
- And we use it for news updates and music playing.
7 features it’s missing:
- “Alexa, answer my phone.” The Echo can hear me across the room. When my phone rings, I’d love to be able to answer it and just talk from where ever I am.
- “Alexa, tell me about the State of the Union Address last night.” I asked a dozen different ways and finally gave up and said “Alexa, play iHeartRadio Eric Church.” (I also tried to use it to cheat at Trivia Crack. It didn’t get any of the five questions I asked it right.)
- Integration with more services. We use Pandora, not iHeartRadio. We can switch. Or not. But ultimately the more services that Echo can integrate with, the better for its usefulness. It should search my email, Evernote, recipes, …
- Search. Not just the State of the Union, but pretty much any search I’ve tried has failed. “Alexa, when is the post office open today?” It just added the post office to my to do list. Or questions that any 2 year old can answer, “Alexa, what sound does a dog make?” It does do math for my eight year old. “Alexa, what’s 10,000 times 1 billion.” and she spits it out to his delight. He’s going to be a billionaire.
- More lists. Right now you can add items to your shopping list, your todo list and your music play lists. That doesn’t work well for a multi-person household. Each of us want multiple lists.
- Do stuff. I’d love to say “Alexa, reply to that email from Frank and say …” Or “Alexa, buy the top rated kitchen glove on Amazon.” or “Alexa, when will my package arrive?”
- Actually cook dinner. Or maybe just order it.
What do you want your Amazon Echo to do?
Until today, I always considered New Year’s Resolutions as something hard. Something you didn’t really want to do but knew you should. Like lose weight, eat better, get more exercise, … then I read Mark Zuckerberg’s resolution. He’s going to read a book a week in 2015. (And the first book he picked sold out on Amazon.) That’s brilliant! That sounds like fun.
So I decided I too am going to read a book a week in 2015. And because I’m still stuck in this mode where New Year’s Resolutions should be hard, I immediately decided that at least one book a month will be a nonfiction book and I’ll blog about it.
So then I decided I need another fun resolution … meet a friend once a week for a soda or a beer?
What’s your fun New Year’s Resolution? The one that you are actually looking forward to?
My sister sent me a message asking for some fantasy book recommendations for a tween girl. No science fiction; old school authors are ok.
That’s my favorite kind of question! What did I like to read around middle school age?
Here’s the list I sent. Makes me want to curl up for the rest of the day with a pile of books. What would you add?
- Anne McCaffrey’s Dragonsong trilogy. I wanted some firelizards in the worst way! It’s about a girl in a fishing village who loves music but music isn’t what her family values to keep them all fed. It takes place in the same world as Dragonriders of Pern but the main character is school aged girl. (There’s no Kindle edition which is tragic.)
- Marion Zimmer Bradley is probably my favorite pure fantasy author but I don’t know if it’s the best for tweens. The Darkover books were the ones I was thinking of.
- So You Want to Be a Wizard? by Diane Duane was one of my favorites. It felt like it could happen to you. (And it is on Kindle. Kindle Unlimited in fact.)
- My 14 year old boy really liked all of Rick Riordan’s books. They are set in present day with mythical legend that live among us.
- I really liked Robin McKinley, especially The Blue Sword. I just reread them recently. And looking her up, I discovered that she has a book I haven’t read! So I bought Shadows for my plane ride home tonight.
- And of course, Madeleine L’Engle’s A Wrinkle in Time. Except I think I was more of a teenager than a tweener when I enjoyed that.
What else would you add to the list?
Can someone tell who your partner or spouse is by just looking at the list of people you are friends with on Facebook?
Graph of My Facebook Friends
Lars Backstrom and Jan Kleinberg believe they can. In their paper Romantic Ties and the Dispersion of Social Networks they explain their theory – you and your partner have a disperse set of friends. You have friends in common but your friends are not well connected to each other. You are not embedded in each others’ networks.
To show this Christian Rudder, cofounder of OkCupid, wrote an app that will create a graph of your Facebook friendships and calculate your dispersion scores. Using the app, you check out your own graph and see if your spouse or partner is top of your list.
While the model correctly identified my partner (Frank), I have to admit that when I first looked at the list, I was a bit worried. The next two guys on the list (granted 30x lower scores) were people I am not close to and haven’t even spoken to in years. I never dated them. What did that say?
First to understand why Frank and I have disperse versus embedded sets of friends. We share a lot of friends (63), but often only a friend or two from every network. So Frank is Facebook friends with only one of my open source friends. And I’m Facebook friends with one of his co-workers and one of his high school buddies but not a group of them.
So what about those two other guys? My theory is that they know a lot of people (one is a sushi chef and the other one is a real estate agent) and so we must have quite a few friends that overlap randomly but not because we are part of that group.
Do bribes or fines work in your work culture? When your culture changes, some of it will feel like bribes and some of it will feel like fines. It all depends on your cultural background.
I was recently in a small town in Mexico and the (new) city government was explaining to us the changes they were trying to make. At first, I was a bit baffled about why they were spending so much time explaining how things worked. They were explaining how if you damaged someone’s property, it wasn’t that you shouldn’t compensate them. It was just that you should compensate them through a fine and a process, instead of a payoff. That it should be done through the system.
And then it clicked for me. They were trying to change their town’s culture.
The town had a culture of just settling it between the two parties. And they wanted people to obey the laws, the process and the judicial system. Where I live, it just taken for granted that if you get in a car accident, you call the police and the insurance company. Then you, the police and the insurance company work out who owes who what. In their culture, that wasn’t the way it had worked. And in order to change how it worked, they were having to explain the new system and how it worked.
And it occurred to me that the same thing is happening in my work place. Mozilla has grown from 250 people when I joined to around a 1,000 people now. And we’ve added a bunch of awesome people with varied skill sets and backgrounds in order to make us stronger. And all of us have different cultures when it comes to how things get done. Some of us file a bug for everything – even a new cable that you need or an idea for an AB test on a website. Some of us create a slideshow for new ideas. Some of us expect a discussion on an open mailing list. Some of us expect a smaller team to come to an agreement before we open the discussion wider.
Some of the ways we decide as a group to do things are going to feel very natural (why would you have to tell someone to call their insurance company after an accident?) and some are going to feel a bit more like bribes or unnecessary process. (What do you mean I have to open 3 bugs and cc 4 departments?) But together we all have to come up with our new culture.
So, back in this small town in Mexico, I ate my bean and cheese stuffed poblano pepper, covered in a sauce that made my eyes water, and nodded. What do I know about turning payoffs into fines?