Private branches for public repositories

erkinalp commented 8 years ago

Some open source projects have companion proprietary projects sharing lots of code and issues. Along with appropriate access control in issues and PRs, this will help deduplication.

ma-sadeghi commented 3 years ago

+1

balupton commented 3 years ago

Another rationale for this that hasn't been mentioned above, is keeping public discovery of repositories (name, description, topics, stars, watching, issues), yet keeping access to source code private. People with access to source code, should still have the private source code show up in system-wide github searches - those who don't have access to such source-code should not have the code show up, or have the result show up but be locked away behind the access wall.

Such use cases for this includes incentive mechanisms to protect the source code from exploitation. Such as access to source code only if you sign a contract/code-of-conduct/license/nda/cla/or-whatever, or access to source code only if you are a sponsor. This could empower fairness again from the open-and-be-exploited dynamic of current FLOSS, to open-to-those-who-won't-exploit-us. Such examples of common current exploitation are the plagiarising of code, or the benefit of use without return, both of which exploits the labour of the original producer, often for the most popular plagiariser who monopolises utility to monopolise attention to monopolise sponsorship.

More details on this model and follow-up discussion here: https://forum.artlessdevices.com/t/coalition-for-access/90?u=balupton

Such a model wouldn't really require the granularity of branch access protection, but merely just source code access protection.

If such was implemented, I would swap all of the @bevry projects to source for sponsorship model, to disincentivise the plagarisation that has affected our projects, and move certain larger projects which are currently private repos, to public repos under a source for code-of-conduct agreement.

This should also enable the goals of certain political advocates, which like it or hate it, is becoming an ever increasing faction of FLOSS development, due to the incentives and disincentives involved.

I'm dubbing such a model privileged-source, rather than open-source (open to absolutely everyone, even those who don't play fair), and closed-source (open to only the walls of employees).

For all the +1's above, just click the 👍 in the OP or the subscribe button in the right hand column, so you don't fill the inboxes of everyone subscribed with your superfluous agreement, wasting their time.

ehorodyski commented 3 years ago

I'd love this feature. I plan on writing some projects that would have a base free OSS main branch, where people can fork the public portion of the code, but additional features would be sold -- therefore private.

I'm not going to make a living on what I have planned, but would like something more concrete than donations for people who want to support my projects to get

erkinalp commented 3 years ago

In fact, the most prominent user would be Microsoft itself, with https://github.com/Microsoft/Windows repository.

aliemo commented 3 years ago

This feature is very practical and essential. I also have some academic and industrial projects that part of of them are public and part of them are private. for example, an academic project that provides material for programming assignments. any student needs to fork the project, but requires a private branch to advance solutions. at the moment we have to fork the project twice (public and private).