They propose “privatize Bitcoin Core” limiting access to the non -technical public
-
Bishop believes that the public can spread misinformation around Bitcoin Core.
-
The initiative arises against the number of interventions of people not involved in development.
Bryan Bishop, known in the community as @kanzure, proposed on the Bitcoin-Dev post list restricted public participation in the discussions of the Bitcoin Core project.
This is detailed by Bitcoin Optch Bulletin #359 and is seen in the Bitcoin developer post list in a June 10 post.
Arguments in favor of the privatization of Bitcoin Core: I believe that reflection is essential for curiosity, understanding, improvement and progress. The recent activity in the Github account of Bitcoin Core has given me the opportunity to reassess my convictions on the development of open source software in Github.
Bryan Bishop, Bitcoin developer.
Bishop comments that the initiative arises from The growing number of interventions of people not involved In developmentwhose participation can generate noise and divert the focus of technical debates, or create misinformation.
Basically, there is a recurring pattern of people who do not contribute (sometimes they are not even developers) that are interference in an online forum mainly for those who collaborate in Bitcoin Core to work together in whatever they are doing. This usually causes problems such as the loss of valuable time of users, the creation of artificial controversies, misinformation, etc.
Bryan Bishop, Bitcoin developer.
Comments that the situation is serious in Github, a platform that according to the does not have good moderation controls And it was only created according to “a very limited concept of open source development.”
The developer argues that limiting public access to discussions could improve efficiency, allowing active developers to concentrate on critical issues such as scalability, privacy or protocol safety.
He comments that he would like to defend “the privatization of Bitcoin Core’s software development,” and make it an exclusive gitlab for members that would work as follows:
Incidents and extraction requests would be private and would not be subject to public hyperlinks. Anyone could register or request access. Who manages the site or repository would be responsible for configuration, accommodation, configuration, moderation, access control, etc. The software development would continue under the same license. The new incidents, comments and code review comments could be subject to a specific license, such as CC0, of public domain or some other, possibly with PGP signature to guarantee compliance if we care about the comments license. Extraction requests can be published in any number of repositories, public or private, as wisped by any collaborator, except, of course, in case an infraction of the standards or spam occurs in the respective publication systems.
Bryan Bishop, Bitcoin developer.
The proposal is not exempt from controversy. Restrict public access could discourage the participation of new developers, who usually start observing, learning, discussing and contributing to these open spaces.
In addition, such a measure could be perceived as a step against transparency and the decentralized spirit that characterizes Bitcoin, although on the other hand it can produce benefits around the management and discussion of the improvements of the main client of nodes of the network.
