HI, not yet possible. The collaboration aspect of Logseq is under development. Given the speed of the devs, I am sure you will not have to wait a too long.
Hi! Should we expect that what’s free now will remain free in the future?
This wording in the FAQ is somewhat confusing:
Notice that some local features in the future might be included in
Logseq Protoo.
Is it referring to future local features or perhaps current features that could eventually be removed from the free tier?
2 Likes
Should just be future local additions. What is available now, will be free in the future
@Ramses , can you confirm that the team is publicly committed to the view that every feature that is free now will be free in the future? If so, perhaps update the FAQ. I’m not sure why but there has always seemed to be some wiggle room retained here by the team, perhaps unintentionally, and after this much time it should be crystal clear.
1 Like
I’m not speaking for the team here, but personally, I don’t understand the worry. We’re an open-source project, so everything that’s currently available is available for free. Even if we decided to make some feature paid (which we’re not), the community could fork the project and make a “LibreLogseq.”
Especially @tienson has explained several times on the forum, in Discord, and elsewhere that our business model will be pro services. Think of pro services as Logseq Sync or real-time collaboration for teams. We haven’t decided on all the details yet, that’s why you haven’t heard more. For now, we first want to get Logseq Sync to work flawlessly before we release it, let alone charge for it.
3 Likes
Thanks for the response. I’ll try to explain my worry, at least.
First, I note that you didn’t say “the team is committed to making all currently free features free in the future.” Instead, you said you didn’t understand the worry. Part of the worry is that you and the team haven’t made that commitment. I don’t know why there is any hesitancy in making that commitment.
Logseq still seems to be figuring out its business model and has avoided making a crystal clear commitment about what will and what won’t be open source going forward. I’ve suggested some ways they could be clearer about this, and some lines they could draw, but my ideas were rejected, I think because Logseq seems to want to retain the ability to charge for hard-to-develop local features. If the business model is pro services, such as sync or real-time collaboration, then it would be easy to make a public commitment to this by saying “all local features will be free and open-source forever”. If that’s what they intend, then they should put that in the FAQ and state it just like that.
Instead, there have been times in the past where they said ambiguous things like “the current version of Logseq will be open source” but have been unclear about future versions. And, since future versions can break compatibility with past versions (as happened in the past with sync to GitHub) then there is a risk to people who create plug-ins or documentation or contribute in other ways that their efforts will be captured into a product that is more closed then they would have wanted. I have stepped back from my heavy early involvement in Logseq partially because of this resistance to commit to future open-source with clear lines. Maybe there have been clarifications that I’ve missed. But I don’t understand, given the claims about where the money will eventually come from, why they can’t just say “all non-commercial use will be free (as in beer) and all local features will be open-source” and also, ideally, “we commit to maintain standards that will allow non-commercial sync solutions”. There is just a big difference between a clear statement that local features will always be open-source and a slightly wiggly ambiguous “our focus is making money on commercial sync and our current local features are open source and we want to have a good relationship with the community”. If your business model is pro services, why not just say “non-commercial use of Logseq will always be 100% no cost” or “non-commercial features will always be open-source”? I think the answer is that Logseq is still figuring out the details, but if that’s the case, then there is the source of the worry—the decisions haven’t all been made and the commitment isn’t yet there.
The idea that the community could fork Logseq is true in a sense, but doesn’t eliminate the worry for me. Most users don’t care so much about open source, so most will follow the product where it goes, and it’s really rare for an open-source product that goes partially proprietary to have a successful fork once the dev team is no longer working on the open source part.
Lastly—and I honestly don’t mean this in a snarky way—if you are not speaking for the team, you may want to avoid statements about “we” (such as “we’re not” deciding to make things feature paid) that imply that you are speaking for the team.
Perhaps I’m the only person worried about this sort of thing.
4 Likes
I think there is good reason to be concerned. I’ve been disappointed in the way Logseq’s business model has developed over the past year. When it started Tienson was (still is) pumping out some amazing work but I think he’s fallen into the typical US-led start up trap. My concerns are;
- Logseq incorporated in the USA; a country known for imperialism, violating international human rights, and spying on its citizens data. I’m not planning on giving money to a service who’s income tax will go to paying for weapons and policies that rain death and destruction around the world. I was hoping they would incorporate in a neutral country like Singapore considering the founding developers are based in China (which also doesn’t have the best track-record on human rights but at least they’re not invading countries every other year.)
- They are planning on setting up their encrypted sync on US servers. Again I can’t trust that the encryption will be fail-safe when they’re using servers in a country that has multiple examples of spying on it’s own and international citizen’s data, and still continues to try to this day.
- They accepted seed funding from venture capitalists. If anyone is curious they can look at why Nextcloud was created (What we can learn from ownCloud’s collapse). Nextcloud is an off-shoot of Owncloud. Owncloud started in Germany, followed the same path as Logseq where they were wooed by fast American cash, and they, like Logseq, set up their head office in Boston. The CEO of Owncloud realized that the venture capitalists were trying to monetize his software in violation of the best interests of the users/the community, and so he decided to fork the code and create a German-based truly open source software called Nextcloud. He’s made multiple speeches about this actually, how US-style of venture capitalism/software industry culture was killing the app.
I suspect they chose an entrepreneurial young mind in the USA to handle the international-side of business and operations development and that smart young mind chose the easy route to incorporate in the US for the tax benefits without realizing the trap they’re walking into regarding the sustainability of the software. The run-way is for a few years and hopefully they can grow enough for a fork to be created, but eventually the CEO of Shopify and others are going to come knocking on the door and say you need to nerf this feature or that feature so we can get more revenue. Oh, and don’t focus on documentation, or community concerns, because this is a business and we follow the american style of business (as opposed to say, the German-style which is less focused on profit maximization).
1 Like
I think it would be most constructive to keep national politics out of this discussion and focus on the policies of specific people or groups connected to Logseq. We are trying to discuss open source policy here. There are more appropriate venues to discuss human rights or imperialism.
6 Likes
Pro services are exactly our business model. However, more and more of the technology that we use is local-first, so we can’t make a blanket statement like “everything that Logseq runs locally will be free forever.” What if some crucial local part of Logseq Sync can’t be open-sourced because of business concerns or licensing issues? We’d then backtrack on that decision and it would fly back in our faces.
I’m the community manager and an employee of Logseq, that’s why I say “we.” Everything I’ve said so far I have checked with @tienson who is the founder and CEO of Logseq. But as I don’t set the vision or strategy for the company, I hope I haven’t given any wrong impression.
2 Likes
There’s actually a lot of research around this; How Corporate Cultures Differ Around the World
https://geerthofstede.com/culture-geert-hofstede-gert-jan-hofstede/6d-model-of-national-culture/
And aside from that, which you didn’t refute, there is also lots of discourse around how venture capitalism affects open source software projects.
I’m not sure how you saw my post as political when I’m referring to tangible differences in how companies are run around the world differently and how this will impact open source policy. Open Source policy is an operational plan (strategy) that comes from the politics of an organization (development process).
I know some countries like to avoid “politics” because of the toxic nature of their political systems, but politics in itself isn’t a bad word. Politics purpose is a governance process to discuss how to best set policy. In this context we’re discussing how Logseq’s operational model (open source) and policies around that model is affected by its politics. I’m inferring that the choice of domicile (USA) could lead to the failure of the project because of the external factors associated with the domicile.
It’s fair to disagree but I don’t believe it should be dismissed out of hand as “national politics”.
1 Like
I saw your post as political because you start by mentioning lots of things that have nothing to do with how Logseq will operate in those countries, such as imperialism and international human rights, and you also make judgments about how countries rank against each other on human rights, and none of this has anything to do with Logseq’s open source policy. The fact that you are worried about gov’t spying in the US but seem to ignore this issue in China, where gov’t has much more explicit authorization to access any company data without check, suggests that you are mixing your personal political concerns with the relevant issues. The simple statement that Singapore is neutral and the implication that Logseq should thus incorporate there is a political position, not an objective observation. Encryption security is also a separate issue from overall open source policy.
The clear focus of this thread is Logseq’s business model, how they will profit and flourish, and how to balance these goals with open-source goals, not how by being based in one country vs another implies support for that country’s politics, and not the security of their encryption model as it relates to gov’t policy.
2 Likes
Bingo—that’s the concern. You can’t have it both ways. You can’t say “we are open-source good guys and we are making a clear long term commitment to the open source community about what features will always be open source, so please donate your time to creating plugins and documentation as a way to make Logseq much more commercially attractive and useful to the community as a whole” and also say “we need flexibility to claim ownership and build technological walls around any features going forward, whether or not these affect the community, because we might have business concerns and profitability issues, and if we do have these issues, we obviously have to choose profitability over community commitments, so we can’t make those commitments or it would fly back in our faces.”
You have not addressed one obvious option, which is to open source local features for non-commercial use and require that businesses pay to license local features for commercial use. I am guessing that this is because you don’t trust businesses to pay to license local features (but correct me if I am wrong).
As far as more and more of the features requiring local code, I have no idea about that type of thing, but it seems to me that the obvious way to go about this is to assume that any business that wants to use Logseq will want sync and collaborative features, and regardless of the percentage of code that is local, it would be technologically possible to open source everything that is truly local and used by only one user, and still wall off the ability to use Logseq with multiple users or across multiple computers. And you could get people to pay for those crucial functions, as Obsidian does.
If the model is pro services, then I just don’t see why Logseq can’t say “the services we charge for and keep closed source are online sync and online collaboration” and also “we are free and open source for non-commercial use but businesses must be licensed” and run things that way.
Also, I’m not sure whether this is just a language/translation issue, but no one else has used any phrase like “everything that Logseq runs locally”, which seems quite ambiguous to me. I think it’s clear what local features are—they are features that don’t transmit data outside one user’s Logseq graph or computer.
@Cobblepot I see where you’re coming from but I see your concerns being a case of the perfect being the enemy of the good.
The harsh reality is that it is really hard to make an economically sustainable, consumer, but somewhat niche, open source product. Since they don’t have a clear plan that has traction, they have to keep some options open.
Personally I am far more concerned that this project will ultimately not be financially sustainable than I am about them backtracking on always keeping the local only version free.
The two primary competitors here are both not open source, and while one is free the other is very very expensive. So Logseq is, by (my perception of) your values, wildly better than the alternatives.
The worst case here is not that they eventually have to charge for some features (even presently existing ones), or even that they may have to make some of the code proprietary, it’s that the entire project runs out of money and your only option is a fully proprietary option.
You are right that there can always be breaking changes. But similarly you don’t have to upgrade. You can keep the version you have now for free. If you don’t want to keep using it, you don’t really have a similar option that meets your criteria, but if you found that, you could very easily switch to it because they have ensured that you have east access to your own data.
Frankly, regarding a viable business model I would actually be relieved if Logseq started charging for their product, but also kept the main code open source so people can easily add features that they value rather than depending on the team doing so (something that’s especially valuable since I get the sense that a lot of their users are developers, or at least are technically proficient). And maybe they could offer a free license to anyone who contributes a PR. 99% of people are not going to spin up their own version of the software if it’s hard to do and cheap not to. So I think as long as they can make money somehow the odds are it will always be in their favor to keep the code open source. Even for stuff they charge for. So my priority would be that the code is always open source, which accelerates development and enables users to build the features they prioritize, rather than a promise that they won’t start charging for the software if that’s their only option vs shutting down.
1 Like
From your post:
“I’m not sure how you saw my post as political”
“In this context we’re discussing how … that model is affected by its politics”
I get what you’re saying. You believe that politics is relevant to the discussion. But nonetheless your post is in fact primarily political and it rests on controversial and unconventional beliefs. Which doesn’t make them inaccurate per se but it does mean that they are likely to lead to an unproductive discussion.
To be clear I’m not saying that you’re wrong or right. Just that I agree with @Cobblepot that:
- Your post is primarily political
- Whether those beliefs connect to the open source discussion depends on whether one believes a lot of the same stuff that you believe
- Even if you’re right that there is a connection, there are many things far more relevant to this discussion than where the company was incorporated and us geopolitics
- Half of your argument was straight up moral in nature (not supporting it because it pays for bombs), which is fine, but it’s not related to this topic
- Getting into that kind of discussion is only going to cause upset and confusion
And finally, since there are many other far more relevant topics of discussion, lets not venture into whether the United States is so morally bankrupt that it deserves a boycott. It’s just not going to be as productive as other topics. You may disagree with that, but that’s my opinion.
Especially since you have already said that youre not going to use the product and therefore don’t have a stake here. And given that your politics are not conventional it’s unlikely that you represent a large part of the market (so I doubt that going against your beliefs is going to hurt their business model, which is what we’re talking about)
I truly don’t mean any of that to be negative or critical. I just am saying I think there are other things that would be better to discuss in this forum, as opposed to in a political group of some kind, where I would love to engage on this topic
1 Like
I’m not sure how long you have been part of this community, but just know that I am not a latecomer to the project entering in with a bunch of purity tests. I wrote a lot of the early FAQs, documentation/glossary, worked with the team to strategize aliases, and have seen the actual development and commitments of the project (only public info, of course, and from my own perspective).
Obsidian (which is what I assume you mean by the free but not open source competitor) is not open source, and they are clear and give reasons for that, but they are free, and commit to keeping everything local free for non-commercial use, full stop. No hedging. So plugin authors know exactly what they are getting, with no developer hedging about wanting to keep options open—you make a plug in, others can use it free forever locally, you don’t get paid, you support the project and the community, and the company will make money only on sync, web publishing services, and commercial licensing.
I don’t think it’s ethically “clean” to encourage the community to continue to put volunteer labor into a commercial product without 100% clear, clean guidelines about how the products of that labor will be distributed going forward and who will reap the rewards. I was spending a lot of time writing documentation for Logseq, who was at the time billing themselves much more prominently as an open-source project, and only stepped back because of various hedges and miscommunications about the future of the project (you can probably search on Discord to find those if you are interested).
I am concerned that Logseq is going to end up like CDDB CDDB - Wikipedia where people contribute volunteer labor under the view that it is an open source project and then, 10k volunteer hours later, changes in business or licensing end up making 10 people very rich due a combination of their hard work and the work of many volunteers who will not reap financial rewards. I was willing to bite that bullet if it was really going to be a forever open-source commitment to the local product, but not otherwise. I still may contribute documentation, we’ll see. I’m happy if Logseq succeeds, and hope it does, but it should (IMHO) based on online and commercial services and it should not try to keep the door open a crack for recapturing local features that it is encouraging its community to build together as a labor of love, just because it is worried that it might be leaving money on the table due to some killer local feature that it thinks will give it a business advantage.
I’m not disputing the good intentions of the dev team. I think they have good intentions. But there are times in business when you feel your hand is forced, and that’s why you should make public commitments up front—you don’t want to allow yourself to be in a position where it seems that you must act in ways that hurt the volunteer community.
So that’s why I say they can’t have it both ways, and why it seems to me that they are still trying to have it both ways.
4 Likes
I’m not making any assumptions about how long you’ve been in the community, although it’s fantastic that you’ve been a contributor for a long time. My point was merely about the purity test. So it sounds like you’re not a latecomer with purity tests but it does seem like you might be an OG with purity tests.
I definitely see where you’re coming from about the idea that in an ideal world people would be told what they can expect in exchange for the labor they’re doing. And I absolutely think you have every right to step back if you feel like important things to you are not being committed to. I just hope that most people don’t agree with you because I think that would be a very bad sign for the viability of this project.
To be clear, if as you seem to suggest, the motivation behind switching from their previous stance was to make a ton of money vs to make a decent amount of money then I agree it would be morally wrong to go back on their world.
But I would be very pleasantly shocked if the alternative was them choosing between changing plans to become billionaires versus sticking to their word and having a perfectly viable project. I think there’s an infinitely greater chance that the options could become having to modify the initial plan in order for the project to survive versus sticking to their word and killing it. My point is that I think it’s very reasonable in such a tumultuous situation when they don’t have a clear funding model to leave options open for the case where it comes down to making that kind of change or abandoning the project due to funding issues.
I do agree with you that keeping the project open source is incredibly important, at least for the core functionality. And I think that barring unforeseeable circumstances that should absolutely be doable. In fact, I think that they should make a commitment to that if they haven’t already. I would think that the license actually would prevent them from closing any of the main functionality but if I’m wrong about that then I think they should make a commitment. Mainly because it would have significant benefits to the community but would not in my opinion have a cost to them. As I said, people are not going to take a ridiculous amount of effort to spin something up from source on their own when they can pay a few bucks to get it easily.
So in my mind, the most likely change would be them being forced to charge for features that they thought they can offer for free forever.
And to me, if their only option to survive is to charge for even the local version, I think it would be terrible for them to not do so and let the project die. Frankly, if it comes to that, I don’t even see why there’s any argument. In that scenario where they don’t charge for it and shut down, you basically have an abandoned project that maybe you can get enough open source contributors to continue, and you have your current version. Alternatively, if they do charge for it and that’s a dealbreaker for you, you can absolutely force the project. You’re right that I agree that’s not super likely to work, but you’re just in the exact same scenario as if they shut it down and you had to make it work anyway. And in that scenario, you also have your free version forever without upgrades, just like you would if they shut it down. So it really does seem like the two are identical unless they’re doing it to become wealthier as opposed to saving the project.
On that note, I do think that it’s perfectly fair for you to expect them to make a strong commitment and that they won’t charge for features unless it’s to save the project. That doesn’t seem unreasonable at all. But so far you’ve simply requested that commitment with no caveat. As far as I’ve seen.
But my strong opinion is that I would prefer this project to be in a position where they have a stable source of funding and are less likely to shut down versus making a commitment to absolutely under no circumstances ever charge for the local version. Because I think that it’s unlikely that enough people are going to pay for syncing frankly. I would be shocked if that worked out. So my biggest concern with this project is around long-term viability.
I don’t know maybe I’m crazy but it just really seems perfectly reasonable to me for them to end up charging, even for the local product, if that’s the only way for the project to continue, and as long as it’s not an obscene amount.
To that point, I guess I’m curious what your take is? Would you actually prefer it to be free even if that means shutting it down? If they are running out of money and don’t have any other ideas. In this scenario, the source code would be open (hypothetically) and you’d keep the current version for free forever. But you’d have to start paying 3/month for future updates. And it’s to keep it going.
It seems that you are concerned about their funding, but I’m not sure there is reason to be. The project started with Angel investors that are friends of lead dev Tienson. He reported that Logseq pays devs about 2/3 of the salary of similar positions in for-profit companies, I am guessing because the dev team believes in trying to keep things open-source and are willing to make that sacrifice for that goal—at least at the time, not sure how things stand at this point. They have a large dev team compared to Obsidian (not sure how many—maybe 10 at this point? Obsidian has 2). And I think that they got another round of VC funding in the last year (someone who’s been following closely can provide the details, I think). So I just don’t see the concern about them suddenly running out of money. In my mind, it’s just a false dichotomy to think that they must keep all options open or have a real risk of shutting down suddenly. Obsidian is doing fine, I believe, keeping local free (as in beer) and charging for sync. And Logseq of course has the option of making local free and open source for non-commercial use but charging licenses for commercial use.
I am not an open-source zealot. Previously, I suggested that if they couldn’t commit to full open-source for all local features, to just take the product closed-source like Obsidian. I just don’t like them keeping things vague and open for so long and I don’t see the benefit of doing so. It just doesn’t make sense to me why they don’t make a clear commitment with clear lines and insist on keeping the option to claw back local features if they need to “because of business concerns”. I can’t imagine the scenario where they are about to shut down due to uncontrollable expenses and suddenly design some killer feature not available in any other software that people will clamor to pay for and it is going to save the company (but only at a decent profit, not to make them excessively rich ) so they can continue to offer other features free. There is a lot of competition, they used to promote open-source as their central differentiating feature, I promoted Logseq all throughout various notetaking communities due to this, and then it got walked back somewhat in a vague way where they are hesitant to make a clear committment going forward, and it made me uncomfortable, because I can’t understand the motivation for it.
Make local noncommercial free and open source forever; charge for commercial use, sync, and collaboration; and make a commitment to this going forward. I’ll sign up, help write the docs, promote the product in my courses to my students, encourage others to develop plugins, etc. The dev team can try to build a successful business and I hope they do so. They get the psychic benefit of building a useful open-source product that still provides a decent funding stream even though they might leave some opportunities for even more profitability on the table. If it fails, well, that’s software development for you, at least you build an open-source product that can still benefit the world, and you can startup something else new or get another position. Or, take the Angel and VC funding, try to keep all options open, worry about scenarios where the dev team might lose an opportunity to get rich, and hope that enough of the community doesn’t notice or care about these issues. If it fails, maybe there’s enough of what remains to still be useful open-source for a fork project, maybe not, but it’s less likely without that core commitment driving day to day development. I’ll pray that they don’t go the way of CDDB/Gracenote.
4 Likes
Thanks for your thoughtful replies
That’s totally fair enough and everyone has different priorities. I use Logseq because I believe that it is developing into a better product than Roam. And I see it being open source as being a driver of that development speed. Conversely, I think their business model is very shaky which seriously concerns me. And as a consumer, my biggest concern is that if Logseq dies, it will take a lot of time and effort to migrate to Roam, not to mention that I will be sad to do so since I think an open source model is better. (on the other hand, I did check Github and I was sad to see that there are not a ton of contributors to the repo - it looks like 90+% of the lines of code / commits are by employees rather than contributors, so maybe I’m wrong about it making a big difference here).
Idk what they pay their developers. At a big company, good developers make around 300k. You said 2/3’s but let’s just assume that they’re making 130k in salary. If there are 10, that’s 1.3MM per year. They did indeed raise a seed round of 4.1 million. So they have about 3 years, in a best case scenario (likely they have plenty of other costs). They won’t get another funding round if they don’t get explosive user growth or have a promising funding model.
The problem I see with their current model is that:
- The conversion rate from freemium to premium is around 1-2% typically
- It will probably be a lot less than that because if they’re offering syncing as their main feature, that’s something you can already get for free using iCloud, Dropbox, etc. Maybe those services won’t be quite as good as theirs, but it’s good enough. Collab on the other hand might make it work, but I’m pretty concerned about that. Publishing is absolutely doable but I think that’s a pretty niche option. Real-time collab on the other hand, has two issues: a) logseq and roam are niche products. how many of your friends would know how to use it? What are the odds you just use something like Google Docs instead? I’m not saying there isn’t a use case, but I think it’s limited. And b) This is not trivial at all to build. Esp since that hasn’t been their focus from the beginning.
- Significant commercial use is a real stretch IMO - for more reasons than I can even get into. Top 3: a) they don’t have adequate collaboration features. b) they are a precarious startup in a market that is full of other precarious startups. It’s not guaranteed at all that they survive more than a few years, and it’s not even clear that their competitors will either. The vast majority of companies go for companies like Microsoft, or if they’re adventurous, Atlassian. If they’re a startup themselves, maybe Notion. c) The training involved to get people familiar with this kind of tool is significant. So basically maybe this could work eventually, but I’d be stunned if it worked in the next 3 years.
- They have really committed to a local-first model, so there aren’t going to be a ton of options for advanced features that they can charge for if they commit 100% to never charging for local use.
- So if sync and collab are the main things they can charge for, I seriously doubt they get past 1% conversion (which is already solid). In that case, let’s say they charge 5/month. To support their current costs, which we estimate as 1.3MM (not even make a profit, just cover costs, and also I know that’s an estimate but I doubt it’s off by more than 50%, so let’s use it for now), they would need 260k paying customers. At 1% that’s 26 million users. That is just straight up not going to happen. Frankly, I think 2 million is a HUGE stretch. I’d be surprised if they had more than 200k users now. So even if we’re off by a factor of 10 on any of those numbers, it still doesn’t work.
- Conversely, I think if they make lots of new features paid instead of free, they may be able to boost the conversion rate. It’s not about a single killer feature (ironically, because I see sync as buying into the idea that a single killer feature will solve it), it’s about offering a solid product for free, and an incredible product for a fee. But unless you want this to no longer be a local-first model, they are going to have to make local features paid features in order to do that.
So for those reasons I am FAR more concerned about them surviving at all than I am about them exploiting people by making billions on the backs of early contributors.
As a consumer and believer in open source, I want this project to be a slam dunk. As an investor, I would not put money into it right now (I’m sad to say that btw).
Finally, halfway through writing this I actually was re-reading their licence on Github and I actually came across a post they wrote about what they commit to and what they don’t (https://docs.logseq.com/#/page/faq). No idea if it is still relevant. But, and this is what I would recommend personally, they seem to commit to keeping all lccal features open source (which I’m thrilled to hear), and they commit to keeping all current features free, but they do say that new local features may be paid (and they offer the same rough argument that I do, which is that there may just not be enough new options to charge for in a local first product if they commit to all future local features being free).
On the other hand, I do totally see where you’re coming from. I would probably want a commitment too if I were in your position. But I am of the strong opinion, as a tech investor, that if they make that commitment and don’t have some source of funding unrelated to profits or features (i.e. a billionaire who loves what they’re doing and basically commits to giving them a mil a year forever) that they will be out of money and laying off devs within 5 years.
PS: Oh and to your point about Obsidian, I think that part of their potential viability is that they don’t have nearly as many employees. And also quite possibly more users. At a minimum, more publicity. So I think it’s a trade off - if Logseq wants to be viable with just syncing, they may need to lay off 4/5 of their team, which slows development. Vs if they want to go faster they may need to charge.
And finally, just curious. I know you stated that you didn’t think that this scenario was likely, but what if it truly does end up coming down to either charging for new local features vs keeping them free but running out of money in a few years? And similarly what if it wasn’t guaranteed to fail if they didn’t charge, but let’s say there’s an 80% chance? This is purely hypothetical - I’m just curious if you absolutely think that they shouldn’t charge or if you think that based on your belief that they won’t run out of money anyway?
2 Likes
The fear here seems not to be that some parts of Logseq will be closed-source and non-free in the future (after all, Obsidian is depicted in a favorable light even when it is 100% closed-source now and some of its parts are not only non-free but also quite expensive) but that the inability to make a blanket statement (as @Ramses understandably put it) may be used as an escape clause in the future in order to close everything else. The assertion that the commitment to keep current functionality free has already been taken when Logseq was made open-source is dubious in the sense that the community as a collective may not have the right incentives or coordination in order to fork and continue the project in case it gets closed-source. That said, open-sourcing Logseq would have been a very risky move for the devs if they had second thoughts about those matters at the moment since, after all, the incentives and coordination required to fork might indeed be there. Anyway, decision making is always quite a gamble and I believe Logseq is a relatively safe alternative, all things considered. I’ve been using Emacs for 20 years before and even though the fundamentals are all solid there, people are still afraid that there may not be core maintainers in a few years, so 
1 Like