Planning the next major version about oso HOT 14 OPEN

It would be good to see some commitment to the oss project, via activity and engagement with the community, re responses on issue and PRs. As an example publicly defining the roadmap, perhaps via comments on this or which issues are to be included, instead of feedback links to private forms (aka removing discussion). As is the project appears unhealthy based on activity, and as an adopter of it i'm now wondering about alternatives.

from oso.

Bumping this. We're actively working on the next major release and would like to share the initial plan and collect feedback. If you're interested in participating, please drop me a line (my first name at osohq dot com)

from oso.

I think Slack is a difficult place to focus the team on if you want to get larger corporations and users from larger corporations involved. Many companies restrict or block access to websites like Slack, Dropbox, etc., whether for security or other reasons. I think it's important not to make GitHub-only users second class by focusing primarily on Slack, which I would expect will drive a slightly different user base.

I think taking more of the approach that groups like Python's special interest groups (SIGs) take, which is to use a mix of GitHub and forums/mailing lists, Slack is fine also, etc. is for broad coordination with monthly or quarterly calls where involved or interested users can all jump on Zoom, WebEx, BlueJeans, etc. and coordinate directly, as many of those services are not restricted by large enterprises. These calls should have a clear agenda so that they don't end up going off-topic if the group is large enough.

Personally, the focus on Slack has been a driving factor as to why I have not been able to be more involved with this project

from oso.

Hey @kapilt! Thanks for the input.

We agree -- the goal of this outreach is to gather input for a public roadmap. We prefer to discuss live so we can get into full details on how people are/want to use Oso. But for folks who would rather comment, they can do that when the roadmap is up.

On the commitment front, that's also the goal of having a public roadmap. We'll share what we plan to work on. Additionally, we have some larger internal changes that we plan to make, with the goal of being able to tackle some of the gnarliest bugs/performance issues that we've seen.

from oso.

Seconding @samscott89's comments.

@kapilt Thats a great call. Can I put you down for, "i want to get involved?"

Let me provide some additional (hopefully) clarifying context. I wasn't at Oso when the library was originally built and released so I'm trying to catch up. Checking out the issues and PR's here is great, but I'd really like to identify some passionate users and work with them more closely to turn that list of n number of issues and PR's into a focused and themed list. What I'm aiming for is community involvement, leveling up my understanding of the issues and doing those things efficiently.

Question: We have both github and the community slack where users are working with us. It's not clear that everyone wants github to be the place where they interact with us about the open source project. Do you have advice about how to create connective tissue between github and slack communities to bring them together?

from oso.

Hey all, thanks for all your work on Oso! I filled out the form but wanted to follow up with a post here as well for visibility.

Another want to have is feature parity for the Rust language support.

Parroting the above, I think this is very important, as well.

I was also wondering how feasible it would be to add support for the Oso instance to be able to manage some state/context in the Rust SDK? To be clear, I am aware of but not referencing the current context/context facts, although I can't seem to find it availabe in Rust, but I am moreso thinking of the ability to manage a database connection pool, etc. This would allow for a more seamless integration for policies defining relations between resources without running into existential assertion issues, which as it stands seems to be a pain point #1705.

I would envision something like:

policy.polar

resource Organization {
  roles = ["owner", "member"]
}

resource Repository {
  relations = { organization: Organization }
  roles = ["owner", "member"]

  "owner" if "owner" on "organization"
  "member" if "member" on "organization"

  # Etc
}

# This is the bit that would be possible with the state/context, naming/usage of oso.state here not overly important
has_relation(organization: Organization, "organization", repo: Repository) if
  repo.organization(oso.state) = organization

main.rs

#[derive(Clone)]
struct MyState {
  db: Arc<Database>,
  // etc
}

let mut oso = Oso::new()
  // State/Context should impl Clone + Send + Sync
  .with_state(MyState { ... });

...

impl Repository {
    pub async fn organization(&self, state: MyState) -> Result<Organization> {
        state.db.do_the_thing().await
    }
}

from oso.

Hey any update on this? I am particularly interested in the test syntax used in oso cloud. It seems the parsing logic for it is completely missing on the polar-core. Would be nice to have. Another want to have is feature parity for the Rust language support. A sea-orm based data filtering logic would be really nice to have. If that is not an option than a Trait for data-filters on the rust language support would be awesome.

Another nice to have would be a BNF grammar. This is currently a blocker for #609 for Jetbrains based ides. Further logic should be easy to implement via https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-developers/. Since there is already a language server used by the vscode plugin.

from oso.

Hey @dvtkrlbs, we're working on this as we speak! Thanks for sharing the bits that would be particularly useful to you. If you're interested, I'll mark you down as a candidate to look at the first alpha when it's ready. Sound good?

from oso.

Sounds good

from oso.