DEV of the #OMN projects

Emissary.dev presents itself as a promising low-code platform that might potentially expedite prototyping for the #ActivityPub based #OMN projects. It’s emphasis on ease of use and integration with various #openweb social APIs which is the path we need to take for rapid development without getting bogged down in initial complexities.​

Potential benefits, rapid prototyping, the low-code approach allows for quick iterations and testing of ideas, which is crucial in the early stages of project development.​ Open source foundation, providing the flexibility to modify and adapt the codebase as needed. This openness also means that, if necessary, a custom backend could be developed in the future without starting from scratch.​ The is some developer engagement, Ben the dev, appears to be actively engaged with the community, responding to issues on #GitHub and expressing a desire to support #openweb paths.​

Things to consider are the monetization plans with a freemium model in the future. While this is not uncommon, it’s important to consider how this might affect the project’s long term independence and sustainability.​ Then there is the background of the developer, which includes work in the self-help industry. While this isn’t inherently negative, it’s worth considering how this experience might influence the platform’s direction and priorities.​ All this questions the codebase long-term viability for “native” #openweb use, as relying on a third-party platform always carries some risk. We do need to assess whether Emissary.dev’s development trajectory aligns with the long-term goals of the #OMN project.

Next steps are technical evaluation, a review of the codebase to assess its quality, security practices, and suitability for the project’s needs.​ Will reaching out to Ben for a video discussion to better understand his vision for the platform and how it might align with the #OMN project’s paths.​ Pilot testing, if initial assessments are positive, proceed with a small-scale pilot to test capabilities in a soft roll-out environment.​

Looking for feedback on this.

We also look at Ibis Wiki

UPDATE: the code I’ve read so far at least looks well-organised, and it’s fairly clear to read through and glean intent. Looks promising.

Is Mastodon a #4opens project

The #4opens are a simple way to judge the value of an “alt/grassroots” tech project.

Open data – is the basic part of a project https://en.wikipedia.org/wiki/Open_data without this open they cannot work.

You can get your data out with RSS and AP and vie user export, so TICK

Open source – as in “free software” https://en.wikipedia.org/wiki/Free_software this keeps development healthy by increasing interconnectedness and bringing in serendipity. The Open licences are the “lock” that keep the first two in place, what we have isn’t perfect, but they do expand the area of “trust” that a project needs to work, creative commons is a start here.

It has a #FOSS licence TICK

Open “industrial” standards – this is a little understood but core open, it’s what the open internet and WWW are built from. Here is an outline https://en.wikipedia.org/wiki/Open_standard

Here it’s problematic, it supports atom/RSS good, but is AP support is pushing broken HALF TICK

Open process – this is the most “nebulous” part, examples of the work flow would be wikis and activity streams. Projects are built on linking trust networks, so open process is the “glue” that binds the links together. https://en.wikipedia.org/wiki/Process

It uses #github a #dotcons platform, which kinda has open process but is in meany ways unresponsive to this #openprocess HALF TICK

Solidarity

It’s easy to become a #4opens project and join the #openweb family. Just show that your project fulfils 2 or more of the above “opens”.

2 opens - Bronze badge
3 opens - Silver badge
4 opens - Gold badge

This makes 3 opens, so Mastodon is a silver #4opens project, to become gold it needs to improve its standards competence and/or work at better open process.