Expectations of costs

One of the challenging things I’ve found here is that there isn’t a very good understanding of what modern software costs, both on the development side, and for services of various kinds.

For me, the mental model I’m using is that getting paid — whether hourly or more as a sort of honorarium — should be thought of as being about $50USD per hour on a global basis. In some places in the world, that is a lot! For North American / Western Europe freelance development, that’s about half to a third rate.

So, if a project has $500 / month in recurring support, it means that we can expect about 10 hours per month of work on it. One most be careful not to overly financialize this — for a side project, it means you can buy your own time back.

So, that’s 100 people at $5/month

Of course for organizations, a more appropriate level of monthly support might be $50, $100, or even the whole $500/month.

I include this note about organizations, because it is likely the fastest path to sustainable funding over time.

Recurring funding

I am a big believer in recurring funding over time that maintainers and other contributors can spend time on a monthly basis supporting software.

Some months this might be cleaning up some tech debt in preparing for a TW version update.

Some months it would be smaller features added, guided by what’s interesting to contributors.

Other months it might be documentation and promotion to find new users and use cases, and to better support existing and new users.

For example, we did a lump sum for File Uploads for Saq, but no recurring. It’s been useful for his own needs and was worked into needs for core development of TW itself, so it will continue to be a useful building block.

To further expand it or move it into core, it really should have at least 100s of dollars per month to be kept up to date and supported.

One could expand this to other TW core plugins — people are already asking for ActivityPub support to be added to the Twitter plugin. We are at a deficit of funding just to keep things working with core beyond Jeremy.

The mental model one should have for working software is, if I enjoy it (or rely on it!) I should be funding it on annual basis. Even just the shifting nature of JavaScript means that this is needed.

Bounties alone lead to one off software that might not even work a month later after it’s delivered. So, a year at a time reliance seems like a good fit.

I’d say $100/month — or 2 hours of time — is the minimum to aim for if one wants maintained software.

On Cloud Services

For hosting services, you start with the same costs of software, but then add server administration and support. The marginal cost for an extra individual user is low, but only when you get to 100s or 1000s of users. And that’s with minimal support provided.

There are also legal liabilities about content and user data.

Mostly I think cloud services should fall into two categories.

  1. some code that technically proficient people can use to run their own servers (like TW NodeJS)

  2. services that are run by a structured entity. This could be a for profit business or it could be a co-op or other structure

And of course, some of (1) can be setup to run (2).

Note: I’m a member of Social.Coop which I pay into to run a Mastodon server for me and other members. There is some recent writing on what sort of resources to have in place Social.Coop Wiki | How To Make The Fediverse Your Own

Another note: the TW community isn’t covering its own costs for our community infrastructure, never mind the many volunteer only time that is currently donated.

How to think about what is needed to fund building new features

People need dedicated time to focus in figuring out a big new feature, plugin, or a whole new edition.

So sometimes one needs a bit of an up front pool to really focus for a month or 3, before moving into an annual cadence of monthly funding.

Having a 100 hours over 3 months is a not unreasonable scope for some things. That’s a little over 33 hours per month or 8 hours per week. By my formula, that’s $5K.

Of course, there are other things that are much smaller in scope that people find very valuable! And, if we think of this as an honorarium (some people are privileged enough to be able to just build open source software outside their day jobs — this is a nice extra incentive OR a way for them to compensate others who don’t have this privilege), then a little bit of funding can go much farther than the dollars and hours I’ve outlined.

Still, the point stands. A $1000 medium-ish feature is about the starting point one should expect, and about the minimum size we would want to see in order to create a project in OpenCollective.

Big dreams

I’d love to see more people getting compensated to work on TW projects of all sizes. I’d especially like to see individuals outside of North America / Western Europe to be able to earn a living creating and maintaining open source software. For some of the numbers I’ve stated, like $500USD/month, that can be sustainable full time monthly pay!

I’ve written this in first person @boris voice, because these norms and expectations need to be turned into shared community guidelines. So: this shouldn’t be taken as final or even agreed upon yet. It’s “for discussion”.

And, to learn, we’ll need to experiment further.

3 Likes

Thank you @boris, this very well matches my thinking as well.

We do not yet have a culture in the TiddlyWiki community of needing to support plugins and core development and one may well ask, “why is this needed when there continue to be plugins published and core features get added without it?

Currently core development depends entirely on whether someone with the necessary skills has the personal need or motivation to add a feature. At times we get lucky because someone is doing paid work for clients that indirectly leads to core improvements. However, this is also why the core is underdeveloped and we are barely scratching the surface of what can be done! There is no shortcoming of great ideas in this community, whether in the discussion forums or on GitHub and often you hear someone bemoan that nothing happens with those ideas. This is the reason why those ideas are not pursued, the development is entirely dependent on volunteers and there is a limit as to how far that will take you.

Then there is the case of plugins. There is no shortage of plugins in the community, we have new ones popping up all the time. But how many of them are actually maintained over time? And how many get abandoned and never get updated and can no longer be used? We probably have as many if not more abandoned plugins than we have maintained ones. The lack of ongoing support for the development and maintenance of those plugins is a contributing factor. Developers create plugins motivated by their own needs or interests, and as those wane they have no motivation to continue the maintenance work. It is work and it is time consuming.

From the perspective of a developer, my work on the FileUploads plugin felt very much like volunteer work with an associated honorarium, and the number of hours spent far exceeded what I had anticipated.

However, the knowledge that there were community members who valued the work enough to want to contribute to it financially was highly motivating. It is very helpful to know that there are users interested enough in what you are working on that they were willing to contribute to it financially. It is easy enough for people to express a passing interest if you propose to work on something new, however you can never be sure how many of those realistically see it as being something that they might use.

As a completely hypothetical example, I can never be sure how many people actually use and find value in Streams on a regular basis (or the FileUploads plugin). Or how many people would be likely to use the WebDAV farm stuff if I worked on it to make it public. Now assume there was a monthly commitment by 10 users to contribute $5 per month to ongoing development of Streams. The resultant funds would barely buy me a decent dinner every month, but I would likely be a lot more motivated to find the time to work on the development as I would know that people find value in it. If you wanted ongoing, regular and assured development for a project, you would need to fund the developer a fair bit more in excess of that.

For most of us, $1000 is a large amount of funds to sink into supporting one project. However, it really does not go that far in terms of funding development work. The way this becomes manageable is when 50 people chip in with $20 each. Not only does that make the individual fiscal burden sustainable but also, having 50 people supporting the project provides its own motivation and momentum. We are a small community, perhaps to get things rolling we might initially be looking at 25 people chipping in $40 each for something that they really want. However these numbers aren’t as high as they might appear at first glance when thought of in this manner.

Lastly I would like to clarify that while I have written this post very much from a developer centric point of view, that includes wikitext developers and also applies to others that might work on administrative parts of a project, documentation, or user research.

2 Likes

Yes exactly! Design! Marketing! Support! All of it is valuable and has to get done somehow.

I used the development example as a starting point of work to be done, but a lot of issues are triaging and troubleshooting — or have better documentation or UX in the first place.

1 Like

Thank you @boris @saqimtiaz. A direct way to inculcate a different attitude about funding TiddlyWiki might be to address it more prominently and creatively on tiddlywiki.com, perhaps expressing it as “If you find TiddlyWiki useful, here’s why and how you might want to pay for it”.

As you note, we need to evolve some shared community guidelines. We can discuss them here, and then publish them to tiddlywiki.org to make them official.

1 Like

Just to bump this thread really…
image

I’m working on the tiddlywiki.com updates now, I hope to deploy very soon.

5 Likes