mattgreg

Another free + open source alt (for Mac) https://github.com/build-trust/ockam/blob/develop/examples/a...

Thanks for the post ToB!

Ockam’s CEO here. If anyone has any questions for me… let it rip!

I really like the visual of the whack-a-mole, it's so brute force, and the game always ends with a flurry of activity... and cursing.

I think it's interesting that Rust is so rarely used among this list of security related projects.

Ockam

https://github.com/build-trust/ockam

would you like to schedule some time with us to dig into this further. This sounds really interesting and pretty close to things we've seen others do before.

To move this off of HN and to a channel that we look at more regularly, I'd like to suggest a couple alts: 1) GitHub Discussions: https://github.com/build-trust/ockam/discussions/categories/...

2) We can schedule a zoom call: https://www.ockam.io/contact/form

great feedback!

ha. love that.

We have two products. The first is avail under Apache 2 lic. The second is available as a paid subscription through AWS marketplace.

1. Ockam Open Source: It's all the protocols, packages, and tools (like CLI) for building things.

2. Ockam Orchestrator: It allows for running small to massive scale systems. It's also has add-ons for Okta, Confluent Cloud, various DBs...

Good question. It's a nested reference. I named the company Ockam as a tribute to a company that a mentor of mine built and ran in the 70's - 2000's. He named his company after Occam's Razor.

The full story: https://www.ockam.io/blog/whats_behind_the_ockam_name

Aw. Thanks for posting this. Hi, I'm Matt, the CEO at Ockam. If anyone has any questions, we are happy to take them on in this thread today.

One good thing about data from Sequoia is that they handle payroll for a lot of companies. They know exactly what companies are paying each of their employees, so it's a really good data set from that perspective. It's not self-reported by employees, for example.

"Concordium aims to fund developers whose efforts are critical to the Rust project but who are not currently being paid to work on Rust full-time. The DevX Initiative takes its lead from examples set by Embark Studios, Discord, Fly.io and Ockam"

We sponsor 5-10 individuals that work on Rust core, cryptography, and dependencies in the Ockam OSS library.

Use the link above to nominate for our next batch!

Ockam does!

https://github.com/ockam-network/ockam/discussions/864

How is this different / when would you use vs a VPN?

I'm curious what the recent data is on the success of YC companies - beyond raising large seed rounds. How are YC co's doing at the growth stage now, vs early batches.

"People realize that securing the transport isn't the same as securing the application, which often hops over multiple transports."

Exactly right. Application layer trust, with the transport and security layers abstracted away. This is important, since app developers typically can't control the transports from end to end, or at scale.

It's a 'feature' of a startup. You become an investor in the company.

The other option is to work at a public company, where stock is liquid.

They aren't really comparable, and a preference for one or the other is personal choice. Both are correct answers.

Startups should move to the 5 year exercise window. We've made this change at Ockam. Here's a list of companies with extended exercise windows

https://github.com/holman/extended-exercise-windows

For tax reasons. If you are given stock you'd have to pay income tax on it when you receive it.

This is a great guide for building a first-ever app in Rust.

If helpful, we open sourced our static site at Ockam.io

https://github.com/ockam-network/website

Want to work with Rust?

Ockam.io loves Rust, and we are hiring!

https://www.ockam.io/team#open-roles

This is a really interesting comment.

I completely agree with the buyer v user persona distinction. If I were on a podcast and someone flipped a coin...heads I argue that Ockam is a B2C company, tails I argue that Ockam is a B2B company - I could do both.

"Freemium" is a good product model in this case, regardless of the OSS part, because "freemium" isn't a pricing model, it's a customer acquisition strategy.

Red Hat is both a great example, and a horrible one all wrapped up into one. They are the OG, but I'm very skeptical that a new project could take the Red Hat 2000s playbook and apply it in the 2020s.

Check out how Peter Levine talks about the 3 'eras' of OSS Companies. I elaborate here: https://www.ockam.io/learn/blog/zero_ipo/#peter-levine---par...

And there is a direct link to his perspective here https://a16z.com/2019/10/04/commercializing-open-source/

100% - the slack pricing model doesn't work with OSS communities.

Also it's a lot of overhead to join a new slack group for a random comment. It makes sense for the discussion to happen in the same environment as the code.

We use Slack internally at Ockam. The original community was on Slack as well.

We moved our community chit-chat to GitHub when we were invited to the Discussions beta. The main reason why I like it: It moves discussion closer to the code. Specifically it creates a nice swim lane next to `Issues`. I think of a progression of `Discussion` => `Issue` => `PR'. It gets discussion out of issues and PRs and declutters comments.

Thanks! I happened to have a unique seat in the OSS world for the past 10 years, and worked with literally hundreds of companies across Heroku Add-ons, and Azure's pivot to an oss partnership strategy. I was a product manager, so as you point out I see the world through a product lens. Most interesting were my vantage points into GitHub, Docker, Mesosphere, CloudBees, jFrog.

This post was already long. It started off as a single slide and turned into this 2500 word blog. You are pulling the thread on a major part that ended up on the cutting room floor - the back stories on some of the companies that I worked with, including the aforementioned.

Great feedback! Product marketing is hard ;)

Basically, we abstract away the complexity of networking security for application developers. Let's say you are building an application that has 2 parts: A weather sensor in a field and a InfluxDB instance in AWS. The application logic is simple. Every 60 secs send a reading to the DB. Most developers could write that logic. However if you want to end-to-end encrypt it across multiple network hops, you need to go find a networking security team with expertise in cryptography. That's hard. OR you simply add some Ockam code to each endpoint and voila you have e2e channels.

To put it another way. Stripe lets an app dev process payments without understanding payment networks. Ockam lets you secure edge to cloud applications without understanding network security.