Scoping Social Coding: Community-driven FOSS only? Fedi-related FOSS?

Move your thoughts 💭 Advocacy
#1

Note: These are just musings. Scope TBD…

Related to Social Coding chat on the topic of the Commercial conflicts of interest in FOSS challenge, I wondered if there should be a further restriction of the (broad) scope of Social Coding Movement. I wrote there:

Btw, (F)OSS with corporates behind them as main drivers, e.g. open core models, are places where any 3rd-party users of the software should be particularly wary, as there are often a lot of hidden motives behind that open core that relate more to the commercial strategy of the companies involved. For Social Coding - which with the Free Software Development Lifecycle already has huge scope - it is likely best to limit in particular to Free Software and maybe further to the community-driven kinds.

Scope restriction

So what is the current scope actually? We have these 3 high-level components (Triple-F :smiley: ):

  • Free software
  • Free Software Development Lifecycle (FSDL)
  • Fediverse

This is hyper broad.

  • FSDL includes the entirety of software development methods, as applied to FOSS as well as their related ecosystems (if any).
  • Fediverse might be seen as one such ecosystem. The ‘technology substrate’ are the ActivityPub et al open standards.

A restriction of scope might be:

  • Only community-driven, fully non-commercial FOSS
  • Venn diagram of Free software and Fediverse, i.e. any FOSS project also prepared to leverage the Fediverse in their FSDL.
1 Like
#2

I, personally, have always found many restrictive or “no commercial” licenses stifling. I do not want to go back to the corporate world. I don’t want to have to ever have a job again. I want to be independent and free and be prosperous at the same time. So how do I pay my bills? I run a small business.

A lot of the restrictions in licenses, such as “no commercial use” assume it is some big corporate actor that would use the software. I’m just a little guy who doesn’t want to work for those giant corporations. The sad thing is that many times policies aimed at large corporations harm small business.

That’s why I prefer the MIT license or Apache license over GPL or AGPL. Although I fully respect people who use GPL or AGPL and I think that it has its place, I can’t use most of it in my business due to licensing conflicts.

I agree that internet infrastructure code needs to be open source and free, but prohibiting commercial use becomes a problem for some of us trying to make a living without becoming slaves to the corporations.

1 Like
#3

But don’t conflate non-commercial with copyleft, or free software with “gratis” software. You can earn a living with (A)GPL or other copyleft licenses. Yes, in current environment it can be harder than with more liberal licenses. It can also offer you protection. Plausible Analytics is a good example of AGPL-licensed software and 2-person company earning good money. And they compete against Google Analytics and such.

SMB’s and revenue versus Copyleft licenses are unrelated concepts. Though there is much to explore in the field of Sustainable Business Models.

#4

True. That is why I choose MIT license or Apache instead of AGPL or GPL. You can release free software without a restrictive license. And I mentioned the “no commercial” aspect since you mentioned that in your original post.

And, yes, you can make money with a FOSS model. But viral licenses such as GPL and AGPL make it incompatible with proprietary code, and I use proprietary code in my business. I want apps to work together, and AGPL and GPL force you to license everything under those licenses making it fundamentally incompatible with other licenses.

As such, I am often forced to create a competing project just to avoid licensing conflicts. It’s annoying to have to write my own software that does the same thing as a AGPL offering, but that is what I have to do if I want it to work with proprietary software.

I only mentioned commercial use because you mentioned “Only community-driven, fully non-commercial FOSS” as a possible restrictive scope. I wouldn’t like to see such a restriction.

1 Like
#5

Ah, you are right. I think that is probably too much in terms of scope restriction, and I actually didn’t intend it like that. Good you pointed it out to me. What my intention with that sentence was: Fully community-driven, and not FOSS that only exists as the product of a company with employees being the sole maintainers. And company going out of business meaning forking is the only option. Community-driven might also be worker / multi-stakeholder co-operative owned (for instance aforementioned The Pavilion), and include commercial activities.

I can imagine. I would be in favor of a focus on all well-accepted open source licenses applicable to FOSS and adhering to the 4 freedoms, such as by listed by FSF and OSI. And I should stress the word “focus” meaning that stuff that doesn’t fall directly in that scope will still find most of the patterns & practices generally useful.

#6

I am running directly up against this myself. I would love it if a community came together and helped me build a federated forum community software. But people don’t usually contribute to people who have ideas… they contribute to people who take action. So, in order to attract contributors, I have to build it myself first, at which point I don’t need the contributors as much.

So my project, even though it will be released under the MIT license, will basically just be my project sponsored by my small startup. Maybe I will get some contributors later, and maybe I won’t, but right now it’s all on my shoulders, like it or not. A democracy of one isn’t much of a democracy.

How should/would we handle upcoming projects that don’t even have backers yet (except the founders), but have potential?

2 Likes
#7

This is where other parts of social coding movement are meant to focus. Your question breaks down into multiple challenges, and likely even more best-practices as solution patterns to choose from. You might formulate this as a #documentation:challenges topic, and relating to Inception phase of FSDL.

Here is a strategic choice, like e.g.

  • I’ll start and maybe I will get some contributors, which would be nice.
  • I’ll start but given the scope I must get a maintainer team and multiple active contributors.
  • I’ll start but it must have a strong community that sustains the project, and will be active participant in a larger ecosystem.

Goal of the crowdsourced Social Coding website is that eventually you could use it as a guide for making such decisions.

Related to the best-practices, which are just documents, there’s the creation of automation tools to accompany them, such as IdeationHub which aims to make the transition from ideas to concrete projects easier and more inclusive.

#8

:slight_smile: Reminds me of About the Friendly Forge Format (F3) - Friendly Forge Format (F3) - forgefriends

This certainly is the what appeals to me most.

And it turns out to be my field of choice so… I would absolutely find myself if such a restriction of scope was set.

I propose something that is maybe less restrictive while being narrower:

  • Only healthy development lifecycles

With a definition of healthy that would exclude toxic or predatory behaviors such as Open Core (think GitLab EE vs GitLab Ce), exploiting legal loopholes to restrict user freedom (think https://grsecurity.net/), systemic dominance (think RedHat), code dump (think Signal.org or Android).

2 Likes
#9

I find myself doing the opposite: writing Free Software because proprietary software licenses are incompatible with copyleft licenses. And they are a plague: adding just one piece of proprietary software in a larger software that contains thousands of Free Software components makes it proprietary.

That essentially means that any proprietary software effectively breaks the “Free Software Development Lifecycle” because it is no longer Free Software and cannot keep cycling/evolving as a Free Software. It becomes a hybrid for which every action (distribute, modify, …) is subject to the terms of the proprietary license.

Now I understand that someone would want to use a Free Software at a point in time and distribute it together with proprietary software, as long as both licenses allows that to happen for whatever they intend to do with it. But it enters a very different lifecycle where most of what holds true in FSDL changed (some bugs cannot be diagnosed, some code cannot be studied, some features cannot be added, some distribution require negotiating contracts with third parties, etc. etc.).

I’m know this hybrid Free Software / proprietary software lifecycle is of interest to some people and I understand you chose this voluntarily @WisTex . I’m just saying it is very different from FSDL and I hope that I explained why.

1 Like
#10

Yeah, that’s why the emoji. I put it in parentheses as I don’t intend to use it. Though OTOH a nice acronym can serve to remember the scope.

Generally I am of the same opinion and principles as you. But there are some important nuances and reformulations to make…

  • “Only healthy development lifecycles”: I get what you mean, but this formulation clashes with existing definition of healthy lifecycle. Social Coding exists to address common Challenges to FOSS in general. These challenges threaten the health of the lifecycle, and the Best-practices can be used to overcome them and get healthier.

  • As for exclusion, I concur that toxic/predatory behaviors have no place in Social Coding. But the approach may be more to not actively include them, rather than ostracize upfront. Many people choose such models because they see no other way. But finding the other ways that DO exist is part of the exploratory adventure of Social Coding. It may be advantageous to also address and analyse the anti-patterns that exist, so that alternatives can be explored and recommended.

  • If someone wants to use anti-patterns in their project, e.g. Open Core, they are at freedom to do so. Even while Social Coding doesn’t directly support that, they would likely still find a ton of value in other components of the FSDL and can still heavily contribute to improve pattern library and tools, etc.

  • Maintainers and forum staff aren’t BDFL’s but merely facilitators. There should be a governance model where the movement steers itself. This scoping topic is more to set outer boundaries of the ‘map to explore’ as we sail out.

On the whole Social Coding wants to focus on getting the best kinds of FOSS practices on a pedestal, to serve the Commons and provide help not only in overcoming “Tragedy of the Commons” but having strong and healthy lifecycles that make FOSS an attractive proposition.

1 Like
#11

Open core is the wolf in sheeps clothing. You have little guarantee that at some point the project will ever open up fully. Infact it’s more likely to close up.

But at the same time depending on the project, often open forks of that code happen. Often these forks seek to enable the functionality that is locked away.

See SugarCRM and its fork SuiteCRM (after Sugar decided to close up entirely.

We also have that fork of Mattermost now as well.

Both Mattermost and SugarCRM benefited heavily from community leverage. Sugar was worse as it utilised badge wear, until the founder of Suite called them out on it. By pointing out how many badges would have to be in the app if the other software that SugarCRM ran on insisted on the badge wear.

Open Core seems at times to be a rather cynical way to exploit goodwill from the FOSS community while ultimately trying to get investment and become a unicorn.

2 Likes
#12

Exclude was a strong word indeed. I meant explaining clearly why and how they break FSDL so people understand the cost of giving into them.

2 Likes