Comments

• steverugi

  May 9

  this is a so much needed post, almost a wake-up call
  thank you @YassineO
  I reiterate my proposal to use Categories in this discussion portal (maybe with a search syntax to catch particular keyword combination)
  like a "start here", " how-to", or specific discipline-oriented topics

  • Any roadmap for supported projects ?

  is for me number one to address

  
• theoryshaw

  May 9 edited May 9

  I think what’s emerging across these types of discussions is a fairly simple but important observation: OSArch doesn’t really suffer from a lack of ideas or contributions — it suffers from fragmented coordination and unclear legitimacy or agency around who can actually move things forward when it matters.

  In other words: people need to feel empowered to make bounded decisions on behalf of the ecosystem without constantly wondering whether they are overstepping, whether consensus is sufficient, or whether someone else actually “owns” the responsibility.

  In fewer words: people need to know it’s okay to “just do it”.

  I think the underlying problem isn’t governance in the abstract, but decision latency. Things like funding workflows, infrastructure decisions, roadmap direction, standards coordination (for example BBIM/OSArch property sets like OSA_Array), and even communication cadence tend to remain in a state of ongoing discussion without a clear point where discussion converts into execution. The result is not inactivity — it’s diffusion.

  I think this is where a lightweight, continuously active coordination layer (as hinted here and here) is worth exploring — not as a hierarchical authority, but as a mechanism that empowers trusted individuals to pull the trigger when shared infrastructure, funding, or timing requires a decision. The key requirement is not permanence or centralization, but legitimized agency that comes from actual participation.

  And I think the uncomfortable but honest reality is that any such system will drift unless it is continuously corrected. So rather than trying to design a perfect governance structure upfront, it may be more useful to treat this as a correctable system, not a fixed one — something that evolves with participation rather than trying to freeze authority into static roles. We are hackers, at the end of the day.

  To make this concrete, one possible direction is to experiment with a participation-based legitimacy signal — not as a final arbiter of authority, but as a transparent coordination index that helps identify who is actively contributing across OSArch’s ecosystem (forum, GitHub/Bonsai/IfcOpenShell, wiki, Matrix, Open Collective, etc.).

  A minimal “seed” version of this could look like:

  def legitimized_agency():
      raw = {
          "forum": score_forum(),
          "github": score_github(),
          "wiki": score_wiki(),
          "matrix": score_matrix(),
          "funding": score_open_collective(),
      }
  
      weights = {
          "forum": 0.2,
          "github": 0.3,
          "wiki": 0.1,
          "matrix": 0.2,
          "funding": 0.2,
      }
  
      return sum(weights[k] * normalize(raw[k]) for k in raw)
  

  At this stage, it’s not about precision — it’s about making participation visible across fragmented systems. Over time, this could evolve into something more meaningful, like a “community confidence index” or contribution graph that reflects not just activity, but sustained, trusted engagement. And it could even become useful to other communities facing similar coordination challenges.

  Importantly, this system would not replace judgment or automate authority. It would function as a shared visibility layer that reduces the friction of identifying who is actively engaged in stewardship at any given moment, so coordination does not have to constantly rediscover legitimacy from scratch.

  In practice, that could mean: those who consistently demonstrate sustained participation across these systems become eligible to exercise decision-making authority, without requiring constant re-validation or formal nomination cycles. Not as a fixed hierarchy, but as a living trust layer that reflects current reality rather than historical status.

  Crucially, this also aligns with how open source already works in practice: contributors don’t ask permission to change the code — they act within a shared system where permission is already encoded structurally through access, contribution history, review processes, and community trust. The same principle could extend beyond code: trusted participation becomes the mechanism through which decision-making authority is implicitly granted, rather than explicitly requested each time.

  I think the key design constraint here is that the system only needs to be correctable, not perfect. If it is transparent, adjustable, and openly discussed, then errors are not failures — they are inputs into the next iteration. That shifts governance from something brittle and institutional into something closer to open-source development: observable, patchable, and continuously improved.

  I think this also connects directly to concerns already being raised: onboarding gaps, roadmap clarity, infrastructure coordination, PR backlog, communication cadence, and confusion between OSArch and supported projects like Bonsai and IfcOpenShell. These are not separate problems — they are symptoms of the same coordination gap.

  So the proposal, in its simplest form, is this:

  • introduce a lightweight, visible participation-based legitimacy signal
  • allow that signal to surface currently active stewards
  • enable those stewards to make bounded decisions on behalf of shared infrastructure, funding, and coordination as part of normal ecosystem maintenance, with decision-making authority being implicitly granted through sustained participation — similar to open source development, where action does not require prior permission because the system already encodes that legitimacy structurally
  • treat the system as continuously correctable rather than fixed

  Finally, I think the real test of any model here is simple:

  can ideas move from discussion into execution without waiting indefinitely for consensus?

  If yes, governance is working. If no, then we are just describing ideas without giving them a path to exist.

  And I think that’s ultimately what we are trying to solve here.

  
• YassineO

  May 10

  I like the idea measuring pas contributions, but only for curiosity and to see who is helping and how and to congratulate them ! ( I am honestly lost as to all the new members /nicknames, and its becoming hard to know everyone when you disappear for a time period).

  Some people are still watching, reading, learning and are hoping to help in some way... but can be shy/confused as to how to help.

  Whilst we formalise things with the commitee: I believe we just need a coordinator. A bridge between supported projects ( the technical part) - the community. Not about decision making but about coordination of efforts. I feel like you, @theoryshaw or @steverugi could help coordinate contributions from the community as you are the most informed person around here. Let's try and do it together?

  
• YassineO

  May 10

  @Moult @aothms , about "Roadmaps" for ifcopenshell projects.
  Would be lovely if we could write two types roadmaps:

  • High level, non technical ( IfcOpenShell project roadmap)
  • detailed, technical roadmap for each IfcOpenShell sub-project ( 1 for Core, 1 for Bonsai, 1 for IfcViewer etc.)

  We could put the high level roadmap in the repository's root Readme.md , then the others in each src/project/readme.md. Little to do list. No deadlines, no pressure.

  
• steverugi

  May 10

  @YassineO I'm flattered :)

  I have no idea as to how this could be practically managed (also my coding skills are limited) but surely count me in, ready for the ride

  cheers
• theoryshaw

  May 10

  I think my hesitation around a traditional “top-down roadmap” model is that it can accidentally invert the natural strength of open source communities.

  Most successful open source ecosystems don’t advance because a central body perfectly predicts the future and assigns work downward. They advance because many contributors independently scratch different itches, experiment, prototype, and push ideas into existence from the edges. The roadmap often emerges after momentum already exists, not before.

  So if a roadmap becomes too centralized or prescriptive, a few risks appear:

  • it can unintentionally discourage experimentation outside the officially prioritized path
  • contributors may feel like they need approval before acting
  • governance shifts from enabling action to gatekeeping action
  • energy becomes concentrated around maintaining alignment rather than building things
  • and the roadmap can slowly drift away from actual contributor motivation, which is the real fuel source of open source development

  I think this is especially important in OSArch because the ecosystem is unusually diverse: architects, coders, BIM managers, researchers, fabricators, educators, standards people, and companies are all approaching the space from different angles with different incentives. A single unified roadmap may create the appearance of clarity while actually flattening that diversity.

  That’s why I’m more interested in something like an “aggregated focus” model rather than a fixed roadmap. Instead of leadership dictating direction from the top, the system continuously observes:

  • where contributors are already investing effort
  • what users are repeatedly requesting
  • where funding is flowing
  • which issues and PRs are accumulating attention
  • which experiments are gaining traction

  Then coordination emerges from those signals.

  But I also think an important extension of this idea is that stewardship itself should remain fluid, in the same way open source contribution is fluid.

  One of the healthiest aspects of open source development is that people move toward the areas where they currently have energy, curiosity, expertise, or urgency. Someone may steward documentation for six months, then disappear into rendering work, IFC schema issues, or funding coordination. Another person may suddenly emerge and become the primary organizer around onboarding, standards, or infrastructure simply because they care enough to consistently show up.

  The legitimacy comes less from appointment and more from sustained visible participation.

  So I think the governance analogue here is not:

  “who permanently owns this responsibility?”

  but rather:

  “who currently has enough trust, participation, and momentum to responsibly carry this forward?”

  That changes the role from office holding into something more like active stewardship.

  In practice, this means historically central contributors should not feel obligated to permanently curate “aggregated focus” coordination simply because they have historically carried the ecosystem. They should be free to rotate in and out of stewardship roles depending on interest, bandwidth, or ecosystem needs.

  Likewise, newer or less historically central contributors should be able to step into curating onboarding, documentation, roadmap synthesis, standards coordination, or communication efforts without needing ceremonial permission first, provided the participation and trust signals are already there.

  That’s the deeper point behind “legitimized agency”:

  • participation grants confidence
  • visibility grants trust
  • and the system structurally normalizes action

  In that sense, the coordination layer starts behaving much more like Git itself:

  • nobody owns the ecosystem absolutely
  • contributors self-select into areas
  • trust accumulates through visible work
  • maintainership emerges organically
  • and stewardship can rotate without institutional crisis

  I think that rotational quality is essential. Otherwise governance becomes brittle because too much identity and responsibility become attached to a fixed set of people. A living ecosystem needs the ability for contributors to naturally drift toward and away from stewardship roles over time without the coordination structure collapsing whenever someone burns out or disappears.

  So instead of thinking about this as forming a permanent steering committee, it may be healthier to think about it as creating a continuously updating stewardship layer that reflects where active trust, participation, and momentum currently exist.

  
• theoryshaw

  May 10

  At the end of the day, since we are human, we already have a fairly well-honed intuition for who has legitimized agency in a given space — but it’s informal, contextual, and somewhat “mushy”.

  I think the opportunity here is not to replace that intuition, but to make it more visible and shared through a correctable, participation-based signal of engagement across the ecosystem.

  The goal isn’t to compute authority, but to reduce ambiguity around it — so that those already acting as “aggregated leaders” can do so with more confidence to just do it, without second-guessing whether they are overstepping or whether permission is implicitly missing.

  Importantly, this won’t — and shouldn’t — be perfectly accurate. But that’s fine, because the system we’re describing is explicitly a human agency system: it is meant to be messy, observable, and continuously correctable rather than rigid or definitive.

  The point is simply to make existing patterns of trust and participation more legible, so coordination doesn’t constantly have to reconstruct legitimacy from scratch.

  
• theoryshaw

  May 10 edited May 10

  Since we all love hacking: https://hub.openingdesign.com/OSArch/Agency
  I hosted it here because i would still like to realize this idea, which i believe has political buy-in, from that discussion.
• Nigel

  May 10

  I have followed this discussion with interest.
  The website osarch.org states, OSArch is for the architects, engineers, designers, builders, planners, operators, and you.
  Let's change the industry together.
  Is this still the purpose? If so there are some critical disciplines missing.
  Before creating an organisational structure I would like to consider who is being served by this project now and in the future, what they want and need and why they want these things?
  This will feel very un-FOSS but these people (including us) are customers, money is not being exchanged for an app or an addon, instead the customer is exchanging their time, commitment and trust. Hopefully they are so pleased with their 'purchase' that they choose to donate :)
  This is where I would start this discussion, at the end and work back.

  
• steverugi

  May 11 edited May 11

  @theoryshaw
  Thanks for your input, with which I tend to agree — as far as I was able to understand. :)
  My proposal for having a roadmap is far from being a strict or top-down diktat enforced by an elite, even if made up of the most prolific or active members of this community.
  It was more a modest attempt to look at the product(s) as they are today and try to figure out where we could realistically take them in the short to mid term.
  Basic points like:

  Short-term goals (<12 months)

  • Reliable full-cycle architectural authoring (walls, slabs, windows, spaces, etc.) with decent performance on medium-sized models. (Bonsai)
  • Efficient drawing production (plans, sections, elevations) so users can generate their deliverables as smoothly as possible. (Bonsai)
  • Basic coordination & clash detection usable on a day-to-day basis. (Bonsai/Viewer/Web)
  • Solid quantities & scheduling export. (Bonsai/Viewer/Web)
  • Easy guide for new users to produce their first valid IFC model in < 2 hours. (Wiki/OSArch.org/YouTube/GitHub)
  • Extensive federation mode (Viewer/Web) for multi-project analysis.

  Mid-term goals (12 to 36 months)

  • Getting closer to replacing Revit’s features, such as MEP and structural output.
  • Infraworks BIM tool for longitudinal infrastructure projects.
  • Becoming a general-purpose CAD/BIM platform beyond the architectural domain.
  • Real-time collaboration tools.
  • full 4D/5D implementation (time-cost)

  The above is not a wishlist but a guidline to define an approximate skeleton of what we could realistically all be willing to aim for within those timeframes.
  Happy to see other inputs on the matter.

  Cheers

  
• theoryshaw

  May 12 edited May 12

  @steverugi I'm basically trying to find a way where ideas can move from discussion into execution without waiting indefinitely for consensus — as we've all seen happen in conversations like this one. :)

  Specifically, I want a system where @YassineO can run with the ideas he listed above. A system where you can seed and aggregate roadmaps, and where others can push back or add as necessary.

  All the 'usual suspects' in this community know intuitively that you both have high 'legitimized agency' — but acting on it is hard because it's not codified anywhere. This system tries to make that explicit, so members can 'cash in on it', so to speak, without feeling they're overstepping or waiting for a consensus that never quite arrives.

  It also includes a proposal and voting layer, so ideas like @YassineO's above have a clear path from "raised in the forum" to "decided and acted on" — not just tracked, but resolved.

  And honestly — I don't think you'd get any major objections from the core community (myself included) on what's proposed above. So how do we give core members more confidence to just do it, and give others a reason to show up and participate more? Nothing is more motivating than being given agency to realize your idea. That's why we love open source — in its purest sense, it touches that nerve exactly. Would be nice to capture that ethos in how we move together as a community.

  We're not going to get it right straight away — but it's going to be fun to refine it over time. And we're not the only community with this problem.
• steverugi

  May 12

  @theoryshaw
  OK, since we all are more or less on the same page let's go

  just one more thing..
  @Moult "O Brother, Where Art Thou?" ;)
• Moult

  May 30

  The actions I'm interpreting from this are:

  • Create a roadmap, of which I think https://community.osarch.org/discussion/3386/addressing-some-core-ifcopenshell-issues is the best I can do right now
  • OSArch new webpage, of which step 1 is to complete the static migration which will happen today, and step 2 I think is to get more regular news. I'll make a start on backdating news, but it would be awesome if there was someone "in charge" of news. In the past, there was a lot of difficulty in news because it took time to write and research. Now, I think it's sufficient if we "lower" our standards to merely a paragraph per "news", that way we could do it more frequently and we don't need to worry about polish. There is so much happening every day in the FOSS space now (a lot due to AI) it's insane, and there is really no place better positioned to capture it than us. Anybody want to take this role? The only requirement is some Git familiarity (easy to learn) and keeping up on social networks on what's happening. Think of it as a more formal "repost".
  • Organise OSarch online Monthly Meetups, this would be great to resume. Might a start with pitching the idea of @falken10vdl talking about the awesome work he's doing on BonsaiPR? Also maybe @yorik and the changes happening in FreeCAD.
  • Post and engage on social media - I forget who owns our socials right now. Does anybody know?

  
• paullee

  May 31 edited May 31

  @Moult said:
  - Organise OSarch online Monthly Meetups, this would be great to resume. Might a start with pitching the idea of @falken10vdl talking about the awesome work he's doing on BonsaiPR? Also maybe @yorik and the changes happening in FreeCAD.

  Not only FreeCAD, Yorik is working on LinesCAD also :D
  Announcing LinesCAD