Skip to content

Read “meaty” books

Every so often I read a book that I can’t describe with any other adjective than “meaty”. They’re large, complex and tough to get through. I read them 5-10 pages at a time. They are slow reads (and sometimes I don’t finish them) but they either change my perspective in multiple ways or introduce me to an entirely new perspective.

Some of these books:

  • Capital in the 21st Century by Thomas Piketty, which changed my thinking on how capital accumulates and what that means for societies.
  • These Truths by Jill Lepore was a re-examination of the history of the USA from perspectives I hadn’t considered.
  • The Case for Mars by Robert Zubrin is a book examining the real world possibilities for space colonization.
  • Refactoring by Martin Fowler exploded my ideas about how to modify software and gave me a new vocabulary too.

The latest book that I’ve read in this category is The Comanche Empire by Pekka Hämäläinen. This book has totally reworked my understanding of native tribes, political economy of the southwest in the 1700s-1800s, US western expansion, the wealth of Texas, social organization and more.

While it is fun to read books that don’t challenge my thinking, it is also good to read these “meaty” books periodically as well.

Ending projects

It is okay to let things end. You don’t need my permission, but I give it to you anyway.

I have let projects go in the recent and far past. It’s hard.

Tips for making it just a bit easier:

  • Sit on it for a while. Don’t make hasty decisions.
  • Give it a good shot. You, of course, get to define what that is, but you don’t want to bounce from project to project. 6 months of effort is my rule of thumb.
  • Listen to your gut. It knows what you really want.
  • Make a list of the good and the bad about this project.
  • If you can, offer to hand it off. How this works depends on the project type (an OSS project is different
  • Allow for a transition period where the project isn’t supported but isn’t quite gone.
  • Realize that changes happen and who you were when you started the project is different than who you are now. That’s okay.
  • Giving up something allows you to pursue new goals. This is a good thing.
  • Say goodbye, either privately or publicly, whatever feels right.

It’s never easy to say goodbye, especially if you have poured your efforts into something for years. I recently let a project I started in 2008 fade away. It wasn’t serving me any more and I had no enthusiasm for it. My life had moved on, and it took me a few years to acknowledge the truth–I didn’t want to maintain the project and couldn’t find anyone who did. While it was very useful for some folks for some time, it was no longer useful or fun for me.

It’s never easy to say goodbye, but it can be the right thing to do.

GitHub actions and workflows

I recently wrote my first real GitHub action workflow at work. It was to publish our website after a merge or push to our main branch.

After this experience, I think these workflows are perfect for simple automation tasks. Things like:

  • Running a linter like rubocop on your code
  • Deploying a simple application (one or a few artifacts).
  • Running unit and integration tests.

I didn’t use self hosted actions, though that seems like a nice escape valve if you want to run things within your own network or run over limit. GitHub publishes the action and workflow limits (storage, runtime) and that’s definitely worth reviewing.

You also can easily stand up a couple of different service containers (right now only postgresql and resdis) for easy integration testing. You can also abstract out your commonly used workflow segments to versioned actions.

It was really a pain to write the workflow, however. I had to push repeatedly to our mainline branch, and there were times I screwed up the YAML or didn’t have my script correct. The feedback loop was slooow. Ouch. There are solutions to run them locally, but I didn’t try it yet.

Other than that, it was a positive experience. If you are using GitHub and have automation needs, take a look at GitHub actions. I am a big fan of CircleCI and have been for years. GitHub actions covers a lot of the same ground. GitHub actions are less sophisticated, but it seems like a definite “innovators dilemma” play. So I expect to see actions to get more and more sophisticated.

The meetup opportunity

I’ve been presenting at a lot of meetups recently. With the move to virtual, if you want to spread the word about your project or company, you can speak to between five and 50 interested developers pretty easily. As a co-organizer of the Boulder Ruby Meetup, I can also tell you that I am always on the hunt for interesting speakers. Zoom makes it possible for speakers from around the world to talk to meetup attendees.

Why might you be interested in doing this? Well, if your product is aimed at developers, speaking at meetups is a great way to display that you and your company “get it” as well as get some brand awareness. It’s definitely retail rather than wholesale, but you’re still getting your name out there.

Organizers look for topics related to their meetup, from speakers who are responsive and know what they’re doing. As an organizer I’m looking for diversity and local representation, but am also happy to have folks from around the world present. We’re pretty open about the talk topic. Some of the talks are about ruby and rails, others are about generic technologies (machine learning, networking) and others are about the tech industry (ethics, interviewing).

Create a presentation

You want this to be on a topic that is technical, and related to your product, but not about your product. For FusionAuth, I present on JSON Web Tokens. If I was working for the Duckbill Group, I’d focus on the top 3 most expensive part of your AWS bill. For TimescaleDB, I’d talk about generic performance optimizations for PostgreSQL.

Do not hit the audience over their head with your product. Instead, display your awesomeness by teaching them something you’ve learned in a field adjacent to your product. Don’t worry, you’ll have your product name on every slide, and you can put in a slide or two about your company, but the focus should be on teaching something, not a pitch.

This is going to be time intensive, and the most effort, so see if you can spin off other useful artifacts. Can you make a screen cast on a similar topic? A blog post? Submit an article to Hackernoon?

You can also pitch a presentation to a meetup without fully writing it, but I’d suggest at least outlining it before reaching out to any organizers.

If possible, I like my presentation to be technology agnostic. Topics like authentication, databases, logging, etc all cut across different languages. Your presentation will be applicable to more meetups if the bulk of the explanatory slides be language agnostic. Feel free to tweak it by including a couple of slides or code examples in a particular language.

Find meetups

The meetup search tool is crap (most of the meetup UI needs some help, to be honest). I ended up creating a spreadsheet with the names of big cities in the USA in the left hand column and the names of various technologies (Ruby, JavaScript, etc) across the top. Then I built a URL searching for <city name>+<technology name>+meetup. Running this query on google was invariably better than trying to use meetup’s search tool.

Once you find a meetup, look at past events to see what kind of topics they cover, if they have online events, how big it was, and how active the meetup is. If it makes sense, send a message to the organizers. This is a good task to batch up and do weekly.

Reach out to organizers

Reach out to organizers via a meetup message. Some organizers aren’t doing meetups right now. You can scout their meetup page and see if they have online meetups. Sometimes I’ll ping an organizer even if they don’t because sometimes organizers will be interested in restarting a meetup or aren’t aware of the possibilities of remote speakers.

When you reach out, explain that you have a talk about such and such a subject and that you’re interested in doing a zoom meetup. If you’ve done it before, mention it, as that may make them more comfortable with you. Also, mention that you are interested in presenting to their meetup: “I’d like to present to the Boulder Ruby Group about JWTs”.

This serves two purposes. It shows that you aren’t a spammer because you took the time to customize the message at least a bit. And, when they reply to you (which can take days or weeks), you’ll know which meetup they run. There’s no way to go from a message to a meetup organizer to the home page of the meetup they help with. What? Yes, as mentioned, meetup has some UI flaws.

Follow up in a few weeks if they don’t respond. Messages get lost or forgotten. I also often ask if it is ok to take the conversation to email, because that’s less likely to be ignored or missed than meetup messages.

If they are interested, nail down the exact date and time (including timezone). Provide them with your bio, talk title, talk description and duration. Ask if they need anything else (pronouns, headshot, social media, the presentation for their review). I can tell you as a meetup organizer that it is quite nice to have these provided.

What you need from them is:

  • how you will connect to the meetup (zoom link, streamyard account, something else)
  • the length of the presentation
  • whether you can give anything away (electronic stuff is good, t-shirts cost a lot of money to ship but are good too)

I had one organizer want to review my talk, and a few others were happy to look at other presentations I’ve given, but other than that, the bar is pretty low. I also have a pretty extensive online presence; if you have less of one, you might need more proof that you will be a good speaker.

Remember, meetup organizers are volunteers and are looking to provide fun, useful content to their peers. Make it as easy for them as possible.

Conclusion

You won’t reach thousands of people when you do the Zoom meetup circuit, but you will get some great feedback on your presentation and help educate folks.

The largest audience I presented to was around 50 and the smallest was around five. I also got some great questions that led to additional slides and helped round out my presentation, which I was also able to submit to more traditional conferences.

Use Cameo for dev focused marketing

Recently, we used a Cameo for a developer focused announcement. If you are not familiar with this service, it lets you request a short video from an actor. You send the actor your idea, pay them, they send you the video, and you can use it for a limited number of purposes. If you, or someone you know, has a favorite actor, it can make for a real fun birthday message. But it also is fun for marketing messages and can help you stand out from the crowd.

My experience below is based on one business Cameo. We plan to do more, so there may be updates.

Why consider a Cameo

It is still relatively unique. I’ve seen a few celebrity endorsements of technical products via Cameo, but not that many. This means that it stands out in a fun way. Using Cameo also gets you easy access to a famous or semi-famous person. All you have to do is submit a form and pay some dollars. Compare this to any kind of commercial, which may involve a casting director, ad agency and other parties.

It also is relatively cheap. I looked at a few actors and none cost more than $2000 for commercial usage (more about that below). While this isn’t cheap, I also saw actors for a couple hundred bucks. We ended up choosing an actor who worked for $500.

Note that a Cameo is a pure brand marketing play. It is fun for shock or surprise value, rather than a CTA. It’s unlikely you’ll get deep technical analysis as well. This playful nature fit with our brand, but make sure it fits with yours.

How it works

You can check out the Cameo site FAQs, but here’s how the process worked for me.

  • Browse actors and come up with a shortlist.
  • Filter out actors who won’t do commercial messages. (Some actors won’t, so check before you get excited.)
  • Decide on a topic to be covered.
  • Review licensing terms for commercial use.
  • Sign up for an account.
  • Put in a credit card.
  • Submit a request on the website. This was limited to 250 characters. (Not 250 words. 250 characters. So the guidance was general.)
  • Install the application to get messaging. (The actor enabled free messaging so he could ask questions.)
  • Go back and forth with the actor and answer clarifying questions, maybe 2 rounds of qs. This had to be done on the Cameo app (boo!).
  • Accept the delivered video.
  • Promote and share it.

Note what wasn’t in there:

  • Any writing talent. I did talk to a number of writers and even selected one. However, after reviewing the constraints, we but mutually decided it didn’t make sense. There just isn’t a lot of room for a complex story line or even a funny line or two. That’s probably why Cameo has the limit.
  • A specific story line. I was able to convey one message to the actor, but otherwise it was in his hands.
  • A lot of back and forth or workshopping. I think I talked about this internally for maybe 15 or 30 minutes and definitely had a good idea of what we wanted to cover. But other than some questions, it wasn’t super collaborative. And, to be honest, that was fine. I believe any actor on Cameo is funnier and knows more about speaking to the camera than I do.

I do wonder whether all the actors would have the same devotion to detail. As mentioned above, the actor enabled free messaging and really dug into the topic. Everyone who watched the video was delighted.

After it is delivered

After it is delivered, it’s time to promote. At the time we bought the Cameo, you could put it on one social media platform or your website for 30 days. We chose Twitter. Then I realized that the actor had recorded 5+ minutes. You aren’t allowed to edit the videos, and the maximum length of a Twitter video is 2:20. So we posted it on an unlisted Youtube link and shared that. Check out the current terms (search for Business CAMEO Videos).

I submitted it to a few online communities, shared in social networks and basically did any other kind of promotion you’d do with an interesting video. It was shared to several email lists and slacks as well. We also bought some traffic.

It didn’t go viral, but it got ~10x the usual number of retweets and interactions as our normal tweets do. It’s unclear if any business came from it.

What I wish we had done differently

  • Understood my limits earlier. I spent a lot of time talking to writers before I realized that 250 characters meant sending over an idea and trusting in the actor. Would have been less stressful to have known that earlier.
  • Be a bit more familiar with the actor. One of the best parts of the Cameo was made in response to an offhand request from a co-worker who was more familiar with their work than I was. I should have done a bit more research.
  • While I focused on the topic and asked the actor to do it in character, I should have included the following in my pitch:
    • How to pronounce the brand.
    • Whether or not I should be mentioned (I was, but that was unnecessary).
    • The optimal length of time (2:20).

At the end of the day, this is a fun alternative (or complement) to the normal boring press release. If you have a character which is in line with your brand or product usage, do check it out.

Online community power outside of devrel

I’ve been working in devrel for while and one of the key components is community–you want to support the developer community around your product or the larger ecosystem. I witnessed this same focus work outside of the developer community and still feel an online curated community is an under appreciated asset. Like all assets, you have to work to attain it, but then after you have it, it pays dividends.

The setting: a little startup in a decidedly nontechnical niche. I’m not going to be too specific because of agreements I made with the company after I left. They did the following:

  • Built up deep expertise in the field before they even started the community. This can’t be rushed, but if you spend a year or two focusing, that’s a a good start. (They’d spent 5 or 10, which is of course better.) This is a critical step that can’t be short cut. If you don’t have this, you’ll have a more difficult time with everything, because you won’t have foundational knowledge about the community for which you are trying to build an online presence.
  • Started an invite only Facebook group. The actual group software matters less than going to where people are. In this case, the target market already hung out on Facebook.
  • Invited people to the group. Not just clients, but anyone who was affiliated with the community.
  • Had a clear code of conduct, especially in relation to commercial activities (aka spam). Discussion of business related issues was encouraged, but unrelated commercial links were removed.
  • Seeded discussions with questions heard elsewhere. Answers were highlighted in blog posts and newsletters as well as shared with the group.
  • Spent time encouraging group members to share their experiences.
  • Promoted the online community to other offline communities with similar interests.

In time (years!, not months), this Facebook group became extremely valuable to the company, in a number of ways:

  • The questions people were asking in the forum could be turned into blog posts, which were helpful for SEO. That is, the company learned from the forum what kinds of questions people the company wanted to target were asking. (Ask if you can do this before you publish what community members may consider to be private! Just ask, sometimes people want their wisdom shared.)
  • The company could see if members were looking for the solution the company was selling. They could then reach out outside of the group and do a gentle ask. Member demand for services could be monitored over time, as group members shifted employers and/or situations.
  • When talking to prospective customers who were not in the group, a membership was an easy, free offer of value. The answers in the group provided insight and many prospects were happy to join, even if they didn’t want to purchase anything from the company.
  • People found the online community and then learned about the company supporting the community. A definite halo effect.
  • If the company has a new offering, they can do market research easily. They know where to find their target customer.

This onlinecommunity definitely isn’t free, even if you use a solution like Facebook groups with no hosting costs. (Facebook groups is not the best option, in my opinion, in terms of long term flexibility, because Facebook owns the user and you don’t have access to information like their email. But at the same time you have to go where the prospective members of your online community are, and anything you can do to reduce friction is crucial.) Moderation and content seeding are also crucial to getting the online community going.

But now that the community is up and running, it is a sustainable moat.

If you run an non-technical business, do you have an online community that you participate in? Do you know of one? If you don’t and can’t find one with a little bit of googling, think about setting one up. It can be a long term sustainable advantage for your business. Like any other assets, you have to invest, but it’ll pay dividends.

You should use forums rather than Slack/Discord to support developer community

Hot take after a year or so of trying to build a developer community. If you can pick only one, use forum software rather than synchronous chat software for community building around a developer platform.

While there are tradeoffs in terms of convenience and closeness, for most developer communities a public, managed forum is better than a private, unsearchable Slack.

There are a few key differences between forum software (which includes packages like nodebb, forem, discourse, and others) and chat software (like Slack, Facebook groups, or Discord).

First, though, it’s important to know what you are trying to accomplish. If you are trying to get immediate feedback from a small set of users, then synchronous solutions are better. You can be super responsive, your users will feel loved, and you’ll get feedback quickly. However, synchronous solutions go beyond chat and include phone and video calls. The general goal of validating user feedback at an early stage is beyond the scope of this post.

But as you scale with a chat solution, major problems for the longevity and value of the community emerge.

Problem #1: the memory hole

This occurs when there’s a great answer to a common question, but it isn’t available or is hard to find. This matters more for community Slacks than other synchronous solutions, since Slack limits free plans to 10,000 messages.

It still exists for solutions such as discord because older messages scroll up. Search isn’t great. As a participant it feels easier to just re-ask the question. If the community is vibrant and willing to help newcomers, such questions get answered. If not, they languish or are ignored, frustrating the new participants. Not good.

You can work around the memory hole as a community member by extracting and reifying interesting chat posts. I have done this by generalizing and publishing the messages as blog posts, to a newsletter, or even to a google sheet. But this is additional work that may not be done regularly, or at all.

Side note: for some communities, discussing current events or just chatting with friends, this is actually a feature, not a bug. Who needs to remember who said what six months ago when conversing with friends.

But for developer communities, friendly chat is important, but so is sharing knowledge; the memory hole actively thwarts the latter.

Forums, on the other hand, are optimized for reading. nodebb even suggests related posts as you begin a topic, actively directing people to older posts that may solve their issue without them ever posting.

And if published on the internet, forums are searched via Google.

Problem #2: Google can’t see inside chats

Google is the primary user interface for knowledge gathering among developers.

I hope this statement isn’t controversial. It is based on personal experience and observation, but there’s also some research.

I have seen many many developers use Google as soon as they are confronted by a problem. Youtube, books, going to a specific site and using that search: these all are far less used alternatives when a developer has a question.

Google has made it so easy to find so much good information that most developers have been trained when they face a problem to open a new tab, type in the search term and trust the first page of results.

Chat systems don’t work well with this common workflow, because all the content is hidden.

This means when you use a chat for a developer community, you don’t get compounding benefits when someone, either a team member or a community member, answers a question well or has an insightful comment that would be worth reading. Very few folks ever benefit in the future.

With chat, people who aren’t present at message posting or soon thereafter never learn from that knowledge.

Problem #3: synchronous communication is synchronous

When you are in a chat system, the information is ephemeral. This means that valuable comments can be lost if there is a flurry of other messages.

People can feel ignored even though the reality is that they just posted at an inopportune moment. This feeling can be intimidating; I’ve definitely felt miffed as a question or comment I posted was ignored or unseen and other people’s questions were answered. “Was it me? My topic? Are other people more welcome here than I am?”

People who like to answer questions may feel the need to do so quickly. This may interfere with time for deep work. The Pavlovian response is real; I’ve felt it myself. It feels “better” to write a response to help someone than it does to write a document that will help many, because the former is so concrete and immediate.

When you pick a chat solution, you are optimizing for this kind of response.

Problem #4: less capable moderation tools

Forums have been around a long time. It’s a well understood problem space. There’s a rich set of functionality in most of them for handling the more frustrating aspects of online community management (see also “A Group is its own worst enemy”).

Chat applications have uneven support for this aspect of community management; I have heard Discord is pretty good, but Slack is not.

Remember that when you are running a community, you will inevitably attract trolls and spammers. Make sure you have the tools to protect the community from abuse.

In addition, make sure you have the time/energy. The community may be able to police itself when it gets to a certain size, but initially and for a long while, with a chat solution you may need to be ready to jump in and moderate.

Forums still require attention, don’t get me wrong, but the tooling and the separation of topics means they aren’t quite as vulnerable. They are a higher value target, because of Google, however.

Problem #5: you’re missing out on long tail content

This issue is related to problem #2, but slightly different. When you are building developer tools, there is a wide surface area of support needed. Questions from developers help define that space. When they go to a chat, someone needs to capture the questions and make them public to help future developers. You can capture this knowledge in formal docs.

When using a forum, the answers are made available to the long tail of searchers without any effort at all. A company I worked for got about 5-6% of their traffic from their forum pages.

That traffic was essentially free because the time to answer the questions was required with either solution. (This assumes the question would have been asked in either a chat or a forum.)

Problem #6: questions can be flippant

When I am talking in person to someone and they ask a question, I don’t expect them to have done a ton of research or thinking about it. It’s a conversation, after all.

The same attitude occurs during real time chat.

For technical questions, this can be frustrating because you want to help immediately (see problem #3) and yet you don’t have all the information you need. In async discussions, because they are async, more context is typically provided by the questioner.

This makes it easier for people who want to help to do so.

Why do people use Slack/Discord/etc?

Wow, so many problems with chat and all these reasons are why forum software is better.

So why do so many folks building developer communities choose solutions like Slack or Discord?

There are two motivations that I can see.

One from the company perspective and one from that of the developer.

From the company side: it helps build community between members.

I don’t know about you, but I am much more likely to pitch in and help when I have had a conversation with someone than if some rando drops by with a question and leaves.

A Slack can begin to feel like a real community, where you know people. It doesn’t feel as transactional when I see a question in a Slack when I’ve seen the questioner post other messages or share a bit about themselves. This type of interaction can happen in a forum, but seems more common in a Slack. This type of interaction makes the community more sticky and people more likely to help. A minor benefit is that chat can be hosted elsewhere for free so the startup cost and friction is low.

From the developer’s side: when I run into an issue or problem, I want an answer as soon as frickin’ possible. It’s blocking me, otherwise I wouldn’t have asked it.

Sure, I can context switch, but that has its own costs. So there’s tremendous value from a knowledge seeker’s side to pick a synchronous method of asking questions.

If you had a burning question to ask, which would you prefer? Hopping on the phone or sending a physical email. That’s the allure of the chat platforms.

I will say that some forum software has built chat in, but that isn’t going to get you an answer immediately.

What’s right for you?

Well, what do you want to emphasize? Long term aggregation of knowledge and a culture of completeness, or community and a culture of immediacy.

As alluded to initially, you can of course use both tools at different times in your community’s evolution. I think the longer you build, the more you’ll move to a forum or other public knowledge sharing solution.

Here’s a tweet survey that I ran a month ago asking how developers wanted to get tech help. (Something else turned out to mostly be “well written documentation”, from the thread responses.)

 

Advice for finding a technical co-founder

So, you’re a non-technical founder. You have a great business idea. You have some market validation.

You’re ready to find a technical co-founder who can help build out your startup. You’ll need some coding done, and you imagine there are a whole host of other technical things that need doing. You want a partner who can help you.

You start looking and realize a few things:

  1. Anyone you pick is going to have a huge role in the success or failure of your business.
  2. You don’t have many developers in your network.
  3. It is hard to find technical people willing to work for equity in your unproven startup.
  4. Any time you post looking for a technologist co-founder, agencies (many offshore) respond, happy to help for $$.

I have had the “how can I find a technical co-founder” conversation a few times in the last week so wanted to share my perspective. This is based on my observations and reading, as well as having been a founder (two times, one successful) and early stage employee or contractor multiple times.

Where are you trying to get

Knowing this is important, as it affects the rest of your search.

Are you trying to get to an MVP you can raise money on? A partner you can work with for a long time (if so, consider the 5 Cs)? An application you can sell to someone? A refinement of your current vision which may have technical uncertainties? Advice if what you are trying to build is possible? A technical network so you can hire quickly?

All of these are valid answers, but different ones shift where you look.

It could be because of who I am rather than indicative of the larger need, but most of the folks I’ve talked to really don’t need a CTO. They need a founding engineer. I wrote about the difference between the two; the latter may grow into the former.

What do you have

You also need to get clear on what you have. The people I talk with often have the following situation:

  • no money (raised or in savings)
  • no tech skills/network
  • an interesting idea
  • a no-code or partially coded solution proving out part of their vision
  • some level of market validation

If you aren’t in a similar spot, you can read the rest of this post with some skepticism. Immediately below I give advice on what to do if this doesn’t apply to you.

If you have money, it’s easy: hire someone.

If you have a network, reach out to that network. Most people are happy to help. It won’t guarantee you a partner, but it can lead you down the path.

If you don’t have an interesting idea, well, you’re in trouble. That’s one of the key things you can bring to the table to interest a tech co-founder.

If you haven’t proven out some aspect of your idea with the tools you have at hand, that’s worrisome. Why not?

What can you offer

Being realistic about what you have means you can be realistic about what you can offer.

Here’s a fact: right now, technically competent people can be hired by companies willing to pay them money pretty quickly.

The idea that you are so passionate about that you’ve quit your job or are working on it full time off hours (if not, that’s a serious red flag to any developer)? That idea is exciting and unique for you, but it is one of many ideas the developer has heard about from passionate would be founders. In addition to not being bought in to your vision, technical talent has the following other considerations:

  • there is significant opportunity cost to joining a startup for equity only. It depends on market and experience, but call it a net swing of -$150k/year ($100k in foregone salary and $50k of debt/savings drawdown for living expenses). Yes, you might raise money, but will you pay market salaries to a co-founder then?
  • the risk is front loaded. I know tech folks who joined a startup, worked their butts off to build something, only to discover that their partners were unable to market or sell what they’d built. Whoops! That was a waste.

So, how can you mitigate those risks?

Don’t stint with the equity. Double digits for sure. Make sure to leave some aside for dilution and/or an employee pool.

In fact, thinking intelligently about equity is a subset of something else you should offer: understanding the business. The Nolo books are great for the fundamentals of business, but you should also understand the domain. If you’ve thought deeply about the domain and the business, you will stand out from the “idea folks” who just have, well, ideas.

Be flexible on working arrangements. In one situation where I was the tech co-founder, I worked full time on the company for the first four months, then half time after that because I contracted to pay the bills. Bring finances up in your initial discussions. Be honest and upfront about living expenses and how everyone has different needs. This will filter out some folks, but that’s ok. Better to do that early.

Push forward on your own. You can get a long way with no-code tools and manual processes. This is a grind, but a tech founder will be impressed by this effort if you get results. If you don’t get results, that might be the market telling you something. You can also start an accountability email list for $0 to share your progress.

You may even decide you want to code. Depending on the complexity of your idea, it may be possible for you to build something using free resources. Or buy a book–you are going to invest years of your life, so buying an intro book on coding is cheap. I’d suggest the Rails Tutorial if you are building a webapp.

I, and other devs, judge non technical founders by their ability to get sh*t done. Show that you can.

Know who you are looking for

Based on where you are trying to get and what you have to offer, you should be able to narrow down who you are looking for. Think about the following factors:

  • risk tolerance, including emotional and financial
  • experience
  • domain expertise
  • personal chemistry (you are going to be spending a lot of time with this person, they’ll know your triumphs and low points like no one else)

Write this down. It’s the start of your job description. You should flesh it out with your vision, experience, and what you’ve accomplished so far.

You want a written job desc because you’ll want to share it with anyone who is interested in helping. That’s the first thing I ask for. Put the job desc at at a URL. It doesn’t need to be fancy, a public google doc is fine.

This lets people easily help by sharing the job with anyone or any group they might think a potential co-founder frequents.

Where to look

Share that job desc with your network. You never know who may know someone.

Tech folks congregate in groups. This is often in a slack. Google for “<your area> tech slack” and you should be able to find something. Join, but watch for a while before posting your job desc. There may be certain channels where it is appropriate. And you’ll get more response if you aren’t a “drive by” poster.

There are also meetups. Google for “<your area> tech meetup”. Again, these are communities, not bulletin boards. Be prepared to join and interact for a while before making any pitches. Could be months.

Angellist is a good site on which to create a company listing and post your jobs. They have an email that goes out to interested folks. That’s how I first made contact with one of my co-founders.

Another option is targeted outreach. Tech folks, as mentioned above, congregate in online communities. They often comment. You can search for comments related to your idea/business and see who is talking about it. They may have contact info in their profile.

For instance, I had someone reach out to me because I’d commented several times about agriculture, and that was the domain of their business. This is a bigger time investment, but can lead to interesting connections. Reddit and Hacker News are good places to start. Doing this helps you build your tech network, because even if the commenter isn’t a fit for a co-founder position, they may pass along the job desc to someone else who is. They may also be interested in remaining in touch; if the company grows or their circumstances change, there may be a possible fit in the future.

When you find the person

Great, you think you have found a co-founder.

Have their skills validated by other technical people. You don’t have the knowledge or perspective to evaluate the co-founder. You are excited about possibly working with someone who can help make your dreams a reality. Sometimes an incubator can provide these advisors, other times your network. (As an aside, you should be trying to build your tech network. When you talk to someone who is helpful, see if you can add them to your startup accountability list.)

When people share equity in a business, it’s like getting married without the sex. Date first. See if there are a couple of projects you can work on before jumping in. Offer to pay them something for these, even if it isn’t full market rate.

Set up vesting for founder equity. Everyone should be on the same page if you are starting a true partnership. This will save you heartache if someone has a change of perspective or goals two years into the startup.

In general, plan for the worst, hope for the best. Discuss exits, future roles (do they want to build a team or continue to be an IC), co-founder departures, and long term vision. Do this even though the business model and organization is imaginary at this point. Having these conversations while everyone is excited about the company will make the inevitable tough times just a little less tough.

Make sure you discuss who will be in control. If you are partnering with a childhood friend, maybe 50-50 ownership will work. I’ve definitely seen it blow up because there’s a tension between the “owner” role and the “CEO” role, so even then I’d be hesitant. But if this is someone you just met, you should stay in control with more than 50% of the shares. Make that clear from the get-go so there is no confusion. That said, you aren’t partnering with this person to micro-manage them. Be clear about the areas they’ll have autonomy in.

I know I had issues with my lack of control when I co-founded companies, but that’s all the more reason to have that discussion earlier rather than later.

When it comes down to it, the technologist is crucial for many companies, but the non technical founder is even more critical. It’s a bit like the product and company is a racecar. The technical founder builds the car, but the CEO drives it. Both are important, but you can often find other car builders once the car is running (to mangle my metaphor a bit).

Conclusion

It’s going to be a long haul to find the right person for your startup.

It might be easier to try to raise some money to pay those ravenous agencies (I’ve worked there, so I can call them that) or hire a freelancer.

But the right co-founder will be someone you can trust, someone who will experience the depths and heights of startup life.

Best of luck finding them!

Open source software business model concerns in the age of the public cloud

A few years ago at Gluecon I was sitting at the lunch table with some new acquaintances. The talk turned to business models and someone mentioned the chilling effect of the public cloud providers on open source businesses. Companies whose main product was open source software (OSS) originally had a straightforward business model: sell support and consulting. (I’m leaving aside sponsorships, donations, dual licensing and other smaller streams of income. I’m focusing on what I’ve seen work to build larger, stable companies. If you are solopreneur you have a different set of options.)

This shifted over time to withholding certain features (the “open core” model) and licensing them to customers who wanted them. Open core was better for companies because it is more scalable and profitable to sell software than it is to sell labor (which is what support and consulting essentially are). Customers won because a certain set of them needed features that were likely not core to the software, such as single sign on or auditing, but were critical for their use cases. These customers tended to be businesses with money to spend. Open core, however, has some problems.

The fundamental one is “what should be OSS and what should be licensed” becomes a pressing question. Building a product is tough enough in general, but now there’s an additional marketing, product and engineering complexity.

The SaaS Business Model Cometh

With the rise of SaaS a third monetization option appeared: offer their software as a service and run it on behalf of their customers. NodeBB, ElasticSearch  and others all do this. The customer wins because they have a lower TCO and benefit from continual updates and the company wins because SaaS combines the margins of open core with recurring revenue. This has even caused some companies to move away from open core. The community remains satisfied because if they want, they can self-host.

Enter the cloud companies. Cloud companies could and did take open source projects, packaged them up and offered them as a service for a low monthly fee.

As a customer, and I’ve been such a customer many times, using an offering from these providers has definite benefits:

  • The cloud operators know how to run software at scale.
  • They are already part of the accounting infrastructure. There’s no additional procurement process.
  • They don’t typically deprecate software (killedbygoogle notwithstanding), so as a customer you are less worried ongoing support and availability.

Adoption by a cloud provider has benefits for the open source project, too.

  • It’s proof the software has reached a large level of customer demand, otherwise the big clouds wouldn’t bother.
  • Improvements to the software or documentation may be donated back.
  • It increases the number of folks who use the software or know about it.

However, those benefits may not balance out the loss or threat of loss of revenue from SaaS hosting. This was the chilling effect mentioned around that lunch table. When I read or ask folks about this issue, I’ve heard three separate proposed solutions:

  • Be better
  • You should be so lucky
  • Close your source or re-license

Be Better

First, as the prime mover behind the product, a company should be able to be better than the cloud operators. Not necessarily better at running all software, but better at running theirs. After all, they built it. This does assume that the best people to operate a service are the ones who built it. This may or may not be true. I think it is definitely true at a small scale–they are going to know which knobs to tweak, and if they run into an issue they can immediately fix it in the code base. As software gets more and more popular, the ability to run it well diffuses, however.

The company behind any project also should certainly have a better sense of customer needs and the ability to map those to its internal roadmap. Of course, being an open source project means that the advantages are fleeting. If anything is turned into code and released, it made available to competitors.

An even bigger issue is that this relies on customers being willing to stick with the company on the bleeding edge. For rapidly growing or changing software that may make sense. Where major functionality is being built regularly, upgrades are an easy sell. But OSS isn’t adopted by the cloud provider until it has a large audience, which means they are likely very functional for a lot of use cases. This means that the company won’t get as many folks on the upgrade train, which makes the “be better” argument more problematic. If the cloud provider can offer a “good enough” experience, then their other advantages start to dominate.

You Should Be So Lucky

This is the argument that the chances of an application becoming popular enough to be adopted by a public cloud are so low that it’s not worth spending time thinking about. I asked Steve O’Grady about the OSS business model predicament at a webinar once and this was his answer.

There’s a lot of merit to this. The biggest obstacle to an open source company succeeding is not anyone taking the software and running it, it’s the software not being useful or known. Obscurity has killed many a company, far more than AWS adopting their software.

But when a company reaches a certain size, this advice is less of a solution and more naming a strategic threat. Yes, they are lucky to have their solution be popular. But what can they actually do about the threat to what may be a sizable portion of their revenue? This argument doesn’t help with that.

Close Your Source

Depending on how the company developed the software, they could relicense or close source. This may require some prep work. First, make sure the software is all owned by the company; have all contributors assign over their copyrights. This will make it more difficult for you to reap some of the benefits of open source: easy contributions from others.

The company can also choose to relicense only certain portions of the codebase, taking a step towards open core. In any case, prepare to consult an IP lawyer.

The company must also be ready for the blowback from the community. Which hurts more, losing something that was once free or paying for something from the get-go? For me, it’s the former. Many of the marketing, engineering and product benefits gained from being open source will be lost; this is the price to pay for obviating the cloud vendor SaaS threat.

The firm could also dual license the software or use something like the Business Source License, which strikes a different balance, but still has some attributes of an open source license.

Alternatives

None of these sound very fun. I think the answer is to back up and consider whether to make a project open source initially. Consider this very carefully initially to avoid pain.

The benefits of open source for a business’ core offering are:

  • Lower friction of adoption
  • Contributions from outside an organization (these must be fostered, they may be free in terms of money but not time)
  • Increased rigorousness for the eng team (coding in public can make code better)
  • Easier to recruit because devs like working on open source
  • More eyes on the code means shallower bugs
  • Marketing halo

Are these worth the risk? I can’t answer that authoratively. If they are, another option might be to prepare for SaaS revenue cannibalization; this may mean going open core, focusing on consulting or support, or possibly never even building a SaaS solution.

There’s more than one way to be open. A company can do open development, inviting customers in to the product process. Would being more open with the development process (using public GitHub issues, for example, instead of an internal issue tracker) allow a company to get some level of contribution from outside the org? This would also imposes that “spotlight level rigor” on the eng team. Could the company make the software “free as in beer”, rather than “free as in speech” to lower adoption costs?

A firm can also release software as open source without taking any feedback from the community (“throw it over the wall”), which may be a good choice if the software isn’t core. Big companies do this every day. Facebook gladly open sources their computer plans and React, but certainly wouldn’t open source the core Facebook application.

In conclusion, if you are planning to build a company on an open source project, think about the main revenue flows for that company and what you’ll do in the unlikely, but hopeful, event the project succeeds.

Slack failing to open with NS_ERROR_DOM_ABORT_ERR error

I use Firefox as my primary browser (version 84 as of today). As part of this, I keep logged into a number of slack channels. These are some of my favorite communities and I go there to chat with folks, learn about interesting topics and hunt for neat links to resources I didn’t know about. Occasionally I’ll even ask a question or two.

Recently, I saw some weird behavior. The slack channels weren’t updating. The notice at the bottom of the browser bar was something like “Slack is trying to connect”.

Hmm, I thought, that’s weird. I tried reloading the page. I couldn’t do it. That is, even hitting control-f5 didn’t change anything. However, I could open other website just fine.

I tried quitting all my browser tabs and restarting. Made sure Firefox was up to date. Checked the Slack status page to see if slack was down. Opened a new tab and typed the slack channel url into the address bar.

Nothing.

So, I popped open the dev tools and looked at the network tab. I saw this error when loading app.slack.com:

NS_ERROR_DOM_ABORT_ERR

That turned up this bug. From a scan, several other folks where having this issue, with slack and other sites. This comment shared the solution:

Clearing storage for app.slack.com fixed the issue, and the Slack workspace loads correctly now.

All I had to do was clear the storage for app.slack.com and Slack started working again, magically. Even though I was warned that it might force me to log in again, I didn’t have to do so.