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 ):
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.
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.
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.
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.
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.
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?
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.
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).
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.
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.
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.
):
Reminds me of