Reply to Dragon’s (@authorpendragon) Minds.com Article

After reading Dragon’s article about how to be a useful user on Minds (URL provided below) and following the corresponding comments, I would like to contribute my own thoughts about the various subjects that were explored within the original article.

Whilst I thought that the original article was interesting and fairly informative, I did see some major issues with the content that is being expressed.

The first of these issues relates to version numbers. Within the original article, Dragon suggested that the site has completed the Beta construction phase. Anybody that has been involved in any form of software development (especially open source software development) would have realised that this form of versioning would follow the timeline of Alpha release, Beta release, Release Candidate (RC) and then the Stable release.

Examining the GitHub repositories, there are three releases. Two of which are developers preview versions that where published in August and October 2016 (with the third being the current version), I have to wonder about why the Alpha and Beta releases where not included within the previous release section of the GitHub repositories, whilst the earlier developer previews are included.

Whilst it is correct that we are in a “testnet” phase, which allows the developers to explore and implement crypto tokens into the existing project (ie. framework), this “testnet” phase does not affect the overarching running of the current framework and could be considered as an extra feature of the services that are being offered by Minds Inc.

Considering that this is an open source project that is based on an idea of a “community-owned social network” (as described within the original Wefunder crowd sourcing investment page), it seems that the staff at Minds Inc. continuously add road blocks to the transparent and open development of the framework.

Generally, within the realm of software development, versioning usually consists of a numbering scheme (ie. versions 0.1, 0.2 etc. are considered as pre stable releases and version 1.0 is usually considered as the first stable release). Considering that there is no actual version numbers associated to the framework and the fact that bugs are still being fixed, the framework is yet to be considered as either an RC or stable version, therefore logically speaking, if the framework has not been released as either an RC or a stable version then the framework must be still within a Beta version.

Also, the developers and administration staff discuss the development of the framework within a closed source, proprietary service (ie. asana.com), in which they only accept a few users to interact with. Furthermore, the staff (after multiple requests by various members of the community) refuse to publicly publish any standard (human readable) changelog or roadmap documentation and only relay on vague public relation statements.

In any modern transparent open source project, the inclusion of at least a human readable changelog document is to be expected. Changelog documents usually provide users with a simple explanation of changes to the source code / framework and further demonstrates how the framework has changed between the release of subsequent versions. Whilst it is true that all modifications and additions to the source code is included within the commits section of the GitHub repositories, this section is fairly confusing for the average user; as well as not providing a simple, easy to understand list of changes.

The inclusion of changelog and roadmap documentation (as well as the implementation of a version numbering scheme) would allow the average user to view the changes between versions, the progression of the framework and an idea of what is to be expected within the following releases. This addition would also further promote the ideas of an open and transparent open source project, as well as providing further confidence to users that may want to contribute code, ideas and viewpoints to the progression of the framework.

Up until fairly recently, the staff members that were contributing to answering help and support enquiries were providing little to no explanation about some of the issues that were being asked within the help and support group, as well as not providing any information to follow up questions.

Recently, the support from the staff has improved within the help and support group. This has also been due to the support that has been contributed by some of the more seasoned users that have volunteered their expertise to providing continuous support for this group, as well as providing answers to various questions that have been asked by other users of this social media site. As an attempt to provide better help and support functionality, as well as to provide a more transparent and accountable environment, some of the more seasoned users are contributing to user facilitated bug tracking services and are also attempting to persuade staff members to move from the “gated” environment of the Asana service to open source services (including the use of Mantis Bug Tracking and Taiga project management services).

I agree with Dragon about how a “non censorship” social media platform raises ethical issues for not only developers and administrators but also for the entire community; I recognise that a site such as minds.com attracts multiple and contrasting viewpoints. I also welcome the inclusion of the “E” rating for content that includes explicit material, but it does concern me when I read that an article which explores issues surrounding free speech and open source ideas, also spins a narrative that there are “professional haters”, which tries to further denigrate users whom Dragon claims to be “misogynists”, “racists” and “social justice warriors”. Rather than trying to label users that may hold different views than the author, I would suggest that Dragon stop playing this form of petty partisan politics and should attempt to encourage free speech, alternative viewpoints and robust conversation.

Whilst the staff at Minds Inc. has work hard to achieve a reasonably good service, I am also concerned about Dragon’s narrative which tries to suggest that the developers are “wizards” and users do not understand how the site functions. I do agree that it would be great for more users to contribute not only to the development of the actual platform but also to support the other aspects of this site (such as providing advice and support to other users, reviewing the various legal issues and to support the long term open source, free speech and community activities that is being promoted by minds.com).

Considering that Minds Inc. is trying to promote the principles of open source. As demonstrated above, the company is attempting to deliberately ignore these actual ideals. I would also remind Dragon that if it wasn’t for the “grateful users”, this service would not be as popular as it already is (I doubt that Bill and John Ottman would continue with this project if it was not as well received by the users).

To conclude, I think that the staff at Minds Inc. has developed and managed a good, useful and well needed site. However, the staff needs to further uphold the principles of the open source ideals, as well as needing to push further for the transparent and openness of this open source based project.

References & Other Resources:
* Dragon (@authorpendragon) Original Article
* #MindsGaming (@mindsgaming) Follow-Up Article
* Wefunder Crowd Sourcing Page for Minds.com
* Mantis Bug Tracking
* Taiga Project Management
* Minds GitHub Repositories
* Technology and Open Source Blog