Open sourcing Warp and business model #400
Replies: 52 comments 82 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.
-
How about doing delayed open source instead? For example, CockroachDB uses licensing model where the code can immediately be used for non-production work but production environment requires commercial license unless you're willing to wait for 4 years (for whatever definition of non-production work you want for your own project): https://github.com/cockroachdb/cockroach/blob/84bfbdbdef8c20ed90288841f7b846be682487f9/licenses/BSL.txt#L20 Every release automatically falls back to defined license (e.g. MIT, Apache 2.0 or GPL) after 4 years of the initial release. Or sooner if the copyright holder wants to convert the software into real open source sooner. And of course, you can define the rules for the initial 4 years exactly as you please. You could even define that for the initial 4 years, redistribution of any modified version is strictly disallowed. That would still allow us to compile our own copies from the publicly viewable source code and make private modifications instead of trusting random binary files but the whole project would still be under your sole decisions. And if you cannot get your project to hit the critical mass in 4 years, maybe you're never going to hit it. But if the source code were made visible (if not open source in meaning that you can also distribute modified versions) that would take away one major hinderance for the project to ever hit critical mass. For example, I'm following this project but until I can see the source code, there's no way I'm going to run this as my shell with real data. If you need my participation for critical mass, you are never going to hit the critical mass without showing the source code first. And the important point is that there will be automatic release into real open source with a predefined date, however long into the future it might be. That allows me to put resources right now to make my own modifications because I can trust that my own work will not be wasted because it will be possible to distribute my changes to other people after waiting the full delay time. If you instead promise to release the source code one day, it might happen after I've already been dead a long time because "one day" may be a really long time into the future in practice. |
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.
-
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.
-
|
Has the team considered something like the FSL-1.1-Apache-2.0 license? It gives a fairly restrictive license that switches to an Apache-2.0 license after 2 years. For an example, Sentry uses this license. Someone could fork the Sentry code from 2 years ago and it would have the Apache-2.0 license. It definitely doesn't fix all the concerns listed, I just thought it might be helpful to know. Thanks for making a cool terminal! |
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.
-
|
man every dev is so disappointed in you guys. might as well remove any part on github |
Beta Was this translation helpful? Give feedback.
-
|
I will not type my passwords in a closed-source software. |
Beta Was this translation helpful? Give feedback.
-
|
Trust is necessary for a Terminal app. It is the main entry point for developers and devs have to write passwords and secrets in the terminal. Though it added a "Network log console", that is not a solution, because not everyone will always check it, and one day intentionally or unintentionally any feature introduced that sends all commands to the server, will be a nightmare. The owners should rethink how to provide trust or make it open-source with some other business model. Not all companies will allow developers to use closed-source terminals for their official work. It is well known. |
Beta Was this translation helpful? Give feedback.
-
|
Even though the project seems really interesting after a few tests, I'll wait for a decision regarding the license before considering replacing my usual terminal. |
Beta Was this translation helpful? Give feedback.
-
|
First and foremost you have created an absolutely awesome product. I've been having many ideas around features and you have brought a interesting product to market. BTW not just terminal this things everything app really. I dont understand how you expect to compete in the market place being closed source. "thats why you have to bullshit everyone about the open source dream". Common seriously vscode ?? I mean no disrespect, you may well make millions good luck to you. There are alot of competitors coming to market ALOT. You appear to have the "desire" to be a contributing part of our free and open source communities. PROVE IT ! At the moment your are not even competing in the real market the community are taking you at your word that you will be open sourcing the code. If you need a server component have one, FSF aren't going to be happy but they rarely are. Honestly i wish you nothing but success. |
Beta Was this translation helpful? Give feedback.
-
The LGPL and AGPL were created exactly for this issue: you want to have your product GPL Open Source but need a proprietary service or component. Even then the AGPL/LGPL guarantees that your product will not be "steamrolled" in that case. The FSF would prefer for you to use GPL, but understand the current realities of the tech dev landscape, and have create appropriate licenses to grant the freedom and security of GPL while being able to make parts of it proprietary. They (Warp) haven't even shown commitment there. And the worst part is that this idea of a better terminal is not too out of the ordinary. It's not unique enough that it grants them a patent, and projects like Waveterm are doing equally as good (perhaps better) while being GPL'd and available to the masses. However, what is crucial is that the Terminal is your gateway to ensuring complete access to any and every process on your computer. Who in their right mind would then support a proprietary tool, ever?? |
Beta Was this translation helpful? Give feedback.
-
|
Really sad the status quo hasn't changed after so much time. It's not viable to use a closed source terminal. Good luck with the VCs, a closed source terminal is something neither me nor anyone I know would ever pay for. It's just insane from a security perspective, and if you can't convince your investors of that, you really need to re-evaluate your communication skills. Guess waveterm it is. |
Beta Was this translation helpful? Give feedback.
-
|
I have seen a new concept named "Fair Source". This may be a balanced solution.
from https://fair.io/ |
Beta Was this translation helpful? Give feedback.
-
|
It is proprietary. When someone wants to diverge they can't compete which is UNfair. They should keep the server private but a libre client. Then it would stay Warp-exclusive. |
Beta Was this translation helpful? Give feedback.
-
|
Let me make a clarification. The key point is delayed open source publication. It means that anyone can always fork from previous open sourced version. Of course it may lack some latest features, and this is how it provides a competitive advantage for Warp. As for providing latest code, it is only a measure to prove its privacy and promote community development. Keeping server private means that Warp may not be usable once the Warp company goes out of business, which is too risky. |
Beta Was this translation helpful? Give feedback.
-
|
The serves provides AI features and stuff, that should be private. The client should be really FOSS. |
Beta Was this translation helpful? Give feedback.
-
|
They plan to make money with AI features and collaboration, right? Then they can just free the client but keep the server providing them private. So they won't lose money. |
Beta Was this translation helpful? Give feedback.
-
Waveterm is nothing like Warp. Doco site is completely broken, 157 open issues and bugs, can't connect to remote servers using the built in "Connect To..." feature (on my Mac), no workflows (the main feature I want!), no notebooks (another killer feature I want), no highlighting of previous commands etc. I don't need a built in web browser, directory lister + image and markdown viewer - that's what my OS is for. As much as I'd love Warp to be open source, Waveterm is not even close as a replacement, at least for me. |
Beta Was this translation helpful? Give feedback.
and others
-
Edit (after 3 years of waiting)
TLDR: Warp will likely never be source-available or open source. (But waveterm is open source and really similar)
Summary: Despite the initial responses below, 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