
Seven Stages of Open Software - zdw
https://coiled.io/blog/stages-of-openness.html
======
diffeomorphism
Didn't we already have a long discussion with "commons clause" that 1. is not
sufficient to be called open source^{TM} as the term is actually used?

Call it "shared source", "visible source" or something, but open source is a
well-established term meaning something else (2.) .

Bad analogy: If your cellphone provider starts advertising voice for $0 as
"free speech" and then goes "technically, this is what these words mean ...",
you would simply say they are using these words wrong.

~~~
tasogare
Free software licenses are considered open source, yet they contains some
restrictions. Commons clause licenses have some restrictions, but there is no
reason they should be excluded from the open source definition, especially
when we consider why they exists and which companies they target.

~~~
yarrel
There is no part of that's true.

The restrictions in the mendaciously named "commons clause" license are
excluded by the FSD, BFSG and the file-off-the-serial-numbers copy of it that
is the OSD.

"Keep headers" or "share and share alike" are not restrictions on use,
although every April first do I realise that I once again haven't sent out a
fake press release about how the BSD licenses discriminate against my source
file header-removal business.

------
einpoklum
> Open decision making: And that communication will be open to the public, so
> that everyone can weigh in, vote, and determine what happens to the project

How is this a thing? Not in my experience. The public has access to issue
tracking and maybe a foo-users-l@mailserver.org .

Open decision-making, in projects which I know practice it, means contributors
(hopefully) and significant stake-holders get to participate in decision
making, not everybody and their uncle.

~~~
BiteCode_dev
Most popular FOSS project do not follow this model at all.

Linux, VLC, LibreOffice, Posgres, Firefox, Chrome, VSCode...

Sure, you can see part of the communication and have an input channel, but
unless you are part of the inner circle, or have some influence over it, you
won't be able to see everything, weigh in, vote or determine anything.

Which is sane: the number of competent people is limited. The ones inside the
circle can't spend their time fighting with the debate from outside. They have
to get a way to filter information, take decision and act.

People stating differently have either never been part of a successful big
project, or have been blind by the discourse that their project is, while in
fact, there is an informal inner circle despite their institution stating
otherwise.

It's like when you meet a "leaderless" group. If it's a small group, it works.
If it's a big group, either it doesn't, or an informal hierarchy with leaders
exist but nobody acknowledge it out of ignorance or idealism.

~~~
cipherboy
> Most popular FOSS project do not follow this model at all.

Most don't explicitly, but...

> Sure, you can see part of the communication and have an input channel, but
> unless you are part of the inner circle, or have some influence over it, you
> won't be able to see everything, weigh in, vote or determine anything.

Isn't mutually exclusive from open decision making.

Red Hat formalized and opened up our approach to this problem [0]. We actually
use it, too.

As another sibling of your said ('gwd):

> Everyone being able to participate isn't the same as everyone having
> identical influence.

In particular, most anyone has an avenue to participate, but that doesn't mean
everyone is involved in explicitly making the final decision.

The examples of use aren't complete in that repo. Fedora is currently in the
process of using it for the Git Forge selection process, Red Hat used parts of
it at various times in our logo process [1]. And I'm sure there's other uses
I'm missing.

The logo process is probably the best example: for numerous reasons (trademark
law, ...), 12k employees community designing a new logo just wouldn't work.
There'd necessarily be cohesion in the final product. So we were given input
at various stages (what do you think of X, Y or Z... polls, open meetings, &c)
and from all of that feedback, the designers formed the logo. Was it a perfect
process? Nah. But you definitely say you got input into it.

And yes, I'm a 'hatter.

[0]: [https://github.com/red-hat-people-team/open-decision-
framewo...](https://github.com/red-hat-people-team/open-decision-framework)
[1]: [https://www.redhat.com/en/about/our-brand/open-brand-
project](https://www.redhat.com/en/about/our-brand/open-brand-project)

------
rikroots
I've never managed to reach Stage 3. Nobody has ever shown any interest in
contributing to my GitHub project.

Still undecided whether this is a Bad Thing or a Good Thing.

\- Bad Thing: either the code base is too messy, or too complex, or too niche,
or too pointless, or I am a terrible communicator/promoter of my project.

\- Good Thing: I can do whatever I like with my project, and nobody is around
to argue with me about it!

~~~
mikekchar
Engagement is something that's required for contribution. For example, I would
never contribute to your project because I don't even know it exists :-) Even
if I did, I've got little reason to do anything other than use the result.

Occasionally people stumble across projects. I had a very long running project
to help myself learn Japanese. I had about 1000 users at one point that
stumbled across my project randomly on the site where I hosted it. But I never
had any more than that because I never put any effort into engagement
(although, I think my documentation was actually pretty impressive, for a
programmer ;-) ).

I think just having a project is not really enough. You need to create a
reason for others to reach out to you. A conversation is a bit like a game of
catch. In order for someone to catch the ball, you have to throw it first.
I've been streaming development of the game I'm working on and I've been
really surprised by the response. I've got more contributions in the short
time I've been doing that than I've ever gotten on my other projects. I think
the key is that having already started the conversation in the chat of the
stream, it's easy for people to get invested and to contribute. I think there
are other ways to start that conversation, but I think it's fairly tricky.
Possibly having a blog would be another way. Once you get 1 or 2 people
responding with comments, you can engage them and then others will join in. In
the old days, that's what happened with mailing lists.

~~~
rikroots
Sorry I've only just noticed your comment now. This is all good advice.

Getting the conversation going is key. It's something I've failed to do - to
the point where I don't bother about it much anymore.

For example: I didn't add a link to my library in my comment, so nobody knows
what library I'm talking about. I've already spammed the link in other
comments and "Show HN" posts with very little feedback, so I'm past the point
of seeing HN as a venue for promoting it, instead visiting daily to check out
other people's posts and comments.

I like to think that I'm a good example to others on how NOT to promote a
project.

------
andrepd
"Open source" is a specific term with a specific meaning. These points are not
it, and "open source" is not a scale of openness.

Also factual errors:

> _You no longer control this software. If someone makes a bunch of money off
> it it then you can’t complain. If someone uses it to build bombs then you
> also can’t complain._

You can perfectly use GPL, for instance, which forces derivative works,
commercial or not, to be released under the same license.

~~~
josteink
Except when used in a SaaS. GPL won’t give you any control there.

~~~
bouke
Then there’s still Affero GPL (AGPL).

------
RcouF1uZ4gsC
Sometimes there is a stage 8, Burial. The software becomes part of the Apache
foundation, and while people know about it, no one actually uses it for
anything new.

------
phkahler
Consider the case where software remains proprietary. Those more intangible
benefits will never come about. The software will be developed under a product
manager with feedback only from existing customers. It will be developmentally
trapped in a bubble on many levels.

On the other hand, paying developers is easier with proprietary software. Also
profit. If software is your product keep it closed. If software is part of
your infrastructure consider opening it, or using something that already is
open.

------
lcall
Could another stage (or dimension or set of sub-stages on the stages when
people start using the tool) be to determine a sustainable business model,
maybe ranging from "I will just work on it as I have time, because I like it",
to "enough of a team effort to be sustainable", vs. choosing from some menu of
revenue-generating business models and/or organization types to provide
income?

Maybe that's two related things: org types and financial models.

------
antoineMoPa
There is another model:

\- Write some software and share it in 1970

\- Now everyone is using it without knowing it

------
sebazzz
There is one stage missing: Where the software becomes closed or at least
doesn't become somewhat closed. This is what the .NET libraries DocX, Fody and
EPPlus have followed.

