Funny, I wrote an article on how I am slowly coming around to the idea of "Open-Core", where contributions can only be given by verified members of the public to your specific project and that the...
Funny, I wrote an article on how I am slowly coming around to the idea of "Open-Core", where contributions can only be given by verified members of the public to your specific project and that the source code is public.
I wrote my ramble of thoughts here on mastodon. It's a bit longer than most posts, but then again I kind of use the space as a tumblog before I finalize and move them to my main blog. it's not a 'tweet-storm' or thread, its one post that's about 900 words.
In a way, it's a response to this post, so read it as that if you will.
I'm kinda in the camp that open core is better than proprietary, but still falls for those same traps that source-available does. Namely, any open replication of closed addons for enterprise will...
I'm kinda in the camp that open core is better than proprietary, but still falls for those same traps that source-available does.
Namely, any open replication of closed addons for enterprise will almost always be rejected for obvious reasons. I want a simple enforced merge approval in Gitlab. Good luck getting that approved in the community edition because that undermines their commercialized addition.
It seems like that's what forks are for, when there's a subset of the community that wants to go in a different direction? I see community governance as somewhat distinct from the software...
It seems like that's what forks are for, when there's a subset of the community that wants to go in a different direction?
I see community governance as somewhat distinct from the software licenses, which aren't about who gets commit access or what they'll accept.
I am talking about governance more than licensing. It's just that a lot of these companies that are trying to divert from the open/copyleft licenses are trying to exert that degree of control over...
I am talking about governance more than licensing. It's just that a lot of these companies that are trying to divert from the open/copyleft licenses are trying to exert that degree of control over governance through their licensing, and subsequently through tight control over their main projects. Specifically they're trying to maintain exclusive control over monetization of their code, which is directly at-odds with maintaining and distributing forks. Hence the main point of the article: You need to distinguish what you're doing quite heavily from the open source model that already exist, rather than trying to reap the benefits without coping with the downsides that come with those benefits. Gitlab is a better player than most, since they're under MIT licensing (mostly), but I'm specifically thinking about licenses like the BSL. I'm just more familiar with their product, so I used them as an example.
The source-available licenses are harder to fork, and even harder to maintain, especially the larger the codebase. If I wanna add this feature to Gitlab, sure I could fork then try to maintain parity with the main project over time, but we see projects like this fail again, again, and again unless the fork has as many or more resources than the original.
It's exponentially easier to just get something patched in upstream, which is half the reason Linux has been successful as it has.
That sounds like a nightmare and a half, but I imagine that you are thinking in an environment that already solved the obvious exploits for this, no? on the topic of governance, I can see a decent...
I want a simple forced merge approval in Gitlab.
That sounds like a nightmare and a half, but I imagine that you are thinking in an environment that already solved the obvious exploits for this, no?
on the topic of governance, I can see a decent middle ground if there was a more empirical system that can also grant elevated roles to certain modules of code. Like, if you're in the Linux kernal and you made a dozen big contributions to the networking module, you can get some local rights to review other's commits and get a faster track to let you push into that module. You can still be reverted and yelled at by Torvald, but you get to earn that trust without necessarily needing to play politics to get a person to do it for you.
Of course, "Big" contributions up there is doing a herculean amount of lifting. Software companies have tried for decades to measure "productivity" and failed in so many ways (mostly because these measures need to appeal to product people instead of actual impact technical quality, nor consumer value, but I digress). Regardless of my feelings, it is hard to properly measure.
This is the feature in question. I probably could have worded it better. It allows you to setup detailed rules about MR approval. Like having a team leader click the 'approve MR' without actually...
That sounds like a nightmare and a half, but I imagine that you are thinking in an environment that already solved the obvious exploits for this, no?
This is the feature in question. I probably could have worded it better. It allows you to setup detailed rules about MR approval. Like having a team leader click the 'approve MR' without actually doing the merge. Its a workflow control mechanism, and in free versions it's a cosmetic button that doesn't halt workflow.
earn that trust without necessarily needing to play politics to get a person to do it for you.
And that's how you get those nightmare scenarios where someone gets just enough trust to start quietly injecting security holes, like what happened with XZ. Trust shouldn't be automated.
I should highlight that what "trust" is, while ideally empirical, is still based on the repo's values. It's not like more commits or more lines of code = more trust. It'd be a combination of...
Trust shouldn't be automated.
I should highlight that what "trust" is, while ideally empirical, is still based on the repo's values. It's not like more commits or more lines of code = more trust. It'd be a combination of factors.
but sure. The "automated" way is 90% of how stackoverflow does it, and we know how that ends. A competition that has users self sabatoge the site and beg for upvotes. That's partially why I'd propose it on a module by module basis, to minimize damage. But I don't think Github even has a "partial contributor" system like that to begin with, though.
The malicious actor you talk about (read the story, absolutely crazy) would happen regardless with a motivated enough actor, they'd just play different games to earn it. I do agree at the end of the day that trust can be revoked at anytime for such cases. Which can let personal politics pollute the discuss, but it's inevitable with a human structure (Otherwise people would just game the system and evil is a transaction instead of a proper punishment).
I feel like the title does a disservice to the content of the article itself. Because at its core it effectively does a good job of: Summarizing some of the success and issues around open source....
I feel like the title does a disservice to the content of the article itself. Because at its core it effectively does a good job of:
Summarizing some of the success and issues around open source.
The desire of some developers to explore other options and models of software development.
Which finally folds into the request that developers who do explore other models don't muddy the waters around the meaning of "open source".
Even the creation of "open source" phrase itself was a way to distance "code available" from the user-empowerment nature of the copyleft/free software movement.
Even the creation of "open source" phrase itself was a way to distance "code available" from the user-empowerment nature of the copyleft/free software movement.
Funny, I wrote an article on how I am slowly coming around to the idea of "Open-Core", where contributions can only be given by verified members of the public to your specific project and that the source code is public.
I wrote my ramble of thoughts here on mastodon. It's a bit longer than most posts, but then again I kind of use the space as a tumblog before I finalize and move them to my main blog. it's not a 'tweet-storm' or thread, its one post that's about 900 words.
In a way, it's a response to this post, so read it as that if you will.
I'm kinda in the camp that open core is better than proprietary, but still falls for those same traps that source-available does.
Namely, any open replication of closed addons for enterprise will almost always be rejected for obvious reasons. I want a simple enforced merge approval in Gitlab. Good luck getting that approved in the community edition because that undermines their commercialized addition.
It seems like that's what forks are for, when there's a subset of the community that wants to go in a different direction?
I see community governance as somewhat distinct from the software licenses, which aren't about who gets commit access or what they'll accept.
I am talking about governance more than licensing. It's just that a lot of these companies that are trying to divert from the open/copyleft licenses are trying to exert that degree of control over governance through their licensing, and subsequently through tight control over their main projects. Specifically they're trying to maintain exclusive control over monetization of their code, which is directly at-odds with maintaining and distributing forks. Hence the main point of the article: You need to distinguish what you're doing quite heavily from the open source model that already exist, rather than trying to reap the benefits without coping with the downsides that come with those benefits. Gitlab is a better player than most, since they're under MIT licensing (mostly), but I'm specifically thinking about licenses like the BSL. I'm just more familiar with their product, so I used them as an example.
The source-available licenses are harder to fork, and even harder to maintain, especially the larger the codebase. If I wanna add this feature to Gitlab, sure I could fork then try to maintain parity with the main project over time, but we see projects like this fail again, again, and again unless the fork has as many or more resources than the original.
It's exponentially easier to just get something patched in upstream, which is half the reason Linux has been successful as it has.
That sounds like a nightmare and a half, but I imagine that you are thinking in an environment that already solved the obvious exploits for this, no?
on the topic of governance, I can see a decent middle ground if there was a more empirical system that can also grant elevated roles to certain modules of code. Like, if you're in the Linux kernal and you made a dozen big contributions to the networking module, you can get some local rights to review other's commits and get a faster track to let you push into that module. You can still be reverted and yelled at by Torvald, but you get to earn that trust without necessarily needing to play politics to get a person to do it for you.
Of course, "Big" contributions up there is doing a herculean amount of lifting. Software companies have tried for decades to measure "productivity" and failed in so many ways (mostly because these measures need to appeal to product people instead of actual impact technical quality, nor consumer value, but I digress). Regardless of my feelings, it is hard to properly measure.
This is the feature in question. I probably could have worded it better. It allows you to setup detailed rules about MR approval. Like having a team leader click the 'approve MR' without actually doing the merge. Its a workflow control mechanism, and in free versions it's a cosmetic button that doesn't halt workflow.
And that's how you get those nightmare scenarios where someone gets just enough trust to start quietly injecting security holes, like what happened with XZ. Trust shouldn't be automated.
I should highlight that what "trust" is, while ideally empirical, is still based on the repo's values. It's not like more commits or more lines of code = more trust. It'd be a combination of factors.
but sure. The "automated" way is 90% of how stackoverflow does it, and we know how that ends. A competition that has users self sabatoge the site and beg for upvotes. That's partially why I'd propose it on a module by module basis, to minimize damage. But I don't think Github even has a "partial contributor" system like that to begin with, though.
The malicious actor you talk about (read the story, absolutely crazy) would happen regardless with a motivated enough actor, they'd just play different games to earn it. I do agree at the end of the day that trust can be revoked at anytime for such cases. Which can let personal politics pollute the discuss, but it's inevitable with a human structure (Otherwise people would just game the system and evil is a transaction instead of a proper punishment).
I feel like the title does a disservice to the content of the article itself. Because at its core it effectively does a good job of:
Even the creation of "open source" phrase itself was a way to distance "code available" from the user-empowerment nature of the copyleft/free software movement.
Yes, I think it’s a pretty reasonable article.