...My contemplation lies in finding a way to allow the source to be open to bring benefits you just mentioned, but at the same time prevent commercialization of the technology beyond Nexus in order to benefit the Nexus community as a whole.[/size]
^I think you are taking a big gamble that you are protecting the project or community from commercialization of the technology. There is a possibility that open-sourcing the project would bring in talented developers who are curious to learn from you and they could provide valuable feedback analyzing the source code, help solve many of these larger problems, perhaps even start developing alpha applications for the LLL and thus helping to improve the protocol. If people decide to fork Nexus, they will still have to keep up with you in terms of development and the strength of the community. 2. Can you clarify what parts of the protocol will be open-sourced and what will be closed-sourced? You say you will be licensing the LLL. How is it possible to open-source Nexus Core and decentralize it while maintaining control over essential parts of the protocol? - The LLL is a template library I should begin by clarifying, so components patented under Nexus Core such as generate protocols or databases from the templates will be licensed according to their uses. This means that anything encapsulated in Nexus Core will be owned by the community of Nexus, or Niro holders. I want the technology developed for our space to remain first and foremost beneficial to Nexus, and secondary beneficial to the Internet. The LLL will include many inherited templates such as a SQL plugin for LLD and LLP, so forth that will be licensed to other areas of the internet to bring value back into Nexus.
^If there are ways to utilize the Nexus blockchain in order to solve computational issues through decentralized computing power, well that would be useful indeed. I think that developing an interface into the protocol for applications is good. What about creating a limited number of "licenses" that can be purchased in the protocol by burning NIRO or creating a sort of "proof-of-stake licensing" within the protocol. For example and I know you are against centralization, but what if you could have both. What if in order to access or use the LLL you must have a certain balance of NIRO and are running a staking node that meets a certain threshold or criteria. I am wondering if there is a way to create some type of scarcity of licenses in the protocol and to decentralize their issuance, or to allow some form of centralization within the protocol that allows for advanced features to be implemented based upon staked interest.
Let's look at DASH for a second just to realize the 'potential benefits' of masternodes. I am very aware of the downsides to masternodes. I am suggesting that masternodes have access to additional feature sets within the protocol.3. Here's the main problem that I see right now: It looks like part of Nexus will be centralized and closed-source, and that in turn makes the protocol dependent upon one single person, you, in order to be built on by outside developers. - I agree with you, and recall this has been one of your initial concerns with the fact being that I am the sole developer. Keep in mind this is a temporary situation, more developers can flow into the project if any decide to dedicate their time, which currently would be in their investment. If they were to require a contract, this will require more funding to be generated to cover these extra costs, which would require more time from me to produce these funds through my contracting business. I am an advocate of decentralization and trust less systems, the problem in this current circumstance is that the industry as it stands is not a trust less system. It is a woven fabric of private groups that have more influence over the industry than general users, which means that we have to find those we can trust in order to be sure we are making safe investments. If you have any ideas on how to bridge this deficiency or by possibility have any other insights I am missing, please do share.
^Adding additional features to the protocol by outside developers requires the ability to test different parameters in the protocol. You cannot possibly test all the possible areas of investigation and you only have enough eyes. I want to see hundreds of eyes that are able to contribute to the source code.
I think the priority should be finding a way to open-source the entire protocol while creating advanced feature sets for those in the community with a large stake. If stakeholders have a tangible reason to push development, they will do so, but monetary inflation through Proof-of-stake is not the only means to rewarding stakeholders in the protocol.
There should be more than financial compensation for stakeholding. There should also be compensation in the form of lucrative access to the LLL by operating a larger staking node.
4. Can you also provide us with a theoretical use case for the LLL in which someone would want to pay to use it? - MySQL databases are limited even with sophisticated caching to about 2-3k requests per second. A website could simply utilize the LLD and LLP with a SQL template to increase their computational capabilities while requiring less hardware. This would streamline into their system if all SQL commands are honored in this template, which would lower overhead of the business and make the licensing of using such a system more profitable to the business then using conventional MySQL systems. This would also stand true with new services built with the LLL from the ground up. This can be seen similar to licensing costs for cPanel and other internet based technologies that bring more profit than their costs.
^By requiring a masternode for the function of the LLL, you would create a semi-centralized but very practical solution for integration into business applications by creating scarcity and by combining node proximity with decentralized security. Since the blockchain would securely store the hashed data from the databases, if a node went down it would not mean that all of the data was lost. A trail of important records could be maintained. The important records of the data would be saved right up to the last block in a decentralized fashion.