Attracting more contributors


#1

One of the “wall of shame” items that came out of the Principles discussions was a lack of non-salaried contributors. For an open source project we have an over-reliance on core contributors and thus we have need to attract more contributors in general. The focus of this post is on Technically-skilled contributors (i.e engineers) but also applies to other types of contribution.

There are some assumptions below, so bear with me. When it comes to potential to contribute to Status, I think there are roughly 3 categories of people:

  1. Crypto/blockchain enthusiasts: the super-early adopters to the sector that already exist, and largely have already heard of Status. These people work/play/live in the space. They are intrinsically motivated to contribute to Status through either alignment with our principles AND/OR passion around the technology.

  2. Mis-aligned Tech workers: General Tech workers that share our values/principles - specifically privacy and security. They probably work full-time for a for a Tech company, are interested in crypto/blockchain but haven’t made the leap because there’s a big risk to them leaving their well-paid, comfortable day job. However, they’re misaligned with the privacy/security principles held by their employer and find themselves increasingly disenchanted with the direction being taken. Examples of this: the internal backlash coming from sub-groups of Google, Facebook and other big Tech companies over privacy issues.

  3. "Regular" tech folks that have a particular passion for our values (security/privacy) but haven’t yet explored the blockchain space. These people probably work for smaller tech companies, in the security/privacy space and are very ideologically aligned with what we’re doing, even if they don’t have explicit knowledge of the space.


I think there’s an opportunity to attract contributors from #2 right now - these are folks that are employed & well paid but potentially unfulfilled. We can offer them the opportunity to help build something better, something that provides rather than extracts value from users. They may only have evenings and weekends to help, but I think it we can reach them there’s an opportunity to attract them to contribute. NOTE: I’m not talking about traditional recruiting, or bounties. I’m talking about attracting OSS contributors.

How do we attract them?
IMO, we have the right message and mission - these people and will be intrinsically motivated to contribute to Status, if we can reach them.

How do we reach them?
We could engage with disgruntled groups of “big tech” employees and offer them an alternative way. This could be achieved by attending/sponsoring non-crypto events focused on privacy/security, by reaching out to those groups when they voice public complaints about the direction of their current employers. You could also take a more hands-on approach: we could take banners/fliers directly outside their offices, with taglines like “Want to build a better web that focuses on the privacy of users? Contribute to Status (we’re open source)”.

Caveats:

  1. I acknowledge I’ve made a fair amount of assumptions/generalisations above about very large groups of individuals.
  2. Not every Big Tech company person is right for Status. In fact, a significant proportion of them will not be as they won’t share our values/principles. But if even 1% of them do share our values, and we can attract 1% of the 1% to contribute, we would significantly grow our contributor-base.

I’m not sure if this has been discussed before, but would be curious for thoughts from marketing/community/devrel folks especially cc: @jonathan @ShawnS @cryptowanderer


#2

My 2 cents as a dx/techwrite guy…

Units

In the past I have seen good results from individual standalone products being published as open source and integrated into the team’s product as a whole like a dependency.

To illustrate trivially: when the tutorial about generating your three-word Status name in Nim is out, and the name generation tool can be used stand-alone, people will integrate it into their own dapps in some way and be encourage to contribute to it without having to deal with the Status-react baggage. Granted, this is a silly example as no one would actually use that tool outside Status probably, but think of some other units like the previously discussed protocol separation and maybe a chat unit API which lets other dapps tap into the chat channels without running Status, standalone wallet management part, pluggable ENS infrastructure to allow for fully custom ENS domains, etc.

Status Mode Plugins

One other thing that I think would vastly increase the public’s engagement is something I’d given much thought previously IRT Status Desktop: Status mode plugins.

I know the plan is to eventually have Status Desktop serve the purpose that mail servers are serving now, which would help a lot with decentralization. But what if people could build their own additional modes, their own flavors of Status that are activated with certain options when launching or in settings, thus incentivizing running Status no matter what project you belong to? Here are some examples:

  • Status as Gas Relayer (I know this is already being worked on to some extent, cool, but would be infinitely cooler if developed as a plugin and demonstrated to the public as such, to encourage development of similar plugins)
  • Status as BridgeDAO node
  • Status a Validator client (possible with Nimbus)
  • Status as Beacon Node (possible with Nimbus)
  • Status as full archive node (for restoring hybernated content after rent expiration - people will pay for this service, there hasn’t been a single government or official entity in the world that hasn’t forgotten to renew their SSL cert or their hosting plan, and they will forget to cover smart contract rent storage costs, this is where full archive nodes will jump in) - should also be possible with Nimbus eventually
  • Status as IPFS or Swarm node
  • Status as Sia host

All these could be in settings where you just activate them, populate the necessary values (coinbase address, staking amount, private key source, whatever else the mode requires), wait for sync and you’re up and running with a heavily incentivized Status app. Think of it like running Mist in default mode, or with some command line options like --light, etc. On very beefy machines, one could even run all those nodes and have Status supernodes that would effectively enable home multi-“mining” in a way. In addition to all this, every Status desktop node would by default be doing Whisper (or whichever protocol we settle on) sync so that the messaging would become much more reliable and decentralized.

Cherry on top - such an architecture would allow “command line Status” to exist where you can spin up Status without a UI on some servers and have them perform these functions on no-GPU devices without screens or in headless virtual machines, further letting people spin up Status on server hardware rather than consumer grade computers that would be required to run the UI-based version.


We’d have a de-facto platform into which people could inject custom modes of work (the modes could be plugins), which would spread adoption virally and increase contributions from the outside as many more parties would be invested in making it all work much better, and we’d outsource a lot of the work as people would have their own projects’ best interest at heart when choosing a platform to develop on. Take for example a tool like the Enjin wallet for games - it shares many functionalities with Status, but would function adequately as a plugin and would merge the two ecosystems. As things stand right now, my Status integration for my conference will have to be put on ice and I’ll likely turn to Enjin, encouraging people to install that instead, but if Enjin were a Status mode, we’d have the best of both worlds.

Anyway, my 2 cents, just daydreaming about a Statusomanic future here.


Status feedback from Blockconf.io
Ethereum Gas Station Alliance
PRBS protocol proposal - An incentivized Whisper like protocol for status
Gas Relayer for Status Nodes
#3

This jogged my memory about this post I read a few months back. https://mtlynch.io/why-i-quit-google/

He quit Google to work on a couple side projects including trying to build a business on top of Sia (decentralized file storage).

It also brings up a possible 4th category, “Indie Hackers”, which could be good candidates for working via liquid funding.


#4

There’s something more traditional available in the short/medium term: separate the chat protocol in a shared library that can be used to write plugins for other messaging software (like Pidgin or Jitsi).