Building Nivenly: A letter from Quintessence
(For those who would like to read A Deeper Dive into Haidra, please click here.)
Hello everyone! My name is Quintessence and I’m the Executive Director of the Nivenly Foundation. I wanted to take the opportunity to talk to you, myself, as the Executive Director.
Let’s talk
As you may know, we recently announced Haidra and the Federation Safety Enhancement Project as the two newest projects to the Foundation. Haidra in particular has inspired a lot of feedback, some for Haidra itself and some for Nivenly. For Nivenly, I had a realization that helped me connect why some of our initial communication hasn’t gone the way that I hoped and have some ideas for how to build toward a better future.
I definitely made a mistake in how I communicated. Not only for Haidra’s announcement but also for some of the queued up posts we have that will do deeper dives into Nivenly. I had, without realizing, assumed that many of you either joining the co-op, or evaluating if you would like to, were doing so with some assumptions about what co-ops are and aren’t, and that mostly you “just” needed information about “our type of co-op”. This makes me wonder, what are some better ways for me to handle this?
By happenstance, I had some truly superb feedback from how to fix this and start producing the communications that are needed. The feedback came from one of the calls I scheduled with someone who, as I found out on the call, has been deeply involved with tech unions for some time. In our conversation I learned that unions face similar problems as well - they are in a position where people maybe kind of do, and kind of don’t, have a pre-existing understanding of what unions are and aren’t. This also means that it usually falls on the union to have some pretty great communication so they can help their new members understand “what the holy fuck is going on”.
Not only was it an exciting chance for me to learn about unions, as “I kind of do, and kind of don’t, understand unions” definitely applies to me, as a result of the “mock onboarding” conversation I have started to understand some of what you might need as you’re navigating “what the heck is Nivenly” and “what even is a co-op in the tech industry”. I don’t have any quick and fast solutions, but I am going to start changing what and how we send our outbound communications to be more informative for all of you. I will be asking for your help as well, as Nivenly cannot run only on one person, or even a small group of people, it can only run on a collaborating cooperative.
To start to address this, let me talk a bit about Nivenly itself.
What is Nivenly?
The best way to describe Nivenly is a non-profit co-op that is focused on providing governance and support to open source projects. We want to be a safe place for communities to have agency in their work and their projects. Which means we need help from our communities. There isn’t an elite group sitting at the top, just a small set of volunteers who need help running the show.
But what does this mean, for you? How do you, the member community, help “provide governance and support to open source projects”? How does Nivenly?
The short version is that you provide you and Nivenly provides resources and support. The resources and support include the governance process, a code of conduct, a contributor license and easy way to sign it, as well as resources like GitHub and additional tools. The longer version involves understanding Nivenly’s primary goal and how that applies to you as a member.
Goal: Supporting our communities
While myself and the board have put a lot of labor into building the governance model, working with legal support to have it translated into bylaws, and talking with others to ensure we’ve captured what needs to be in the plain text and legalese, it actually isn’t the end goal for Nivenly Members to engage with governance all that often.
Wait, what?
I know. We put a lot of work into something I just told you isn’t the goal, and that probably feels really counterintuitive. It’s true though! The reason we put so much time into it is because governance is a safeguard measure and an important one at that.
You see, the long term goal of Nivenly is for Nivenly Members, of all member types, to feel they are empowered and have agency to be the change they want to see. We believe in decentralization where projects own their own destinies. This can either be via direct contributions to a project or discussions with other members of any member type (general member, project member, or trade member).
There will be times when members are able to agree. Maybe there is a universally loved project or maybe there’s an easy common ground to a specific topic or decision.
There will also be times when members do not agree. Maybe there is a project that is controversial, or a discussion that is becoming contentious. How do we work together, when we feel like we cannot work together? One answer is to have an agreed upon fallback mechanism to allow us to still come together and be able to accept the outcome of that process and keep moving forward. That fallback is governance. This means that:
The goal of Nivenly is to provide a place for communities to work together on community built technology (open source).
and
The goal of governance is for there be an agreed upon mechanism to reach agreement and consensus to make decisions together when we disagree. (After all, why engage in a process when we agree?)
Lightweight Collaboration
As we build Nivenly together, the goal is for the Foundation to support members to get what they need done. To help inspire some thoughts about what this might mean, let me provide an example.
Let’s say that a member saw an open source project was working with art in technology, but perhaps not with artists. Let’s say further that they felt really strongly that there is a gap in lived experience and expertise between artists and technologists and that they felt that gap could be bridged by knowledge sharing between the groups. A member of Nivenly can, either individually or with the help of the cooperative (including other members as well as myself and the board), facilitate a discussion between a panel of artists and the Nivenly community. The result of the panel would likely be an improved ability to include more considerations when building projects, and not just the project that inspired the original request. In Nivenly’s model, no one would need to request permission “from Nivenly” to do this. Instead, they would only need to ask for what support they needed and let everyone know about the cool panel they’re organizing so people will attend.
What I am mainly trying to communicate with this example, is how this might differ from a more corporate model. In a more corporate model, you likely need to Ask Permission before doing things. You would need to ask an agent of the company before introducing guests, and you would need to request permission for outcomes, and so forth. In the cooperative model, you work with the cooperative to (for the most part) Just Do.
Another way this differs from the more corporate models is who has agency in building toward the desired result. In a more corporate model consumers, customers, and so forth would need to vault feedback, Letters to the CEO style, over a metaphorical fence to inspire change in the company or organization. The key thing here is that as a customer, consumer, or even employee that you are outside the decision making ecosystem of that organization. So you are trying to inspire them to do differently as an outsider.
We are designing our cooperative model to enable people to have as little overhead as possible. That means that we want members to feel empowered to build together, both their own ideas and each others, with as little overhead as possible.
As a very young organization, we’re still working together as we build and change the ways that help us work together the best. The ultimate goal is to find a sustainable way to work together that facilitates creative exchanges with as little bureaucratic overhead as possible.
What does Nivenly look for in projects
When the board and myself look at a new prospective project, we have a few top concerns:
- Can we work together with the maintainer or maintainers of this project?
- How does this project break the mold? How is it different from the norm? Why does THIS project need our help the most.
- The details of the project: what it is, is it open source, what legal concerns does it introduce, etc.
Our topmost concern might feel counterintuitive, in the same way that reading we went heads down to build a robust governance model that isn’t the end goal might have felt counterintuitive. Just like then, there is a reason why we consider how collaborative the project is first.
We want to work with projects that have maintainers who are collaborative because collaboratively minded people want to work with others. This means that whether we accept a project that is universally loved or that inspires heated debate, the end result is still collaboration.
Essentially, a collaborative maintainer of a contentious project will listen to concerns, invite criticism, and do their best to merge the project goals with community concerns and needs. A non-collaborative maintainer of a contentious project is not open to views outside their own and will not welcome the free exchange of ideas that we hope to build here.
Beyond these top concerns, we look at the project itself. We have a lightweight template that we ask maintainers to use when applying to Nivenly. (The GitHub version of the template is located here.) The prompts ask for answers around:
- A description of the project and what is needed from Nivenly
- Project scope - what problems or concepts the maintainer(s) are hoping to solve
- Intended use - how the maintainers intend the project to be used
- Anticipated misuse - how the maintainers anticipate the project may be misused
- Countermeasures - how maintainers protect against misuse
- Accessibility to the project - this can be both accessibility as a contributor and accessibility as an end user, the question is intentionally broad to fit as many projects as possible.
We adjust our expectations around the depth of the responses to each of our questions depending on a few factors, including project age and complexity. To put it another way, a very complex project that is very young might not have all the details thought out, but is striving to get there. On the opposite side, a longstanding project that is much less complex might not have deep answers to each question due to the simplicity of the project.
Let’s take a look at how this process applies to Haidra.
Haidra’s application process
db0, Haidra’s lead maintainer, was connected with us on social media (Mastodon) when he mentioned he was struggling with a rapidly growing project. After a quick discussion where we asked a few clarifying questions about his project and he asked a few clarifying questions about Nivenly, we mutually decided to proceed with the formal application process.
Haidra was our first project that we were going to accept via an application process, as both Aurae and Hachyderm were already projects when Nivenly was created. Haidra’s maintainer was very happy to work with us while we requested an initial application via Google Docs and requested a few small follow ups with additional questions for clarification for the application itself. The culmination of all of this was a singular Google Doc that had all of our initial questions answered in one place and the template that we have in place for future applications. We decided at this stage that we wanted to have the application itself live in a transparent place, so we added AI Horde’s application (and our general application template) to our project GitHub repository.
As part of the decision making process, db0, myself, and the board had several asynchronous conversations to cover more Q&A about the project, it’s goals, and make sure we had a solid understanding of what the project is, was trying to grow into, and what was needed for Nivenly.
I mentioned earlier that we adjust our expectations depending on a few factors such as age and complexity of the project. Haidra is no exception. In Haidra’s case, Haidra is a very young, complex, and rapidly growing project. (For reference, Haidra has yet to have its “first birthday” and has already hit 150k subscribers.)
Haidra also started as db0’s passion project. The initial mental model he had for building the project accommodated a much smaller audience and much smaller growth, and one of the main reasons he was interested in talking to an organization like ours is because his project had rapidly grown past his ability to consider everything he needed to consider, and implement everything he needed to implement. To put it another way: scale breaks almost everything. When Haidra grew rapidly, he suddenly found that decisions had more implications than his design had accommodated and had grown beyond the scale he anticipated. By a lot.
Even though AI Horde and Haidra were growing far, far faster than db0 had anticipated, he had done a lot of work to try and prevent misuse. What I am specifically referencing here are content moderation, worker opt-in, and the kudos model. For content moderation, Haidra is constantly working to make sure that images generated do not contain harmful content like CSAM. This is actually one of the earliest misuse mitigations that db0 had put in place for Haidra out of the gate.
Haidra’s opt-in model for workers we also felt was crucial. The project was young enough that while it might not have project-level opinions it wanted to enforce, it did allow individuals to do so. (Note that project-level opinions can, and frequently do, differ from maintainer(s) opinions.) The way Haidra implements this is by allowing people who were willing to add their computer as a worker to be explicit in what they wanted to opt-in to. This was specifically done to allow individuals to accommodate how they were reconciling their own ethics with how they did, or did not, want to participate in the project.
Lastly, a little bit about Haidra’s kudos model. As some have pointed out, this is somewhat similar to a “karma” model. Essentially, good work is rewarded via kudos. Workers with more kudos have their work prioritized, so that they can continue to do good work. The result is that those who are engaging in bad faith, but not to enough of a degree that they are moderated out completely, are disincentivized.
We, myself and board, acknowledge that none of these three solutions is complete. For a project this young, we primarily evaluated:
- Tangible work done toward a stated goal, i.e. steps accomplished toward a stated goal, instead of only stated a goal.
- Ability to collaborate
For a developing project, it is our opinion that works in progress are opportunities for collaboration. They can only be opportunities for collaboration if the core / lead maintainer is looking to collaborate, and he is. For a project that is in a contentious or divisive space, we view the potential for collaboration to be even greater: while it might not be true in a more corporate model, in a cooperative model people have the opportunity to share thoughts and opinions that can influence the trajectory that a project and/or technology is taking.
For these primary reasons, the Haidra project was accepted by the Nivenly board of directors.
(For deeper details on the above, please see Haidra’s blog post.)
So What’s Next?
I realize that was a lot. As we grow, our communication will start to be smaller and more iterative rather than deep and long. I look forward to working toward that stage with you all. I have a few requests of the community to help us get there together.
Actively seeking a common onboarding project
Something I discussed on the call with the union organizer: the lack of a onboarding project. The goal of the onboarding project would be to:
- Provide a common experience for all/most members who are interested in contributing to projects
- Provide a place that helps build knowledge and awareness to the contributor process and feedback loops
The call to the community is the onboarding project itself: we’re actively looking for either a project that can meet these needs or to create a mock project that meets these needs. For anyone that can help with this, either with a project in mind or building one, please either email us or start a Discussion on GitHub.
Actively seeking support for a newsletter
Something that some of our members have expressed interest in is a newsletter to help members be more engaged and have the information they need. What we need help with is for a small group interested in curating the newsletter itself. We have the information to provide and need help getting it into the hands of our members at a better pace. For anyone interested in this, please either email us or start a Discussion on GitHub.
Actively seeking support to test tools to support member activity
Although we are very excited that our governance model was ready for our main launch, there is a lot more work to be done. Tooling rollout is no exception. In our earliest communications (as in back around March) we tried to set the expectation that at launch there will be a certain amount of “building the airplane while it’s in flight”. This is where we’re at today.
The disparate needs of FSEP and Haidra have provided us with a wonderful opportunity to find tools that meet more needs, better. It showed the strengths and weaknesses of the feedback loops we have in place today: GitHub, Discord, and email. As we mentioned in the FSEP announcement we’re evaluating tools for where its Discussions can be hosted that doesn’t constrain on GitHub, as well as how to handle a Live Q&A. The request for a member newsletter also introduces a potential for a tool.
We need a group of interested members that are interested in being added to tools before they are announced as a formal feedback loop so we can do more “pre-launch” testing instead of testing at the launch itself. The most valuable information we find is generally surfaced when we can observe what the tools can and cannot do based on how participants actually try to use it (rather than relying on its advertised feature set alone, which is of course also helpful but not predictive). Same as before, for anyone interested in this, please either email us or start a Discussion on GitHub.
How we’ll handle the tool roll outs
Something I wanted to call out explicitly. Since we’re working through what tools do, and do not, work very rapidly as part of these first project announcements we will likely do a few shifts to a new tool when we discover that a current tool has a critical limitation. (e.g. a lack of a voting mechanism) We appreciate everyone’s patience while we work hard together to get this part done right, and we will definitely strive to keep these changes to a minimum. When we do start to “sunset” using a particular feedback loop, we will not close the feedback loop without warning. I mention this in particular around GitHub, as it was a great place to quickly capture all the initial interest, discussion, and criticism around Haidra and AI, but isn’t sustainable in the longer term. As we make new changes we will make sure to communicate where people can send us their feedback and participate in discussions, while also being explicit about the timeline for moving away from an incumbent tool.
How we’ll handle project announcements going forward
As I watch and compare the discussions around Haidra and FSEP, something that I feel we can do with future project announcements is to include a statement from the new maintainer where they introduce themselves, take the opportunity to outline why they’re joining Nivenly and what they explicitly hope to learn from the Nivenly community, as well as do a deeper dive into their project. I’m curious if members feel this would help with the initial introduction to a new project, as well as help them feel more empowered to ask questions and participate in discussions. What are your thoughts?
Thank you!
I want to thank everyone for working with us as we go through our launch. I also wanted to extend an extra thank you to everyone who took the time to write us their long form criticisms, sincerely. We are a new organization and Haidra is a new project. I recognize how much time and care went into those posts. It takes someone truly hoping to change things for the better to put that level of nuance and attention to trying to change things for the better, especially before there is even an established history where you can trust that your thoughts are even being read or considered. We have read them, and we hope to build that trust by continuing to actively follow through on the questions and concerns raised as we build Nivenly together. Thank you.