Open Source, source available, private..?

Discussion
1

I turned the Sifa frontend/backend repos from public to private. I should have asked for input before doing that, but… here we are. :sweat_smile: Note that Sifa was never open source, just publicly visible code (source-available, MIT on lexicons only).

Too much for one person

I spoke to some people experienced in investing and growing companies. First thing they said: having three products (Barazo, Sifa, and a shared trust/reputation layer) is way too much for a small team, let alone a solo founder. Pick one.

The trust/reputation layer isn’t its own product yet (and shouldn’t be right now), but it could be a good add-on business once either Barazo or Sifa is further along. So the real choice is between those two:

  • If I pick Barazo: clearer SaaS business case, go up against Discourse and the like. Established market, probably some money in the bank sooner, but less eventual upside.
  • If I pick Sifa: more business model options (HR services, verified credentials, fintech, advertising), but none where end users pay directly. That probably means a longer runway to revenue and needing investment. The expectation was that Sifa could have much bigger upside, but it’ll take longer to get there.

Haven’t made that choice yet, but it led me revisit at what makes each product viable as a business.

“Open” matters differently for each

For Barazo, open source has a clear business benefit. Self-hosters still contribute to the AT Protocol ecosystem: their users’ data lives in PDSes, so the lexicon data grows regardless. Self-hosting becomes a natural freemium tier, with upsell to managed hosting and paid
trust/reputation services. The general public doesn’t even need to know the Barazo name for it to work… forum admins are the customer. The average forum user doesn’t know if they’re on Flarum, Discourse, or Vanilla either.

For Sifa, I think this is different: it needs to be a recognizable brand where people share their professional identity link. It helps if there’s a strong network effect, if the recruiter or colleague on the other end actually knows what Sifa is when you send them your link. I’m not saying nobody else should build professional identity on atproto. I’d love that, and the lexicons are MIT for exactly that reason. But I want to compete on UX, brand, and service, not have someone fork whole website and swap the logo. The source-available license already didn’t allow that, but having the code right there makes it a lot easier to do… and I’d rather not deal with that legal distraction on top of everything else. And this seems a risk checkbox on a potential investors checklist so… rather not have it?

Moat?

If your app data is in PDSes (like it is with both products), there’s no data moat in AT Protocol land. That’s why we’re all here… but it also means we need business models that work without one. (I know you can still do private data by having people login with atproto and
storing everything in your own db, but that’s not what I’m doing.)

I get that for investors, no data moat is already a hard sell. Code isn’t much of a moat either, I think that should come from network effects mainly. But letting others copy-paste the entire frontend could look like unnecessary risk to someone writing a check.

Trust though

The other side of the coin: in many ecosystems, having your code visible is a trust signal. Someone can look at what you’re actually doing with their data, how you interact with the protocol. Going private removes that, and in a community built on openness… that’s not
nothing.

Practically, the legal difference between source-available and private is small: someone determined to copy your code could do it either way. The main thing you lose by going private isn’t legal protection. It’s the trust of this community. I’m aware of that, and it’s part
of why I’m not sure this was the right call.

I’d also be happy to give other atproto builders access to a private repo if taht helps you build additional services (like @trysound.io is doing with https://weareonhire.com/, building on Sifa lexicons, super cool) or if anyone wants to review the code.

I know at least one person is already unhappy about this, so maybe the goodwill damage is already done even with a revert :flushed_face:

What others do

Most AT Protocol services are open source: Bluesky (MIT), Streamplace (MIT), Frontpage (MIT), Leaflet (MIT), Smoke Signal (MIT), Tangled (MIT), WhiteWind (AGPL), Graze Social (mixed permissive). Roomy has MPL-2.0 for the app + PolyForm NonCommercial for the services, with a delayed relicense to permissive after 2 years.

Afaik these are closed/private: Skylights, Skylight Social (plans to open source later), Pckt. Not unheard of, but clearly the minority in the atproto sphere

Where I’m at

I’m not 100% sure this is the right call or that it’ll stay this way, and of course changing licenses willy-nilly is shitty and should not happen. I’ve never dealt with investors before, and I’m eager to have at least one of these projects succeed, so I’m learning on the job here. Still very much in alpha, figuring out both the product and the business side.

I think it’s good for the AT Protocol ecosystem to have multiple healthy businesses beyond Bluesky, and I’d like input on how to make that work.

From experience (I worked at Spryker, which is source-available): we had a lot of shops running our proprietary software without a license because the code was right there to copy. Different business model (PaaS), but the legal headaches that caused is one I’d be eager not to repeat. For a product like Sifa where the value is brand and network effects, not self-hosting… does having the code visible hurt more than it helps? Or is that a non-issue and am I completely overthinking this?

But yeah… your view? If you build an atproto app: what license did you pick and why?

11 Likes
2

Hi Guido,

Welcome to the club, as a fellow founder who builds open-source infra (and closed (and sometimes open) source apps).

LinkedIn has also B2C business offerings, therefore not necessarily correct. Its up to you.

Discourse also has a freemium model where their brand is visible on free forums if I’m not mistaken, therefore, in both instances building brand recognition is unavoidable (/benefits the business long term).

If you are building for the open-source developer ecosystem yes having open-source code is unavoidable. But LinkedIn has millions of users and is closed-source. The average consumer does not care about this, they just wanna use a tool to solve a problem.

From my perspective: Focus on the end-consumer if you go for B2C business model, and the users needs/goals/problems and fix their problems. I signed up to Sifa to find a mentor. How will Sifa help me achieve this? (most will likely sign up to Sifa to get their next career)

Sifa is a marketplace, people and companies and you need to connect them to solve a problem for both the company that is hiring and for the professional that is looking to get hired (imo this is the core premise of linkedin).

Re: open/closed-source. As long as you do not have a db, and rely on atp to store data you do everything right. Granted, there might be sensitive data someone might need to share in that instance you should have a private db, and later on support permissioned groups/spaces etc.

Also the above is my opinion and might be wrong, if you’re having a different business model for Sifa that’s great I hope whatever you work on will be successful.

3 Likes
3

Think about a networked business model where others run Sifa front ends / nodes / customizations.

  • Are you going to tackle Japan or Brazil right away?
  • What would city by city job boards look like?
  • Is a film industry specific Sifa useful?

If you’re running just one instance / AppView … that’s fine but may not play to the strengths of the system. What services could you run that lets many nodes flourish?

And regardless - people can and will build other clients around the data if it’s at all successful.

3 Likes
4

I wrote some thoughts on building identity tech that you may want to check out. I’m not saying don’t build an identity product, but the road is littered with tomb stones and no victors.

2 Likes
5

i open source mostly everything w MIT (plyr.fm, standard.site search, etc), mostly bc im interested in proving patterns and sharing them more than i’m interested in monetizing the project. if i were going to monetize plyr.fm (i have no plans to), i’d likely have closed source services that are optional plugins to a self-host-able and open source core (i.e. you could self host my same exact plyr.fm backend, but you’d have to write/deploy your own transcoding service if you don’t want to use mine), which draws from the “open core” model you’ll see people use when they have open-source tooling and a commerical SaaS offering.

just some thoughts! i generally agree with the other comments!

3 Likes
6

Thx all, lots to think about :folded_hands:

@dave.self.surf yeah, end users won’t care about source-available vs private on bit. I think the atproto moat is (will be?) more the UX/convenience of data portability. At some point users might not want to login in non-atproto apps because the users know it will prevent them from reusing any data they put in. We can dream :wink:

For me this is more about initial trust and ongoing collaborations with others in the ecosystem. And you’re right that if we go into the jobs direction (which is one of the logical directions), this would make Sifa a 2-sided marketplace problem. I think the AT Protocol angle makes it interesting because activity data in PDSes could feed into professional reputation… but that brings its own problems (see below).

That is a great reframe :blue_heart:. And you’re right that people will build other clients if this works at all, code visible or not. This is also not something I want to prevent at all (like mentioned in the OP, @trysound.io is already building in Sifa lexicons and I’ve seen other examples as well!).

@boscolo.co “Identity is the tail of the dog, not the head” is a very relevant one for Sifa. How I was thinking about this is that Sifa’s actual product should be helping people find jobs, projects, collaborators… aaand having an Atmosphere Account is (for now at least) the byproduct.

@zzstoatzz.io open core + private added services on top like a trust/reputation engine could definitely work. That private engine doesn’t exist yet so it’s premature to architect around it, but… it’s probably the right direction.

atproto app business moats

I went through a whole variety of moats after reading your replies, and… I don’t think code visibility affects any of them tbh

  • There’s no data moat (atproto, PDSes, by design).
  • Code isn’t much of one either: someone with funding builds something better without seeing my code.
  • “Being first” is the same story. Even the GDPR angle is odd because it restrains me more then competition: as an EU company I can’t just ingest everyone’s PDS data to build reputation profiles without consent (the Dutch DPA specifically lists “scraping to create profiles” as very likely unlawful). But a US or Chinese competitor probably won’t let that stop them, so it constrains me more than it constrains competition.
  • What’s left is network effects (people sharing their sifa.id link), brand, the consented user base, and whatever trust/reputation algorithms I build on top. All execution stuff.

And this all probably applies to all/most atproto apps, not necessarily what I’m building.

So private vs public really boils down to:

  • does it hinder any collab or trust (for some it will, for some it wont)
  • does it scare of potential investors (unknown still)
  • is their moat left is someone would (illegally, but till) copy the website

Or I just setup a https://atprotofans.com/, get enough coming in to pay the mortgage and then it all doesn’t matter what investors think :stuck_out_tongue:

2 Likes
7

I agree.

Data is not the moat since it is open, but its a core benefit long-term. I think the moat is your product and the problems you solve for the people using your product (and having them come back).

I would also strongly urge you to go mobile-first. This was already the case 5 years ago and is more so important now than then. And please build for the average Joe that has never heard of ATP/Bluesky make signup and onboarding simple and intuitive instead of writing about internet handle or whatever new language people come up with.

Network effects is important, but how to do this ethically without becoming a MLM lol. Bluesky is def a key place to start growing but it is also a limiting place because 90% of the world lives in places outside of Bluesky. Tori (from skylight) said this nicely during her talk, she makes reels and tiktoks on other socials because its important to grow the pie and expand ATP/Bluesky.

3 Likes
8

Could user activity data be a moat? Anonymized or not?

If you go the jobs route, you could use what a user is clicking on and searching to inform job matching without publishing each microevent to the protocol. Then even if someone duplicates your app and takes the open data, you’ll have much better signal within your slice of the ecosystem.

I believe this would by why links on bluesky redirect through https://go.bsky.app/redirect?u= and also part of how graze.social plans to monetize with anonymized feed usage data.

PS: Thanks for making this post! I’m thinking through similar tradeoffs with the thing I’m building too :raising_hands:

2 Likes
9

First, thanks for building Sifa - it’s an awesome tool! :raising_hands:

Been thinking about these things a lot over the past few years as well.

I do think that pursuing the “standard VC pitch” in unlikely to produce positive results in this environment. If atproto businesses are going to be successful because of (not despite) atproto’s unique capabilities, is going to require new business models - and in my (limited) experience - business model risk is the kind of risk most investors DON’T want. So I think there is going to be a need to prove that new business models are consistently profitable before there will be a surge of investor interest.

Second, and hopefully more encouraging, I do think there are ways to lean into the openness/interoperability and deliver differentiated value that people will pay for. In terms of “layers”, I tend to think of atproto stuff like this:

Commodities: things that will inevitably have their value driven to near-zero over time. In atproto, this is the raw firehose data, the open graph, the public social signal itself. This is a key differentiator from web2 assumptions before we even start talking about implementation licensing. There isn’t (and, to me, shouldn’t be on atproto) lots of money in gatekeeping data itself.

Universal Value: things that have their highest value when kept open as enablers for everyone across atproto - even (or perhaps, especially) for competitors. Standards, Lexicons, PDS implementations, Moderation primitives, AppView boilerplate, and (frankly) most “Web2 → AT Web” app clones are going to fit this pattern. This deserves to be open source. What made the Web2 business models work was the walled-garden network effects (built on data capture) that atproto is designed to unwind. I think trying to shove the genie back in the bottle is working in the wrong direction.

Differentiated Value: the things that engineers, PMs, scientists, and infra people bring to atproto that is high-value not because of enforced scarcity or arbitrary lock-in, but because of genuine, sustained utility in the atproto ecosystem. These are things that it may not make sense to open source, or - even if the tech is open - the differentiation is about timeliness, reliability, reputation, etc; things that can’t be cloned from a repo. Stuff that comes to mind:

  1. data analysis and enrichment; real-time or near real-time insights will require ongoing effort, but produce ongoing value too. I think there is some of this already happening in moderation and stream management contexts (thinking about the remarkable stuff that blacksky has been doing) - enabling people to easily make better decisions is valuable, requires ongoing stewardship, and can likely provide monetizable services and streams.
  2. provenance & reputation - couple #1 with “oracles” (to use a crypto term) linking analysis with external insights to create strong-provenance assertions about actors and data. I kinda can’t believe how terribly LinkedIn has fumbled this, but there is an absolute crisis going on in recruiting today because it is so difficult to know who is real & qualified vs who is a bot, a con, or even an adversarial national state actor. Money is being thrown into the fire to solve these problems, and all the primitives to address them elegantly are here - structurally - in atproto’s data, graph, and moderation primitives.
  3. permissioned community management - this is, I think, the heart of what people pay Discord for: an amazing experience managing permissioned community spaces. This is not exactly a technical problem (though it has technical aspects) - it is a UX/civic/sociological challenge the requires continued tending, innovation, and expertise. Cloning Discord’s UI isn’t the same thing as tending living communities - but if you can, it’s demonstrably worth a lot to a lot of people.

There are others, but I’ll leave it there. TLDR, I think tools like Sifa can lean into atproto’s capabilities to create disruptive, profitable businesses doing things walled gardens like LinkedIn are either disincentivized from or structurally incapable of doing.

2 Likes
10

this is what it boils down to, if your target audience can trust you with the repo being closed-source and use your app it should be fine.

Also, since everything is stored on ATP, the repo being closed matters only half as much if you can see what happens and what is read/written to the users PDS.

Scoping permissions during OAuth is also a nice-to-have, so that you only request permissions to modify the lexicons you care about. Altough I think OAuth is a terrible UX in and of itself and hope that this will improve.

2 Likes