Seven Stages of Open Software
coiled.io
coiled.io
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.
Perfect analogy. Mobile phone operators are doing exactly that in the country I live in and it annoys the hell out of me.
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.
Just because you have open source doesn't mean you are Open Source.
I might have misunderstood what this is
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.
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.
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... [1]: https://www.redhat.com/en/about/our-brand/open-brand-project
Everyone being able to participate isn't the same as everyone having identical influence. In my community, anyone and their uncle can chime in on discussions on our mailing list; and even to chime in on each and every single patch that's proposed. If what my uncle writes makes sense to people, he'll probably persuade people and have an influence. But if he's just expressing his personal preference, he won't gain much traction unless he becomes a regular contributor.
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!
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.
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.
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.
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.
Maybe that's two related things: org types and financial models.
- Write some software and share it in 1970
- Now everyone is using it without knowing it