Hello,

Two cents of a non-qualified non-programmer here.

On Mon, Aug 27, 2018 at 10:54:15PM +0100, David Gerard wrote:

Lotta people use Gitlab precisely because you can self-host a Gitlab instance - but you can use them as a service provider it's easy to leave.

The beauty of git is that it is decentralized and doesn't even need something like Gitlab to develop software collaboratively. Alessandro summed up the situation already.

What I see as the crucial part is the "social" component. I'm afraid this somewhat derails Alessandro's intended discussion as my point totally ignores "who" the current owner of github is.

If you have a project and are looking for more developers to join it, you need some kind of visibility so potential developers get aware of you. In that sense, github serves as a social network and its current state is close to amazon or ebay - and that is what I suspect is why they even bothered to buy it.

Sure, you can set-up your own ebay-like website or join one of the existing alternatives, but if you really need to get rid of your old stuff by the end of the week, your best bet is where the most eyes will see your offer.

So the gap we may need to close is how potential developers (and employers) get to know your project, and its code that might be hosted in the living room of your parents in law on a RasperyPi.

...

...

than most other companies -- but they are the same ones who wanted to kill us out of the market, before turning into friends who still would love if we disappeared.

Doesn't matter to me. They could have turned by 180° and LOVE us! I don't want us to rely on "good faith" that this may be the case. We need a decentralized infrastructure that makes their intentions irrelevant. Like if they'd take part in torrents. File transfers would be faster if they joined, but still be possible if they wouldn't.

Greetings,

Guido

On 28.08.2018 09:29, Bernhard E. Reiter wrote:

Am Dienstag 28 August 2018 01:19:54 schrieb Guido Arnold:

...

We need a decentralized infrastructure that makes their intentions irrelevant.

This is the direction where I believe we must head.

Just want to throw in a relevant link to a project combining ActivityPub and git: https://github.com/forgefed/forgefed

Hi all,

sorry for being late in the discussion but I still want to comment on one point:

On Tue, 28 Aug 2018 15:11:06 +0200 Carsten Agger wrote:

I'd say, though, that my experience is that the "social media" aspect of Github is not as important as e.g. on YouTube or eBay. People find your software if they hear of it somewhere, in distro repositories, through clients, co-workers, mailing lists, forums, etc., and it's not so important where it's hosted. PyPI and CPAN (for Python and Perl) are more important, I think, but also not really social media.

Couldn't we argue the same way if we would discuss "traditional homepage vs Facebook page"?

Sure, with every search engine you can find a homepage (almost) as fast as a Facebook page. Keeping aside that Facebook often makes it easier to find a specific person because you can search specific properties like name, city,... But if Facebook becomes the de-facto standard for people personal home, than many people will only search at Facebook, if they don't find you, you don't exists for them. Facebook reached this state for a large number of internet users already.

All this is more or less true for code hosting with Github these days as well.

A thing that /is/ nice, though, and that makes it very irritating that Github isn't free software, is the pull request and code review functionality. After using it, it's hard to go back to inspecting diffs in terminal windows.

I think the "value added" functionality is what many "old school hackers" underestimate. Sure you can have a plain and stupid VCS, a separate bug tracker, a separate project management tool, a separate wiki,... In this case it might be easy to move to another VCS if you have to, ignoring that you will break all the links from the bug tracker, etc for a moment. And sure, people can send their patches just per email.

But I think that's no longer the workflow and integration which will invite many new contributors to join your project. I read a blog post from a Gnome Developer recently where he wrote how amazing it is that they get so much new contributors since they moved from their ageing git repository and bugzilla to Gitlab.

Another part of the social lock-in effect is that if you host your own project on Github, the chance is high that the 3rd-party libs you are using is also on Github. This way you can easily collaborate, mention the developer of a 3rd-party lib in your bug tracker if you need some feedback, send back a pull request, etc.

I read regularly from projects who decide against moving away from Github, exactly for all this reasons.

Cheers, Björn

Am Mittwoch 29 August 2018 07:04:05 schrieb Bastien:

https://www.gnu.org/software/repo-criteria-evaluation.html https://www.gnu.org/software/repo-criteria.en.html

Not taking new developments into account, though as the last evaluation came from 2016-04-13.

On Friday 31. August 2018 13.03.22 Alessandro Rubini wrote:

But I have a question for Berhnard, who says among other things I agree with:

...

• Use hg or other trackers if you can.

why? It's already oh so difficult to get people make decent commits to git, where at least I can point to all the world doing that...

I might answer that as someone else who prefers Mercurial.

Firstly, it is a capable tool for doing distributed version control whose performance has easily been good enough for what most people need it for, including things like the Linux kernel, which is usually the vehicle used to discredit solutions other than Git.

It employs a conceptual model that is powerful enough for what most people need it for. Here we ignore random people on Stack Overflow who exclaim things about Git being a "powerful object database" when asked to justify some arcane incantation required to do what might have been straightforward with other solutions.

It has had a decent user interface from day one, as far as I can tell. Meanwhile, I recall advice on adopting Git which involved the Cogito front- end, now long since merged in with the actual Git interface, I guess. (Developers find a Subversion-style command interface comforting: who knew?!)

There is interoperability with Git that is presumably acceptable given that people managed to migrate their stuff to Git after being lobbied to move to Git(Hub).

It is actively maintained. I may not like the nature of some of the contributing organisations, but I cannot dispute that there are organisations who would not want to see it go away.

All of the above are merely things that do not disqualify solutions like Mercurial, and from personal experience I could probably suggest tools like Bazaar (the "NG" variant, of course, given that Canonical pretended that the original Bazaar never existed) with caveats about the last point, although I imagine that someone still maintains that, too, maybe just not Canonical any more.

But possibly far more important than the above, which is only stated to undermine claims of "not good enough" is that we all benefit from choice. I could probably find some advantages of Mercurial, too, but I would be satisfied with just giving everything a fair hearing.

Paul

On Fri Aug 31 11:03:22 UTC 2018, Alessandro Rubini wrote:

...

• Use hg or other trackers if you can.

why? It's already oh so difficult to get people make decent commits to git, where at least I can point to all the world doing that...

Bernhard gave some good reasons but I can think of another:

* To follow the cultural norms of the communities you are part of.

My impression is that a number of projects started to use Mercurial because git was initially linked very closely to development of the Linux kernel. So, projects associated with other operating systems may have adopted Mercurial as a strategic move. Also, Mercurial was seen as having better cross-platform support in the beginning.

I'm thinking of Symbian and the OpenSolaris derivatives. Inferno also went via Google Code (svn) to Bitbucket (hg).

Using Mercurial instead of git is also a bit like using another kernel instead of Linux. It seems unnecessary to use something else when you already have something that works, but it's useful to have working options in case you find yourself using a device without a Linux port but with FreeBSD support, for example.

David

Am Mittwoch 05 September 2018 21:44:20 schrieb Alessandro Rubini:

Having two options instead of one is always good.

Yes, this is why my post was about the effect chains if we use and support one tool or several ones. Because in a lot of situations others are already completely booked on one tool, I'm using all opportunites to use the other, because they come less often. Just like I am always trying to use https://iridiumbrowser.de/ instead of Chrome and Edge if I can. And a GNU system instead of Windows. LineageOS-microg over Vendor Android/Linux. And so on. It is not a major hassle for me, I'll just keep an eye open for more Free Software opportunities.

But back to Mercurial SCM (aka hg from https://www.mercurial-scm.org/):

Today I read some (most?) documents on the project's site, and I see that it's very similar,

Thanks for giving hg a look. In my experience it is a sound option and comes with comparable power, if compared to git.

but on the flip side it looks like interactive rebases are not as easy as they are with git, and I really use them a lot (I write several features and test them all together, so I often squash my fixes in the original commit before pushing).

With due respect: Here you can see how your style of working was shaped by the tool. In my company (where we use hg and git) we'd already lost code because an interactive rebase can lead to data loss, thus breaking a mental concept that some have of an SCM to be able to reconstruct each configuration once it has been checked in. Still I believe interactive rebased can be useful, and you've probably found the extensions that allow it for hg,

e.g. see the dicussion at https://stackoverflow.com/questions/1725607/can-i-squash-commits-in-mercuria...

Also, I don't like much the data model (which is why, I think, changing the whole history is not as easy as with git).

Thank you none the less, it was interesting reading.

Thanks for considering hg, a technically diverse "ecosystem" is much more resilient against all sorts of "problems". :)

Best Regards, Bernhard

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 09/06/2018 06:42 AM, David Boddie wrote:

On Wed Sep 5 19:44:20 UTC 2018, Alessandro Rubini wrote:

...

Today I read some (most?) documents on the project's site, and I see that it's very similar, but on the flip side it looks like interactive rebases are not as easy as they are with git, and I really use them a lot (I write several features and test them all together, so I often squash my fixes in the original commit before pushing).

Yes, I think there's a compromise between flexibility and simplicity. Mercurial seems to be focused more on simplicity and ease of use, but that might make certain tasks difficult to achieve depending on your workflow.

...

Also, I don't like much the data model (which is why, I think, changing the whole history is not as easy as with git).

I think that is regarded as a feature in Mercurial. History rewriting may be a useful feature in git but it could have limited use if your repositories are already public. When Mercurial and git were evaluated at a former employer the ability to rewrite the history was counted as an advantage for git despite the problem that it would have been very difficult to justify using it on the company's public repositories.

Still, it's useful to have the option to do it, especially for private repos.

...

Thank you none the less, it was interesting reading.

You're welcome.

David

On the topic of history rewrite, I'd argue that allowing it on a private (read: development) repository provides better commits and less chance of losing work. It allows the developer to incrementally commit small, incomplete, possibly even wrong changes, then decide how they should be packaged and layered before attempting a merge. Without this capability, our programmers would tend to keep a massive chunk of unstaged changes locally, then submit the entire mess for review once it was working properly. History rewrite allows the developer to verify a multi-week, multi-layer, self-dependent modification and still be able to split it apart into logical, incremental chunks with relative ease.

I can't imagine working without this feature. The lack of that feature on other source control systems might explain the relatively poor commit quality we have observed on those systems (or from people trained on those systems) over time -- their commits to be very large, doing way too much and touching too many files. Needles to say this causes a massive headache if/when the patch introduces a regression.

- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com

On 09/06/2018 02:46 PM, David Boddie wrote:

On Thursday 6. September 2018 12.21.17 Timothy Pearson wrote:

...

On the topic of history rewrite, I'd argue that allowing it on a private (read: development) repository provides better commits and less chance of losing work. It allows the developer to incrementally commit small, incomplete, possibly even wrong changes, then decide how they should be packaged and layered before attempting a merge. Without this capability, our programmers would tend to keep a massive chunk of unstaged changes locally, then submit the entire mess for review once it was working properly. History rewrite allows the developer to verify a multi-week, multi-layer, self-dependent modification and still be able to split it apart into logical, incremental chunks with relative ease.

But are they sharing the changes they commit before rewriting the history and sharing it with colleagues?

No, and I should have pointed that out. When you start sharing, all bets are off and history should not be rewritten, however at the same time you're not likely to be sharing broken / nonfunctional code that's still in the middle of a rewrite. At the very least, it would be expected that you clean up your own mess a bit before trying to engage a colleague for assistance, to avoid wasting time all around, and even then it would be in some kind of WIP branch that would be deleted later on.

...

I can't imagine working without this feature. The lack of that feature on other source control systems might explain the relatively poor commit quality we have observed on those systems (or from people trained on those systems) over time -- their commits to be very large, doing way too much and touching too many files. Needles to say this causes a massive headache if/when the patch introduces a regression.

I think it depends more on the workflow more than the features of the revision control system. Of course, those people used to non-distributed systems may be in the habit of batching their commits for several unrelated issues because they are used to a centralised model where committing a change involves sharing it with everyone else.

I think you could do something similar to git with Mercurial but it wouldn't be exactly the same.

As long as the general class of functionality is present, that's fine. No ability to stage and rework a commit stack though is going to push people more toward the monolithic / batched commit mode from what I've seen.

David _______________________________________________ Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion

This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct

Without derailing too much this wonderful discussion, I would like to make a comment on lost commits/code.

IMHO git is not a backup solution, its a version control system. sometimes we forgot this simple but important tiny thing so freq commits (even on a local cloned repo or branch) is really useful and copy/merge/rebase/rewrite/whatever when ready to master.

Evaggelos Balaskas https://www.linkedin.com/in/evaggelosbalaskas

I won't cite any past message because I lost some of them during an accidental removal of the emails on my computer, so forgive me if this was already said by someone else.

Personally, I don't think we need to dive down into completely different VCS software just because a VCS repository provider decided to go evil. We can still use Git but push people to not to use GitHub, not because of the recent Microsoft acquisition, but due to a problem we have been facing many months before that, which is even worse than the acquisition: non-free software being forced to the people who visit the GitHub website, through client-side JavaScript[1].

GNU Savannah provides Git repository hosting too, and is powered by GNU Savane, a host software that you can use on your own[2]. There is an ongoing effort by the Peers Community to make a VCS hosting software called Vervis[3]. Besides there is host software called Kallithea[4] (partly maintained by the Software Freedom Conservancy, which has the plus of already providing correctly-marked free/libre client-side JavaScript, and also has many features to allow commits to be made from the web browser) and there is Pagure[5] (which I don't know how good or bad it is in terms of software freedom for the end-user/website-visitor). All of these, as far as I know, work with Git.

[1] https://www.gnu.org/software/repo-criteria-evaluation.html#GitHub

[2] https://savannah.gnu.org/p/administration

[3] https://peers.community/#projects

[4] https://kallithea-scm.org/

[5] https://pagure.io/pagure

-- - Página com formas de contato: https://libreplanet.org/wiki/User:Adfeno#vCard - Ativista do software livre (não confundir com o gratuito). Avaliador da liberdade de software e de sites. - Página com lista de contribuições: https://libreplanet.org/wiki/User:Adfeno#Contribs - Para uso em escritórios e trabalhos, favor enviar arquivos do padrão internacional OpenDocument/ODF 1.2 (ISO/IEC 26300-1:2015 e correlatos). São os .odt/.ods/.odp/odg. O LibreOffice é a suíte de escritório recomendada para editar tais arquivos. - Para outros formatos de arquivos, veja: https://libreplanet.org/wiki/User:Adfeno#Arquivos - Gosta do meu trabalho? Contrate-me ou doe algo para mim! https://libreplanet.org/wiki/User:Adfeno#Suporte - Use comunicações sociais federadas padronizadas, onde o "social" permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP (https://libreplanet.org/wiki/XMPP.pt), #DeleteFacebook #DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via #Mastodon (https://joinmastodon.org/). - #DeleteNetflix #CancelNetflix. Evite #DRM: https://www.defectivebydesign.org/

Am Samstag 08 September 2018 15:36:08 schrieb Adonay Felipe Nogueira:

Personally, I don't think we need to dive down into completely different VCS software just because a VCS repository provider decided to go evil.

The argument is about how to counter the network-effect that will makes it easier and easier for a leading provider to get more ahead of others. And it is about what is a more sustainable choice.

The money that Github is earning with helping to develop proprietary software, allows it to innovate fast and turn a user experience of git into a user experience of git-hub. If many people are socialised with it, they want that user experience whereever they go. This is why even using Bitbucket as a proprietary competitor does something good to keep the competition open. And using hg or services that allow hg also help weakening the network-effect cycle a bit, while strengthening chances of competition.

GNU Savannah provides Git repository hosting too, and is powered by GNU Savane, a host software that you can use on your own[2].

It is very good that these Free Software product and services exist. The problem is that many developers now believe them to be too far behind (in features, available add-ons and user experiences) compared to github/bitbucket/gitlab.

Even Allura (which is the Free Software that runs Sourceforge) is considered by many to not play in the same league.

For instance Savane is an continuation of the old sourceforge code variant, a newer one is http://fusionforge.org/ which was used by Debian and others (see list at https://en.wikipedia.org/wiki/GForge#FusionForge) But Debian is moving off Fusionforge. The listed organisations (which includes my company) have failed to finance and organise a steady development of Fusionforge so it could keep up. Think about https://en.wikipedia.org/wiki/Gna! which shutdown a while ago.

If we (as Free Software people) want a first class Free Software product and a number of service providers offering to run it for us, we need to make sure professionals can earn serious money with it.

Regards, Bernhard

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Hello Bernhard.

...

Personally, I don't think we need to dive down into completely different VCS software just because a VCS repository provider decided to go evil.

The argument is about how to counter the network-effect that will makes it easier and easier for a leading provider to get more ahead of others. And it is about what is a more sustainable choice.

By the phrasing "leading provider" I assume that it means a company that won't share the software innovations with the rest of the community so that all can benefit. The company gets an upper hand and can impose deals like what you write about Github that helps proprietary software companies in their business.

If this is the case then I would suggest to seperate out the parts that makes Github and others to have an upper hand and then see how the parts can be countered using free software and free innovation.

Github seem to take the inter-connectedness that would be lacking in many of the other alternatives. You can click a button to fork a project, you can start "watching" certain projects and get email notifications, you can download the sources without needing Git, you have an interface of markdown that every project adapts and the README is presented as if it were a web page.

I am at a loss right now of suggestions or methods or ideas to counter Github but it sounds easy enough to be able to get going using a few people. It might just take a discussion during a week for a good project to spring up later.

The money that Github is earning with helping to develop proprietary software, allows it to innovate fast and turn a user experience of git into a user experience of git-hub. If many people are socialised with it, they want that user experience whereever they go. This is why even using Bitbucket as a proprietary competitor does something good to keep the competition open. And using hg or services that allow hg also help weakening the network-effect cycle a bit, while strengthening chances of competition.

It's really bad that a company thrives on a thing like "open source" while using that income to fund "closed source". I wonder if even the open source camp would approve of that as a thing to further improvements.

...

GNU Savannah provides Git repository hosting too, and is powered by GNU Savane, a host software that you can use on your own[2].

It is very good that these Free Software product and services exist. The problem is that many developers now believe them to be too far behind (in features, available add-ons and user experiences) compared to github/bitbucket/gitlab.

Even Allura (which is the Free Software that runs Sourceforge) is considered by many to not play in the same league.

For instance Savane is an continuation of the old sourceforge code variant, a newer one is http://fusionforge.org/ which was used by Debian and others (see list at https://en.wikipedia.org/wiki/GForge#FusionForge) But Debian is moving off Fusionforge. The listed organisations (which includes my company) have failed to finance and organise a steady development of Fusionforge so it could keep up. Think about https://en.wikipedia.org/wiki/Gna! which shutdown a while ago.

I thought I would add up the list with two more Git providers that I use in parallell:

https://www.tuxfamily.org/ https://pagure.io/

They seem to be alright. I'm not sure about how Pagure is doing with their stance on proprietary software but Red Hat is usually a nice company in that regard and would prefer the repos to contain free software projects only.

If we (as Free Software people) want a first class Free Software product and a number of service providers offering to run it for us, we need to make sure professionals can earn serious money with it.

I could share an idea I have had about the financing and the "poor free software developer not getting paid". It's not a very complicated idea and it would work if enough people have the initiative to do so.

The idea is to make an economical funding platform. The platform itself only communicates between the two parties users and developers, economically. If the developer is signed up and ready to develop, users are signed up and leaving opinions, bug reports, requests and other issues - the process is a matter of transmitting funds. What would be possible right away is to transfer funds using traditional means such as physical transportation or digital transmission using anonymous payments. I see a problem with the platform being popular right away, the platform is going to slowly gain traction if implemented right and developed further. The starting position needs to calmly work out means. I have a few means that I thought about, such as a service to come home to a user and take the discussion as well as payment from them which will be transfered to the developer of said software including all the demands that that funding has.

Work it out good and it will work good.

Kind regards, Andreas

On Friday 14. September 2018 09.06.50 Bernhard E. Reiter wrote:

Am Donnerstag 13 September 2018 17:05:41 schrieb Andreas Nilsson:

...

The idea is to make an economical funding platform. The platform itself only communicates between the two parties users and developers, economically.

This has been tried a number of times in the past and hasn't worked out well.

It is worth noting that there are a number of recurring obstacles. Gratipay was attempting to pioneer consolidated payments between individuals, but there is a very narrow path that needs to be navigated to avoid being considered as some kind of financial institution that holds other people's money whilst also processing payments (or delegating that processing) in a way that does not overwhelm the actual payments with processing fees.

Liberapay took over where Gratipay left off, but their payment processor has discontinued its relationship with Liberapay, apparently claiming that they didn't think that Liberapay was fulfilling its obligations:

https://liberapay.com/ https://github.com/liberapay/liberapay.com/issues/1171

There seems to have been an account linked to an organisation which cannot be legally serviced by the payment provider, and I guess the blame fell on Liberapay for that. (This is from a quick perusal of public information about this, so it may not be completely accurate.)

Other organisations exist, but it isn't completely clear how they operate in a similar position without getting hassled about financial industry/crime regulations. Here are some examples:

https://www.bountysource.com/ https://tidelift.com/ https://opencollective.com/

Open Collective seems like it promotes a model that I may have advocated before, emphasising collectives (which Gratipay and Liberapay both support). If you have an organisation like the Python Software Foundation, to take an example I tend to use, then one could envisage establishing a presence on such a platform to solicit funding for Python development, where those giving money might have reason to assume that their money is going to the right people due to the presence of an entity they know and trust. Meanwhile, those doing the work would presumably be able to receive payments in a properly-regulated way.

Then again, I am inclined to think that such platforms tend to favour transactional work, often underpriced, that is viewed as fashionable amongst the relentless promotion of the "gig" economy (hence the venture funding for some of the companies above). Instead, I think that structures to fund Free Software should enable developers to actually draw a salary, not have people speculatively do work in order to compete for payouts.

Maybe what is really needed is some kind of virtual organisation for Free Software, maybe some kind of consulting organisation. Naturally, there are non-virtual organisations of this nature already, but the bottlenecks are getting hired by them and for those businesses to be able to hire people. And recruitment is still largely performed using pre-digital techniques (if you ignore the superficial use of digital tools).

What could help would be a system for micropayments that is easy and has low transaction costs. Another approach would be to have a organisations that distribute small amounts of money (e.g. GNU system distributors would be in a good position to do so.) A key point is peoples willingness to pay for something, even if they are not force to.

Micropayments with low transaction costs is like the Holy Grail of payments, though. But the matter of persuading people to pay for stuff is worth further thought, and there was a blog article about that recently:

http://think-innovation.com/blog/should-you-donate-to-open-source-software/

One thing I ought to mention is the need for solutions that use real money as opposed to today's favourite cryptocurrency. When looking for creative solutions there always appears to be someone wanting to sweep everything off the table to further their "cipherpunk" anarchist pipedream.

People need genuine solutions that do not involve financial speculation, legal uncertainty, and exposure to criminal schemes. A crucial aspect of funding Free Software is exactly that of giving people certainty so that they can focus on what they actually want to do.

Paul

On Monday 17. September 2018 12.42.18 Bernhard E. Reiter wrote:

Am Samstag 15 September 2018 17:20:26 schrieb Paul Boddie:

...

Then again, I am inclined to think that such platforms tend to favour transactional work, often underpriced, that is viewed as fashionable amongst the relentless promotion of the "gig" economy (hence the venture funding for some of the companies above). Instead, I think that structures to fund Free Software should enable developers to actually draw a salary, not have people speculatively do work in order to compete for payouts.

If I do understand you correctly, you believe they fund more "marketing" and less "development". Whereas sometimes good quiet engineering would need to be funded. In a bird's view I'd agree on this. The challenge - though - is to find out which kind of engineering work is worth what.

There are at least three forms of funding platforms that tend to see some Free Software development activity:

* Bounty funding (such as Bountysource) * Ongoing funding (such as Liberapay) * Crowdfunding campaign (such as Crowd Supply and IndieGoGo)

I think these platforms tend to favour work that can be readily advertised, packaged and sold, but of course not all work that is worth doing will fit into this form.

Crowdfunding is most definitely something that has a marketing component, and this means that people have to make a pitch to others to convince them of the work's value, but software is still seen as intangible and less valuable than hardware. With hardware, you hopefully get some goodies at the end of the campaign that are exclusively yours and that people outside the campaign do not get. With software, you share the rewards with others, and also with everyone else if it is Free Software. People might wonder, as usual, whether they shouldn't just leave it to others to put up the money.

There are also a few common problems with ongoing funding and crowdfunding. One is that some people feel that they have to be highly responsive to their backers in order to keep them happy. This ends up with people burning out because they are effectively having to do the work plus an "always on" public relations job. YouTube millionaires have this problem, apparently, so I am not sure it can be solved easily with more money:

https://www.theguardian.com/technology/2018/sep/08/youtube-stars-burnout-fun...

(The other problem is that people fail to communicate, particularly if things do not go well, but that is another story.)

Bounty funding should get around this cultural problem of people expecting "always on" responsiveness, but the work favours things that are either "odd jobs" that don't pay very well or are things that would normally be put out as a contract for bidding. I noted in my blog article about funding platforms...

https://blogs.fsfe.org/pboddie/?p=1620

...that while the sums involved for some bounties are considerably better than the usual "tip jar" amounts, the rather informal arrangements around getting the work done, combined with people competing speculatively (as opposed to collaborating), means that these large sums go unclaimed. Three years on and the IBM people are still waiting for their LuaJIT port (or dragging their feet on accepting any submitted work):

https://www.bountysource.com/issues/25924774-enable-implement-ppc64-le-linux...

Ongoing funding potentially promotes a more sustainable way of funding people, at least if we can ignore those cultural issues around keeping the audience happy, because a developer can potentially prioritise their work appropriately and not feel that they have to dance to everybody else's tune all the time. But the problem then is to persuade people that the work is worth supporting. Some might claim that a successfully funded person could just be working for a company, but that requires a sole employer to put up that person's entire salary.

[...]

...

People need genuine solutions that do not involve financial speculation, legal uncertainty, and exposure to criminal schemes. A crucial aspect of funding Free Software is exactly that of giving people certainty so that they can focus on what they actually want to do.

Fine again, except for the last part. It is not the desire of the Free Software engineer that should drive the directions of funds, but the needs of the users. There can be a wide difference between the three things: a) what people want to do b) what people are good at c) what others need

To be succesful in my eyes, a funding model would need to make sure that mainly c) and b) is matched.

It is true that you cannot just have people doing exactly what they want and expecting to get paid for it, no matter what it is. (Well, actually you can: it is called art.) Then again, by "what they actually want to do" I meant the work of writing software, as opposed to things like meddling with dubious financial instruments, executing foreign exchange transactions, drumming up business on a speculative basis, and so on.

But you also cannot leave it to the whims of "the market" to decide, either, because you end up in precisely the situation where only the "cool", marketable projects get funding. And those projects may only address the fad of the day and leave nothing for others to build upon. Worse, for Free Software, they may also exploit other software projects to deliver their product.

Paul

On Tuesday 18. September 2018 18.25.26 Andreas Nilsson wrote:

When I think about crowdfunding I have stuff like "smaller hobby projects" in mind such as a design for an electric circuit that can do a funky thing. I don't have insight in the crowdfunding projects today.

I only tend to keep up with things on Crowd Supply. The other platforms seem to have a poor reputation. There have been pretty big campaigns for hardware, even ones that have delivered the anticipated product, so not Ubuntu Edge but things like Novena (open hardware) or Gemini (proprietary but "alternative" hardware).

For software, I don't see as much going on. I have mentioned Mailpile and Roundcube Next before, and here there is a difference in outcome. Mailpile struggled along with a fairly meagre sum (for what they wanted to do), then found some Bitcoin from donations under the sofa cushion (metaphorically) and managed to ramp up again, meaning that they may be close to some kind of release.

Roundcube Next raised substantially more money than Mailpile, but this money hasn't been spent and seems to have been resting in an account in Switzerland for three years waiting for people to spend it. There was some brief activity on GitHub a year or so ago, but nothing since. The backers seem to be resigned to using "classic" Roundcube or other things, if the comments on the campaign page are any indication.

With the lack of a middleman, or a team to communicate in between the funders and fundees, there is bound to be a stress related task at hand that is endured by the fundee. Be it a person, a team or a company.

Often, these kinds of campaigns are trying to squeeze out the last drops of efficiency in the economy, being low-priced, low-margin efforts. There isn't going to be any extra money to pay people for publicity, although I believe there are companies who offer promotional services, perhaps directed at getting campaigns funded more than anything else, though.

And lack of communication erodes trust. There are campaigns where every last setback is described, potentially leaving those responsible open to criticism, but even so, people are a lot more receptive to such tales of apparent failure and will forgive delays and even non-delivery if they feel that something took place and that the effort was genuine. When nothing is said, people start to get suspicious about nothing being done, even if the same efforts are being made, and they are less likely to be as forgiving with similar outcomes.

I am taking guesses at what this is lacking is something called "demand specificaton" in Swedish (directly translated). When a customer (here funder) is having an idea for a product, then they are thinking in terms of a finished product and as front end and concrete as possible.

Their ideas could be that they want the software to have certain GUI components here and there, while clicking on them should execute a task explained outside of coding terms.

What I'm trying to say is that the human component for tasks like this are probably going to lack in the crowdfunding platforms. It could and should be taken a look at if volunteers, organizations or even profitable companies could pitch in here.

Certainly, the notion of pitching an idea and getting people to back that idea with their money is not particularly compatible with the kind of iterative design that contributes to the production of good software. And another pitfall that might be even more likely with software is that of the campaign creator overselling what they intend to achieve.

[Bounty funding]

Sounds like an auction of developmental work. I don't know much about it. It's an interesting approach.

Actually, I saw some presentation by someone from Mozilla about their pet project for funding projects that involved "futures". That would be similar to auctioning in certain ways, but it all sounded ghastly and yet another potentially exploitative application of financial industry practices.

We can be sure that as soon as any auction concept gets applied to work, it will result in people underbidding to get the opportunity to work. This is, of course, familiar from any observation of procurement processes where companies offer to do work for unsustainable sums and then cut corners or exploit their workers to make the numbers add up.

[...]

...

It is true that you cannot just have people doing exactly what they want and expecting to get paid for it, no matter what it is. (Well, actually you can: it is called art.) Then again, by "what they actually want to do" I meant the work of writing software, as opposed to things like meddling with dubious financial instruments, executing foreign exchange transactions, drumming up business on a speculative basis, and so on.

I have a hard time following here.

Really, this was just me observing that where work needs doing, people want to get paid for actually doing the work and not being distracted with other activities that are unrelated to the work getting done.

So, when someone claims that everyone can get paid in today's cryptocurrency, it sounds great to them, but this would mean that people would need to deal with setting up their cryptowallet (or whatever), figure out how to exchange cryptomoney into real money, and all sorts of things that nobody should have to be troubled with.

I agree that the best approach is to blend various methods. Auction payments sound much like the market is in control of almost everything, while recurring payments sound more geared towards good software. Almost two opposites here. Crowdfunding is special, I don't know if you can talk about a market in that case, in the classical sense of it.

Thanks for sharing your thoughts on this!

Paul

On Wednesday 19. September 2018 09.48.06 Bernhard E. Reiter wrote:

Am Montag 17 September 2018 15:14:16 Paul Boddie wrote:

...

at least if we can ignore those cultural issues around keeping the audience happy, because a developer can potentially prioritise their work appropriately and not feel that they have to dance to everybody else's tune all the time.

You make it sound like a bad thing, there I disagree: I believe it is good that it is necessary to show that work is good.

The key element is "all the time". Clearly, if the work is not "art" then it must be relevant to others. But people also need to be able to exercise discretion about how they do certain aspects of the work and the direction in which the work is going.

What we have seen in various Free Software projects is that the developers refuse to listen to the users, accusing them of not understanding "design", "usability", "the big picture", having "entitlement", and so on. That is not acceptable and has resulted in substantial dissatisfaction (and has arguably set Free Software adoption back by many years in certain cases).

But at the same time I recognise that the developers ought to be in a better position to make technical and strategic decisions and should be allowed to do so. There needs to be a constructive conversation between users and developers to allow each side to recognise and exercise their responsibilities.

Paul

On 29/08/2018 11:23, Bernhard Reiter wrote:

Am Mittwoch 29 August 2018 09:22:57 schrieb Ion Savin:

...

I don't see why UI tools wouldn't make this process as friendly as GitLab/GitHub MR/PRs but I don't think they exist yet.

Have you checked out what latest Versions of Allura, Phabricator and gerrit and do to solve this use case?

I haven't looked at any of them.

I was looking for something really specific too the email workflow. A desktop app you can point to a mailbox and which is capable of providing a friendly interface for reviewing the patches.

I guess most people who used GH PRs would object to this workflow: https://github.com/git/git/blob/master/Documentation/SubmittingPatches

But with some supporting tools (even for triggering a build somewhere) it might not be so bad.

Regards, Ion Savin