This blog is intended to give some clarity on short and medium term areas of prioritisation of neume development. It is a guide based on the author (Dan Fowler) ’s best view at this time. Development may take different paths depending on the wants and needs of the neume community.

Summary

The goal of neume should be that it can hit “escape velocity”, defined as:

• Financial independence from one single party
• Multi-party requirements informing the development roadmap
• Compounding growth of developers and users of neume

All three of the above criteria strongly relate towards pushing onwards from the incubation that HIFI Labs has generously provided to neume over the past year.

Successful transition to escape velocity will see self-perpetuating growth of the project, building on the social scalability foundations that we have already laid.

Financial independence

To date, neume has been solely financially supported by HIFI Labs. The next stage of neume will be built upon more varied funding.

To this end, despite great progress over the past couple of years in the development of DAO methodology and infrastructure (e.g. Nouns Builder), I personally don’t think that this is the right model for neume at this time.

While there is clearly a lot of cross-over between DAOs and Open Source projects, my view is that a project like neume shouldn’t be “owned” by any distinct parties, and funding through some form of token creates divergent incentives. The values and social contract that we started neume under; social scalability, credible neutrality, open infrastructure; require the project to be “unowned”, permissionless, and free (as in libre).

It would probably be the easiest route to spin up some kind of token, but the medium term implications are severe if motivation turns to token value, which is ultimately inevitable.

So, if we discount tokens as an option, then we can focus on the following routes towards financial independence…

1. Grants

Grants from independent bodies (such as gitcoin) or aligned projects are a likely source for some funding that neume should pursue. They can provide supplementary funding free of restrictions.

However, there are challenges with the grants approach, especially those applied for via an independent programme. There is usually significant front-loaded effort, writing bids and cutting through the noise of other applications. Funding can often be delayed, and require matched finance.

For these reasons, I think that the optimal approach for neume in the short to medium term is to engage with larger projects in the music & blockchain and web3 open source development communities, and seek support.

2. Donations

Similar to grants, though even more unrestricted, donations are a viable option for supplementing neume’s financial independence, albeit unlikely to provide the foundation for funding compared to other routes.

3. Project development contribution

Not specifically a route towards financial independence, but a very important accelerant towards escape velocity and beyond for neume will come through development contribution provided by affiliated projects.

The purpose of open infrastructure and composability is to alleviate the need for parallel development within organisations, a core issue in traditional industries. And thus, our aim at neume should be for it to be attractive for projects to develop within it, rather than in parallel to it.

4. Not-for-profit service company built alongside neume

A more adventurous, but ultimately sustainable, route towards financial independence for neume will be to start a service company alongside neume that funds the project out of revenue that it generates.

Examples of services that could be built: platform integrations, NFT database caching and provision, rights and authority database, NFT accuracy insurance, etc.

In a well functioning ecosystem, a not-for-profit service company run by neume would be in competition with other companies for the services that it provides, and ultimately the majority of which would become commoditised into the network over the time.

And thus, this funding route can essentially be seen as building a business around elements that are not yet ready to be ingested and open-sourced by the protocol, and then continuously developing the product line as previous elements are commoditised.

Multi-party development requirements

neume’s development roadmap to date has been solely driven by HIFI Lab’s requirements for musicOS.

This has been extremely useful to focus our prioritisation while establishing the project over the first year, but reaching escape velocity requires a more varied set of use cases and needs to form the network into something that is useful and used by the entire ecosystem.

Development requirements will come from two key sources - projects that are building music NFT distribution platforms, and projects that are building music NFT experiences.

neume’s priority to date has been to focus on the few, largest, music NFT distribution platforms, Sound and Catalog (and Mint Songs, and Noizd), which provided the highest value for development effort while establishing the architecture. Moving forwards, we are looking towards the Lens and Decent ecosystems as the potential next additions, as well as “custom contracts”, for example those released through factory contracts from Zora and Manifold.

However, I am aware that this prioritisation remains driven by myself, and HIFI Labs, and may not in fact reflect the needs of the ecosystem at large.

Bringing projects on to neume will not be an overnight victory, and should be seen as a constant endeavour, though it is hoped that there will at some point be a break point where it becomes the de facto infrastructure to build on, and ship to. We should do everything that we can to make neume this.

Compounding user and developer growth

A product of the previous escape velocity conditions, but likely the most important of all. neume will be successful once projects (users) and developers using and shipping to it are growing at a steady and then increasing rate.

There are probably reward mechanisms that we can build to encourage this behaviour, however, as with the comment above about tokens, I am personally cautious of disguising genuine active users for those more financially minded.

This area is something that we should develop going forwards. As it stands, we have github commits and open office attendance as measurable indicators, but we should think about more comprehensive metrics to understand how active the project is becoming.

Managing neume

A final section to discuss, though not directly a condition of escape velocity, is the management of neume the project itself.

As thing stand I am somewhat the default director of proceedings, but as the above elements grow we may need to think about more democratic approaches.

With that said, my personal approach to governance is of simplicity, only where requirement, and subtraction rather than addition. One of my frustrations with recent developments within DAOs has been the over-complication of decision making (usually to justify a “governance token”).

For now, I would propose that we continue management of the project as it is, but remain alert to where we may need to alter things due to there being friction or deviation from our values.

A specific element that is worth highlighting though, in context especially to the funding options above, is that some will likely require the establishment of a treasury, and the accompanying legal and financial requirements that come with that.

For this, I suggest that we would likely want to establish a “neume LLC” (or equivalent), which could then be the vehicle for the “not-for-profit services company” detailed above.

Dan