Open sourcing Warp and business model #400
Replies: 43 comments 70 replies
-
|
I’m happy to discuss the pros and cons of different approaches in public on this issue. On Warp’s side, we are trying to balance competing factors as we figure out how, when and what to open-source. In favor of open-sourcing everything right now is our desire to:
In favor of us moving more cautiously are
My current best guess on how we will proceed is with a more restrictive license that
I would be curious to get feedback from our community on how they would feel about such a license or if there are other paths forward that might be better. Ultimately we will make a decision on this based on the needs of the company, but we value the feedback of our users as we figure out the path forward here. ** As a side note, we also plan on open-sourcing all of our extension points as we go - that seems less concerning from an IP perspective. These are things like our UI framework, themes, completions, and other ways we plan on making Warp a platform. For the UI framework in particular, we are waiting to implement some version of multi-platform support before open sourcing it - this will help us make sure the APIs are right before having others start to depend on it. |
Beta Was this translation helpful? Give feedback.
-
If we only look the Freedom Zero with a non-critical perspective, then you're right. However, the issue about SaaSS shows us that the definition of Freedom Zero is incomplete. Starting from the current 4 principles of freedom only, we could absurdly conclude that, some SaaSS, whose spirit is completely contradicts with that of free softwares though, are free softwares. To avoid such antinomy, we must consider the behaviors that providing services to others as not only running the software, but also distributing the software. |
Beta Was this translation helpful? Give feedback.
-
|
We're coming up on two years now. Has there been any progress in this area? The rough plan that was outlined of open-sourcing the client parts under a restrictive license seems very reasonable and achievable with minimal fuss. The concern about not wanting to spend engineering time handling community contributions is a valid one, but is not relevant in terms of making the client open-source. Just because you're providing the source code to an application under a certain license, doesn't mean you're obligated to accept any contributions whatsoever. That's a completely separate concern. Others have already outlined the serious security and privacy concerns that prevent us from using what seems like a great product. My terminal sees far too sensitive information that I can just trust it to a closed source application that I have no way of auditing, from a company that I don't have any kind of data processing agreement with. Having a few bits and pieces be open-source (themes and workflows) is irrelevant from that perspective. |
Beta Was this translation helpful? Give feedback.
-
|
Open-sourcing and restrictive license are antonym, the only way to make something open source is to use one of the OSI approved licenses. I'd like to add that the best license for this king of business model where you want the open client is the GNU GPL3 license. That's how Ubuntu, RedHat and all others have been doing it for years. That's the best way for users and the company, you can fork it and do whatever you want with it but the source will always stay open and there will never be a situation when the company behind the product is not able to reap the benefits of it because nobody can take it and close it down, it stays open. |
Beta Was this translation helpful? Give feedback.
-
|
I just wanted to add in another perspective that I haven't seen mentioned here. If you're planning on open sourcing other platform elements like the UI toolkit, that's great. But if you do that without also making the terminal itself open, aren't you just asking for an open-source clone to spring up using the parts that have been open sourced? And I'm not saying that a clone would necessarily be a bad thing or harm Warp the company. The open-source project would likely have fewer resources and there'd still be reason for customers to choose the original closed source version. However there will still be plenty of people who would choose an under-resourced open source clone over a closed source terminal even if it meant forgoing some features or polish. But what a waste that would be, since the effort the volunteers put into the clone could have been going into Warp proper! And while it is surely true that even after you open-sourced the Warp terminal the vast majority of feature development would still be paid for by the company, open source devs would nevertheless likely be very useful and finding and fixing system-specific bugs and performance issues, that kind of thing. What developer will put up with a problem in their terminal - we must track it down and fix it right away! |
Beta Was this translation helpful? Give feedback.
-
|
I doubt their UI toolkit is better than other open source toolkits already available. Why wouldn't you want people forking and creating their own versions? That's the whole point about open source and if you use GPLv3 license then nobody can create a closed source fork and they have to contribute their changes upstream so it's always a win for the initial developer. But they want the clout of FOSS software while locking down users etc. They are a proprietary project and they don't have a clue about how FOSS is done nor do they care otherwise it would have been an FOSS project from the start. So this is a big bs they are giving us. |
Beta Was this translation helpful? Give feedback.
-
|
A license similar to Onivim 2 strikes me as a good idea for this. Copy-pasting from an older version of their README (they've since switched to MIT)
There was also an interesting thing not included in the Outrun Labs EULA, but in addition to it - a time-delay dual license. Commits from employees became MIT-licensed after 18 months in the master branch. Community contributions were MIT immediately. IMO this strikes a really good balance between a commercial product and being open source. The community can audit the code, contribute features, fix bugs, and reuse their code. Other companies can't legally take the main product and re-package it as their own. People who wouldn't buy the product anyway (basically just hobbyists like me and students) get to use it for free, but using it commercially would require a license. (Oni2 failed commercially not because of the license, but because a vim+vscode mix is a very hard sell to VCs. It's been switched to MIT now to encourage the community to take over. Warp doesn't share the same problem since the target market is literally every developer instead of like... 2000 people at most) |
Beta Was this translation helpful? Give feedback.
-
|
+1 for the delayed open source approach. |
Beta Was this translation helpful? Give feedback.
-
|
I am very much looking forward to being able to pay for Warp. Open source is a mechanism to provide assurance around the code but it might not be the best one. 1Password is a great example of a company that creates a lot of confidence in their security critical products without open sourcing much. Paying for third party audits might be a significant step forward. It's much more important that Warp build a sustainable business here than immediately open source. |
Beta Was this translation helpful? Give feedback.
-
|
To go against your point about 1Password, Bitwarden is FOSS, and is still a business. |
Beta Was this translation helpful? Give feedback.
-
|
Plus Bitwarden is a superior product to 1Password. That being said, 1Password probably generates a lot more revenue, which is a compelling argument for whomever owns the Warp IP. |
Beta Was this translation helpful? Give feedback.
-
|
Our business model is that we are free for everyone for now and will eventually experiment with different premium features for enterprise. Our model will NOT involve collecting or selling any data. The general philosophy is that we would never charge for anything a terminal currently does. So no paywalls around ssh or anything like that.The types of features we could eventually charge for are things that have a cost to us, like for example keeping an infinite searchable command history, or enabling real-time terminal collaboration. Even those though would probably be free to some level of usage and only charged in a company context. |
Beta Was this translation helpful? Give feedback.
-
|
Thats an interesting statement. But tbh, that sounds nice but I have some difficulty putting the trust in it that it probably deserves. Without being able to recall a specific example from memory, my brain tells me: "you have read that many times already, but folks ended up in traditional market-logic-thinking and uninspiring (though somewhat proven) business models (e.g. selling results of a secret receipe)". Also, (especially at VC-funded?) companies people come and go over the course of time. |
Beta Was this translation helpful? Give feedback.
-
|
I wouldn't mind getting only open-source licensed crates and leave branding crates entirely closed sourced. Open Source as a business model should have the right to earn money, IMO. |
Beta Was this translation helpful? Give feedback.
-
|
I'm curious if a GNU GPL 3.0 license would be a good fit in this case as it grants users an open and free usage/modifications but does not allow redistribution under different license which essentially will prevent companies making money from it. This is the most popular license in the general free open-source world so you don't have to reinvent the |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that's what I was thinking about the copyleft licence already do exists |
Beta Was this translation helpful? Give feedback.
-
|
The GNU GPL covers the Linux kernel, and one of the problems they specifically want to avoid (according to above) is fracturing:
|
Beta Was this translation helpful? Give feedback.
-
It is not the kernel fracturing, it is the distro. Each distro does not have constant environment, they use different version of libraries, and even use different system path. The kernel makes least problems, for most of the time, you can use the mainline kernel to replace the distro one and you should be fine. |
Beta Was this translation helpful? Give feedback.
-
|
This is not as much of a problem as it seems. There are universal packaging formats and even though there are a lot of distros, most people do not have that much of a hard time using it how they want. I understand the concerns for OP, however, to gain trust from privacy enthusiasts and general users, the client side should definitely be open source, and also forking should be allowed just not under the warp name possibly. This protects users against forced telemetry, which they cannot change to distribute. |
Beta Was this translation helpful? Give feedback.
-
|
GPL would be awesome for this project. Nearly maxmimum freedom is achieved with the GPL. I respect this suggestion. |
Beta Was this translation helpful? Give feedback.
-
|
I find this issue highly interesting. Are there any updates on this? I myself struggle with the same issue and, while grateful for OSS and wanting to give back, still need to make sure the business venture itself is successful. Because otherwise... well, I'd just lose lots of time that I'd otherwise have—to work on what I love. In the end, everyone needs to make a living somehow. |
Beta Was this translation helpful? Give feedback.
-
|
The technology in Warp looks impressive, but I can't imagine adopting infrastructure as fundamental as a terminal without it being Open Source. Not just "source available", actually Open Source. It would be like adopting a proprietary compiler, or a proprietary programming language: no matter what interesting features it might have, it's too dangerous to rely on and build upon (to the extent you even can build upon it). "Source available" licenses that aren't Open Source don't actually solve that problem. Feeling like you can rely on critical infrastructure includes the ability to patch downstream, or make security fixes, or adapt to different needs, or try large-scale experiments, or keep a project alive if discontinued or taken in a different direction upstream. Sometimes it's important to be able to innovate in ways that the original project didn't think of and didn't approve of (or didn't approve of initially). In practice, large Open Source projects rarely have forks; new forks that become successful often make the news, which makes them seem more prominent. I also want to note that you have more choices of license than just permissive licensing. The Rust community tends to primarily use and encourage permissive licensing ( Also, keeping the server proprietary and having a business model involving paid collaborative features seems completely reasonable. For any kind of hosted service, I want to be able to pay for it, so that I'm confident it'll stick around and be healthy, and never need to be tempted by alternate revenue streams such as ads and selling user data (which tend to go hand in hand). In any case, thank you for innovating in an area that has traditionally not gotten the benefit of substantial innovation! |
Beta Was this translation helpful? Give feedback.
-
|
Just a random thought: what if there was a "self-destruct clause". So that legally, as a company, warp is required to fully open source the terminal if they ever go out of business? |
Beta Was this translation helpful? Give feedback.
-
|
I was excited when I found warp. However, I was very disappointed the moment when it requires an account to function. It is reasonable to require an account for any paid service, but require an account to just use a terminal does not sound right to me. What if the service is gone? Can we just have a branch dedicated as an OSS project and remove some advanced features that you think should be paid, so that we can use it without sign an EULA for the service? |
Beta Was this translation helpful? Give feedback.
-
|
Terminals should work offline as well as online - this is an important issue. |
Beta Was this translation helpful? Give feedback.
-
|
I do not understand why you would release the source code after a certain number of installs; is this implying that open sourcing the project will slow new installs somehow? I feel like this does not make much sense. Of course, maybe it is just because you want to build the groundwork before others have the opportunity to use your codebase to make alternate projects, however, most people are likely to still use the main project if you implement features they desire, and respect their privacy. There are countless examples of this, and there is not an issue regarding open sourcing unless you break promises or create issues in development. I hope you take some of this into consideration, thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah the idea would be to hit a "critical mass" before open sourcing. The open source world, as much as I love and am a part of it, is fraught with broken standards. Just take a look at bash, zsh, dash, fish, etc. We can't just edit the .bashrc, there's another edgecases for every variant. And we already have this problem with terminals and trying to do something like detect color support, or character encoding support. It's very haphazard. Waiting for a certain number of installs would help establish a de-facto standard. And on top of a standard being helpful, it also makes it much easier for the founders (and others) to monetize services, like a settings-sync or intelligent autocomplete or whatever. |
Beta Was this translation helpful? Give feedback.
-
|
I feel like you are expecting too much. Developers have higher standards regarding privacy and expectations, and not being able to contribute fixes to issues and not having guarantees of privacy would stop a lot of people from switching. Your idea of "critical mass" has no real reason, as I doubt open sourcing would stifle support, it would be the opposite. |
Beta Was this translation helpful? Give feedback.
-
|
The obvious choice is to simply have a very restrictive license, such that you give users the ability to see client-side code of the shell, fork it, develop plugins, help out, and do what they wish (so long as they do not compete). That eliminates fear from big business eating you alive, gives users the safety they need. Waiting for critical mass, as you say, is a really bad decision. You will stifle your growth with bad publicity and less adopters. Personally speaking, I would never touch the shell until it's FOSS. You're expecting 10,000,000 (ridiculous number even if arbitrary, btw) developers to disrespect their potential security and privacy, or be naive... Probably not the best bet to make against developers anywho. |
Beta Was this translation helpful? Give feedback.
-
|
yeah I can confirm I've downloaded it and had a play and it looks great but I won't be switching until its FOSS. I kind of assumed it was until I looked in github and couldnt find the code. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is a smart way to go. Either a license that keeps code open but restricts competition, or a license like AGPL which means any code reused has to be in an open project as well. This is up to their discretion. |
Beta Was this translation helpful? Give feedback.
-
The licence you are suggesting is not FOSS. |
Beta Was this translation helpful? Give feedback.
-
|
open source and offer a linux version, if you really want this to fly. business model comes later IMO |
Beta Was this translation helpful? Give feedback.
-
|
I agree about open source and the linux version, but they are smart to give it some thought before rushing into it. |
Beta Was this translation helpful? Give feedback.
-
|
business model comes later? is this before or after they file for bankruptcy? |
Beta Was this translation helpful? Give feedback.
-
|
Before open sourcing everything... which can't be put back into the bottle. |
Beta Was this translation helpful? Give feedback.
-
|
After. They will file for bankruptcy first, and then they can worry about the business model |
Beta Was this translation helpful? Give feedback.
-
|
A custom license should work, stating WRAP needs and business model. Also adding something like even if the project is redistributed it shouldn't be commercialized will be a cherry on top of the cake. This would make sure that, some random big company out there don't fork and make money out of it. I'm looking forward for the license! P.S building a SaaS product, kinda in the same situation |
Beta Was this translation helpful? Give feedback.
-
|
Use AGPL so everyone must keep the code open. |
Beta Was this translation helpful? Give feedback.
-
|
Several other commercial open-source projects have written articles explaining their choice of license. A common concern is "Getting eaten by a big company that copies and steamrolls the original project". I've compiled a list of them here.
|
Beta Was this translation helpful? Give feedback.
-
|
Check this LICENSE as well: https://polyformproject.org/licenses/noncommercial/1.0.0/ |
Beta Was this translation helpful? Give feedback.
-
|
As a newcomer, I think it's almost impossible to trust a 3rd party terminal client if it's not open source. Especially one that makes you log in for whatever reason. No offense I liked the product, but we wrote soo many private things in our terminals
I can understand that you spend an enormous amount of effort to make this thing and you should be compensated, I wouldn't care about closed source generally if this wasn't a terminal. But for a terminal client, being open source is sort of the number 1 requirement for many people like me. |
Beta Was this translation helpful? Give feedback.
-
|
I mean I don't really like notion of defending a statement by showing more of the bad examples. There are people who get away with closed source privacy sensitive projects. So ? Is this supposed to make me go 'oh if they are doing it too, well I guess you're right. Here, get my API keys, the person I don't know'? I think talking about operating systems are also not very helpful. Because you really can't trust bigger companies either. But what are you going to do about it ? (Btw apple's core os stuff is actually open source, same for linux.) I think it's about what is available to you as a tool and how many people you want to give your data to. Good luck doing work without an OS in 2022. But you can very well use another terminal that have no additional privacy issues except from those you agree when booting to the OS. And it comes pre installed on your machine. |
Beta Was this translation helpful? Give feedback.
-
Not sure where you saw a "defense." Like I said I agree with you. My point is that no one cares about our opinion. We need to find other arguments aside from "I refuse to use it because it's closed source."
You're acting like there are no open source operating systems. I use an open source operating system and I have a great experience. I don't do it only to be open source. I use linux because I think it's superior to any of the alternatives. I also exclusively use open source terminals and password managers. Nearly all the software I install on my computer is open source. There are plenty of open source options for people like you and me. You're not going to have a lot of luck convincing closed source projects to go open source with the argument that users like us won't use their software. We are a tiny portion of their user base, so they don't care. Most people are just going to use whatever app they enjoy using the most regardless of it being open source. Companies pursue profit, arguing about the preferences of people who will never pay under any circumstances is moot. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah but this term is atm only on mac isn't it ? But I think you're right about not convincing. I think when stuff like this happens we should put our money to where our mouths are and try to make an open source version of these stuff we like about these projects while paying respect and attention to both the organization and the law. I don't think the right path is accepting. Or creating justifications in terms of user counts. Privacy shouldn't be a negotiation or can not wait until an arbitrary "critical mass". |
Beta Was this translation helpful? Give feedback.
-
|
For instance : https://github.com/erdemu/zsh-codex |
Beta Was this translation helpful? Give feedback.
-
I'm absolutely in favor of this. It can be tricky to amass the necessary man hours to deliver a quality product without some financial incentives. There are a ton of open source terminals, and it might be easiest to add some of the killer warp features into an existing codebase that already has several active contributors, instead of building something from the ground up. On the other hand there are some very unique things about warp so I would expect substantial rework and design challenges. I don't have any experience with desktop gui apps so my knowledge is pretty limited here. Anyway to answer this question I'd probably look into a modern, performant, cross-platform terminal that doesn't rely on electron and is actively maintained, and see if the codebase has room for some of these features to be thrown on top. Wezterm is the first one to come to mind but I'm sure there are plenty of other candidates. |
Beta Was this translation helpful? Give feedback.
-
|
It's so silly what they are trying to sell us. A closed source terminal lol. It's basically a rootkit. No way it'll ever be permitted in our company. If it was GPL and auditable then that would be fine but a closed source terminal is an automatic no. Imagine running Linux and putting proprietary terminal on it. You've completely ruined your security architecture. I'd feel so dumb if that terminal got exploited with some silly bug because nobody could audit it, fix it etc. It's a flop. |
Beta Was this translation helpful? Give feedback.
-
|
Warp will be open sourced. Why, you may ask? Simple. or I could be wrong; either way, I won’t touch this until I can at least build the binary from source 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Check out Wave Terminal. Someone pointed this out to me last week, it's essentially the FOSS of warp. |
Beta Was this translation helpful? Give feedback.
-
And I'm out. The Command Line is such a precious little tool, with such a high-stakes environment and utility that I cannot trust any closed source solution, no matter how awesome it is. In a way, the Command Line is a last line of defense that helps us know deeply what's happening inside a computer (and subsequently, our code). If there's no transparency from my CLI, I cannot use it in good conscience whatsoever. It's the core reason for many to be on Linux on the first place (or even macOS to a high degree, to be honest...since it's running UNIX underneath and the Darwin components are open sourced). It's also why almost every widely used devtool is open sourced, at the very minimum it ensures that the tool can have continued development if the original company/devs go under. I'd have completely understood if the AI part of Warp had to be closed source, but at the very minimum the Terminal Emulator part of it should be open sourced. As I have mentioned earlier in this thread, the GPLv3 would have been ideal, but really any Open Source license would have done. However, I'd like to agree to disagree on the notion of a closed source Terminal Emulator. It's been a good ride, but I will be sadly uninstalling Warp. Based on the responses from Warp VC's (or lack thereof), it's probably safe to assume that this would not be open sourced anytime soon. Peace ✌️ |
Beta Was this translation helpful? Give feedback.
-
|
I guess Warp developed this terminal for their internal use :D Cause no one will use it unless they open source it |
Beta Was this translation helpful? Give feedback.
-
|
I'we come here from the ad in the Bat README, and can say something: Seems like Warp guys do NOT want to publish their garbage as Warp is a HUGE terminal application with a LOT of features which looks like eye Warp got ported to [GNU/]Linux. DO NOT INSTALL IT, THIS IS A NON-FREE TRAP! This is a scream of my soul. If we continue to disregard the degree of freedom of Free Software or death!(deleting Bat for advertising the non-free) I am migrating from Gith*b to Codeberg! Check it out. UPD 02.03.2024: fuck, W*rp ad are now on the Neovim site... I should find some alternative... Also, I deleted lsd just in case, because it is written in R*st |
Beta Was this translation helpful? Give feedback.
-
|
I think the problem is that some people automatically think everything made in Rust is the best. |
Beta Was this translation helpful? Give feedback.
-
|
That's the other extreme, and both are absurd. Try it and use it if you like it, is my point. Don't use something worse because it's written in rust, but don't use something worse because it's not, either. The original comment was also just so hateful in its language, which doesn't belong in the OSS community. |
Beta Was this translation helpful? Give feedback.
-
literally any sane compiled language is fast
memory safety costs performance, in optimized builds it is disabled as i know
i never seen e.g. GNU ls segfaulting.
from my point of view, they are not good. the rust community most times tries to reinvent the wheel in a VERY bloated way, trying to make one util do a lot of similar things (e.g. LSD is just subset of GNU ls with icons + tree). the only good tool is ripgrep, because it does one thing (searching matches in text files), and does it pretty damn well.
useless. we already have GNU ls and tree, why yet another tool?
i get used to it when searching some string in big amounts of text data. actually good
i don't use spotify, in any wraps and kinds like this
tried, this thing renders font and my colors incorrectly
useless; want to highlight your code anyway for a laugh, we have an tool for that:
useless;
i already setted up my zplug-based zsh config, don't bother to test it out
maybe i will use it out, but not now |
Beta Was this translation helpful? Give feedback.
-
|
Check out vis. I stand with you in protesting. |
Beta Was this translation helpful? Give feedback.
-
|
Also check out |
Beta Was this translation helpful? Give feedback.
-
|
I wish I could continue using WARP in all the developer content I make, but won't if it doesn't come with the ethos of Open Source. Uninstalling, there are plenty of ways to keep core open source while optimising for business. You just lost me and many other customers, Enjoy with the VCs. |
Beta Was this translation helpful? Give feedback.
-
|
As much as I like this command block-based approach, I dislike login/cloud walls. |
Beta Was this translation helpful? Give feedback.
-
|
This literally is a necessity for us to use it. |
Beta Was this translation helpful? Give feedback.
-
|
I like the UX a lot, but as many people said, the security is a too big concern. |
Beta Was this translation helpful? Give feedback.
-
|
There is no way a terminal application that is closed-source and has mandatory authentication is ever going to be massively adopted. As people pointed out, there are many other ways for businesses to keep core open source while optimising for business and profit (look at github sponsors for example) I really hope you guys figure this out and make a radical change for the good here. (hopefully it's not too late cause many people have lost their trust) I'm sure that if the status quo stays the same, a solution that does the same thing but it open source will come to be and then it's game over. Make the right call :) |
Beta Was this translation helpful? Give feedback.
-
|
That look like they want to open source, but actually they don't. While consumers still consume (pay) this shit, that will definitely stay proprietary. They will not go to the good. Abandon this pile of rusty code. |
Beta Was this translation helpful? Give feedback.
-
|
Wait what I need to login to use my terminal???? |
Beta Was this translation helpful? Give feedback.
-
|
that's the least problem |
Beta Was this translation helpful? Give feedback.
-
|
From the point of view of a software engineer and open source enthusiast, I would like to participate in the project as a contributor. Unfortunately it is a closed source project.. :( |
Beta Was this translation helpful? Give feedback.
-
|
Check out waveterm! |
Beta Was this translation helpful? Give feedback.
-
|
@jeff-hykin That is great. Can't wait for a Windows release. |
Beta Was this translation helpful? Give feedback.
-
|
I am deeply saddened by the effort that is being wasted on this project. Look at waveterm as a better alternative. Beware people to stay away from the malware that Warp term is. The developers do not have your best intrest at heart. This is proprietary garbage that should be avaided. |
Beta Was this translation helpful? Give feedback.
-
|
Open sourcing this project under the GPL would be like Jesus wiping away its sin. I hope the developers have a change of heart, and realize how much it would mean to set project free, and break the chains of proprietary restrictiveness. |
Beta Was this translation helpful? Give feedback.
-
|
I just stumbled upon this project, was interested but I'll pass. The terminal emulator part should be open source. |
Beta Was this translation helpful? Give feedback.
and others
-
(Edit: 2 years later)
(Edit-Edit: if you care about open source, checkout waveterm)
TLDR/FYI: Despite the initial responses, I don't think the Warp owners (VC's) have any interest in removing the login requirement or making the source available in any form. I'd be happy to be wrong, but over the years that's what the writing-on-the-wall seems to say (even if some of the Warp devs feel differently).
Here's the original post:
Describe the solution you'd like?
Additional context
I'd like to kick off the conversation by saying I'm not opposed to non-open source software, I appreciate benefits like
However, as a end user, I don't want a core part of my workflow to be fully controlled by a single source. For example:
There are different possible solutions, the two that come to mind for me are:
Having well-defined legally-binding clause for when the code will become available. For example: "once we reach a __ ROI per member, we will release the code under XYZ license" or "once we have 10,000,000 installs according to app store metrics, we will release the code", etc
Having source-available code by uploading it with a very restrictive license. That way enthusiast/hobbyist coders can compile, patch, verify, and tinker but forks, redistribution, and resale are prevented.
I've just seen too many projects that go sideways, and I don't want the rug pulled out from under me after I learn to depend on something as essential as a terminal.
Beta Was this translation helpful? Give feedback.
All reactions