All-Hands-AI
Update bug_template.yml to show app.all-hands.dev
End-user friendly description of the problem this fixes or functionality that this introduces
- [ ] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below
Now people are starting to use app.all-hands.dev as a way to use OpenHands, we should probably add it to the bug template!
To run this PR locally, use the following command:
docker run -it --rm -p 3000:3000 -v /var/run/docker.sock:/var/run/docker.sock --add-host host.docker.internal:host-gateway -e SANDBOX_RUNTIME_CONTAINER_IMAGE=ghcr.io/all-hands-ai/runtime:0903da3-nikolaik --name openhands-app-0903da3 ghcr.io/all-hands-ai/runtime:0903da3
These make sense!
Just to clarify though, the online site will be running the open source software, so open source contributors will certainly be able to fix issues that appear when people run things there. And the two apps will largely be at feature parity, so it's not like the online site is extremely exclusive or anything. I don't know if that helps?
In terms of user support in billing, I assume that we will have something separate for that, but we're not that far yet.
As one idea, maybe we could put this later in the list instead of first?
Yeah it's a tough call. If you all made the decision to add this, I would add the new option last so it doesn't show up as the default for now.
Just a detail on this:
Just to clarify though, the online site will be running the open source software, so open source contributors will certainly be able to fix issues that appear when people run things there.
Of course, I'm sure the first is mostly the case. I'm not equally sure that the latter follows.
Not very relevant perhaps, but slightly related: a couple of nights ago I had to get out of bed to go try to repro an issue I was seeing on the site. Because amanape asked me to report it, and I realized I didn't know how to report it, I hadn't seen it before so I wasn't sure whether it is on the project or only on the site. I couldn't quite repro locally so I posted it for the site.(So I settled for the idea that there might be something site-specific, which may well not be accurate.)
An issue you cannot repro locally usually means a number of things. If it was seen on the site, however, it can mean a number of other things, specially when related to sessions, to auth, to user setup, to workspace setup, to permissions. 🤷
Surely, the agent is the same agent, but the agent errors might or might not be, I don't know, it depends. And people don't usually report good behavior. 😅
Thank you for taking the time for this discussion. I only found out about this intention a couple days ago, and I honestly didn't get to grapple with the consequences. I do think it's non-trivial.
Thanks @enyst , I see where you're coming from, and I also understand as well. Debugging on the hosted version is more opaque for me as well because I'm not really able to dig through the logs.
Just as a thought experiment, what are the options that we have here:
- Status quo: We keep the form the same. If so, every time I choose "installation method" I need to pick "docker" or "dev workflow", but neither of these apply when I'm using it on the site.
- Current proposed solution
- Some other solution such as having an entirely different workflow for reporting issues for site users? This seems a bit sub-optimal, because that would fragment knowledge about potential issues, and many or even most of the issues on the site stem from something in the oss repo.
I realize that there's no perfect solution here, but I still would lean towards "2." It seems easier logistically and a good way to keep things as open as possible and share knowledge with the whole community. But on the other hand, I do understand that you (and likely others) may be frustrated by seeing some bugs that are not stemming from the open source.
And yes, thanks from my side for the discussion too! As always, OpenHands is a community effort, and I want to make sure we end up with something that everyone is happy with!
Well said. Option 2 seems to make a lot of sense for simple, pragmatical reasons.
I may be dense, I admit I initially assumed that the hosted app support is, or will be, part of a separate project set up for "all-hands.dev" website (option 3).
Let me take your thought experiment and go deeper into option 2: same place. If the site is here, what does it bring with it and where are the limits? They are shifting.
- You say that the issues will be mostly with
oh, and I see why that is likely. But I hear on slack that AH has an NDA for people to sign. I have no idea what is that about. Where are users under NDA going to post about their issues?
Are we looking to see here posts like "there was also a lot of red error text but I don't know if I'm allowed to talk about it here because NDA"?
This is a pragmatical question as well as a values question. On the pragmatical side, I don't see how that would work in a public repo.
On the other side. "Open source but you're not allowed to speak" would seem to be the new normal. I do question whether that is a value this project should have and what consequences it will have on it.
The more I think about it, the more option 2 makes sense. But it implies, shall we say, a tighter integration between this project and the site. From the project side, that is.
So, speaking of the site, I noticed a funny thing or two. Unlike the above, they're not exactly pragmatical issues with option 2, but they are little interesting tidbits and worth bringing up IMO.
- The ToS for the website/service is public. Frankly most seems to be boring legalese, but there's a rather amusing detail.
The following are examples of kinds of content and/or uses that are illegal or prohibited...[AH reserves the right to...] including reporting the violator to law enforcement authorities.
Then a bunch of bad things follow. Really bad. Law enforcement authorities bad. Then among them:
engage in or use any data mining, robots, scraping, or similar data gathering or extraction methods.
About this...
We are an AI open source project; we work with LLMs day in day out; and internet datasets; we have an agent grabbing axtrees and we may do in-context learning on up-to-date software library documentation, to name just a few. 😂
Data mining and web scraping public data are legal. And well, essential. (Private data is different, because it's private data, not because of data mining or scraping.)
Does AH want to prevent people from scraping its website? Well OK, it's its website, surely the AH team can monitor and try to stop it if so it wants, this paragraph is IMO unnecessary. Idk though, we may have forgotten to tell our agents. 😅
As a policy matter, I believe AH is mistaken to add this on its website.
(IMO, you're helping interests that would like nothing more than to make startups like this pay through their teeth for the crime of fine-tuning llama or browsing the internet archive. That's just my honest opinion.)
What is your position on this?
Last, and least.
- The same ToS (it's disputable if anyone reads or cares about these things, and whether it'd be worth your time and resources to even think of enforcing, but well, words have meaning)
Competitors: No employee, independent contractor, agent, or affiliate of any competing open source software development company is permitted to view, access, or use any portion of the Service without express written permission
A curious little detail... why single out "open source software development company", and not all competitors if so, is that a typo?
In the early days, "Devin" from "Cognition AI" apparently submitted a PR. I remember that when I brought it out in our slack, everyone was amused and excited. Is something like that becoming frown upon? Sorry, it was fun.
We also have a lot of issues posted in this repo, afaik roadmap-worthy, that describe or even include screenshots from devin. This... seems a little ironic.
On the other hand, please correct me if wrong, I think AH is not trying to enforce this. Then why say it? Legal stuff has the habit to become part of the shared understanding in a community. I believe people internalize it as shared values. Just like licenses. Just like it's meaningful that the license is MIT, a "live and let live" license.
Hi @enyst , thanks for sending! I just want to acknowledge that I saw this and will take a closer look but it might take a few days. CC @rbren for visibility too. Terms of service are obviously important but they need to reflect our values, so I'll take a close look at what we have now and circle back!
@enyst thanks for the discussion here!
Re: terms of service--to be honest, we asked our legal team to draft something, and pretty much accepted what they gave us wholesale, because we were heads down coding 🙃 I should have taken a closer look. Thank you for digging through it--I will bring up each of your points with the legal team and see where we can and should push back. I agree with pretty much everything you said.
Re: the bug template--my main concern is that people are going to come here to report issues with app.all-hands.dev, whether we guide them to or not. I definitely don't want e.g. billing questions here, but I do think we need some kind of outlet for the folks who naturally come here after using the website.
Maybe we can have an "other" option, which would cover SaaS, on-prem, and any other non-standard environments?
Thanks @rbren, 100% agree on revisiting the terms and thank you to @enyst for pointing this out (I didn't think as deeply about them as I should've either).
For the time being, I added "app.all-hands.dev" as one option but at the bottom of the list, and also added "Other" for other setups too. Let me re-request review, but I'm also happy to continue the discussion!
Thanks a lot! And let's continue the discussion, these sorts of things are super important to discuss and get right, so in the future I'll try to run things by you whenever there are similar decisions to be made.