Thank you Ben for getting the discussion started. I will keep a running update of the percentage of votes on https://nubits.com/about/source-code until it reaches the over 50% of blocks and sharedays required to pass.
Playing with assistant bot
History of the Nu Network (Feedback Please)
Exco.in has opened a market for trading BTC/NSR
[Passed] Motion to Make the Nu Source Code Available
**Draft** Motion to Adopt An Open-Source License
**Draft** Motion to Adopt An Open-Source License
[Passed] Motion to Make the Nu Source Code Available
A well written start to the conversation, Thanks Ben.
I still need to think about the pros and cons of open sourcing the code at the present time but it’s definitely something that needs input and community involvement.
I’m not sure I’m quite ready to begin voting for open-source yet, but I also know that at some point in the future we should be.
For the purposes of starting off the discussion, here’s a very rudimentary benefits / drawbacks list
- Increasing trust in our product and conforming to existing cryptocommunity expectations of open-source
- Increasing the ease with which independent developers can create new innovations in the Nu ecosystem (a mobile wallet or a messaging system, for example)
- Increasing the ease with which independent developers can contribute to the Nu source code
- Duplication is perhaps even more of a danger than with traditional crypto-assets like Bitcoin and Peercoin. With Peercoin for example, when a developer forked the code to create their own clone but held 3% for a “pre-mine”, the backlash from the broader community was intense and immediate. This is because of the expectations that a transactional unit is distributed as fairly as possible. With our model, the transactional (NuBits) and speculative (NuShares) units are properly separated. This means that a developer might now be able to hold 40%, 50%, 70%, or even higher of a hypothetical X-Shares fork with no public backlash. For someone wondering whether to build onto the Nu ecosystem or to fork their own project, the potential profitability is now much higher in the second option. This may hurt our ability to attract developers onto the Nu project.
- Forks of Nu will almost certainly fail in many cases. This is because of the high level of expertise required to develop and maintain the NuBot, manage liquidity operations, and facilitate voting. When a forked Nu clone fails it will cast doubt on our own design. In a way, we become responsible for the operations of groups that will almost invariably have less expertise and experience with the Nu design.
I tend to feel like now that the white paper is public, developers will be trying to copy what we’ve done anyway. There are a lot of talented people out there who would probably be interested in joining us as a contributor, rather than a competitor, but by staying closed source, we are forcing them into the competitor bucket. This could ultimately be a more dangerous prospect.
This was the subject of a discussion thread back in September. Was it removed for some reason?
I get this when I click on the link:
“The page you requested doesn’t exist or is private.”
I’ll review the content to see if there is any reason it should remain restricted. It was probably caught up in the cleanup after release.
I would be interested in hearing ways staying closed source would hurt us in the short term, say 3 months, while we get the Android wallet and burn option sorted.
I fully expect that this will take some time to pass. Until we have a formal motion that can be voted on, we cannot begin to move forward with any changes.
I think there’s far more benefit to going open source than there is in staying closed.
Translations. Open source projects are allowed free use on websites such as transifex.com and getlocalization.com. We want Nu to be an easy to use application for anyone and that means localizing the client to their preferred language. Right now the client is using outdated or butchered translations from the Peercoin base. This is terrible for growth, and as NuBits becomes more known in mainstream crypto circles we should do our best to remove any impediments for adoption. Our target audience is the entire world. Not just English speakers.
Trust. We want people to trust the software. Bitcoin is trusted because it’s open, uses signed binaries, and has discussions about technical direction of the software on publicly accessible mediums. We want to encourage the same trust in Nu. The only way compete in that area is to follow suit.
Developers. Developers. Developers. We need them. Going open source is how you get them. Microsoft has recently open sourced .NET in a move that significantly shows that times are changing. If you want developers involved in your ecosystem you need to make the code available to them. NuBits is extremely attractive in that we’re not just another clone coin. We have tools in place (such as the motion system we’re using here) to allow anyone with a computer to help drive NuBits towards a successful future. Whether that means donating their time to assist in code audits, bug fixes, features additions, or any other tasks - the first step to growing our developer community is by embracing the FOSS model.
Which leads me into my next point. Ancillary services. We’ve been terribly lucky to have so many people from the Peercoin community join us. Without Johny adapting his Peercoin block explorer for Nu much of what we already have would not be possible. We could not be listed on coinmarketcap.com and development testing would be negatively impacted as well . By going open source we enable the developers we attract to create an entire ecosystem of tools and services to complement Nu. The coinomi.com app developer approached us with interest to add NuBits into their wallet. He was met by resistance because we’re closed source. By embracing the open source development community we allow creative engineers and thinkers to not only help NuBits, but also help themselves by enabling them to develop complementary services without gatekeepers. NuBippy was an awesome tool released by @woolly_sammoth immediately after launch. This was only possible because he worked closely with someone who had access to the source code. Thanks to Bitcoin and all the other altcoins much of what is out there simply would need to be adapted. It would probably be much faster for NuBits services to pop up because so many tools and services already exist within the cryptocurrency ecosystem.
We need help. If we want NuBits to become what we think it can be with all the grand ideas discussed on this forum it will take everything I’ve discussed. It will take an application and services that can that be used by anyone regardless of their preferred language. It will take developers that feel they can impact the future of the network by understanding how it works, which allows them to contribute their expertise and ideas. It will take those developers improvements and ancillary applications to make NuBits easier to use and more widely distributed. We cannot achieve our goals by acting as a private company.
It’s the right thing to do. Bitcoin open source software allowed for Peercoin to exist. Peercoin open source software allowed for Peershares. Peershares allowed for Nu. If people fork Nu it shows that what we’ve created is desirable.
I don’t see drawbacks to going open source. I see new challenges. By opening the source we allow more people to help us tackle these challenges. Once the source is released it does not mean a door will open to a land of green grass and rainbows with unicorns that puke your favorite ice cream. We will have to continue to prove that NuNet is a worthwhile solution for consumers, businesses, and developers to invest time and money into.
I’m confident that our solution, team, brand, and community will allow for that to happen. I’ll probably have more thoughts on the issue as this discussion evolves but I wanted to jot down a few points that immediately came to mind.
i agree. open source is the best way. even if other nubits clones exist there have to use a system like peershares if not peershares itself. also there could be a healthy competition between nubit clones in park and shares area. more people will come aware of “stable” coins and more great minds ofcourse. it could be the start or the real deal
If Nu is based on Peershares then the common part of Nu is already open source. Is it difficult to put most part of Nu to Peershares and only leave some key functions close source?
Having to maintain two code bases in parallel, while evolving them, is a major burden.
Context shifting will slow down development and mistakes will inevitably be made.
I thought Peershares is upstream of Nu so that if properly refactored usually the devs only need to change either in Peershares or in Nu ?
It is, but it still requires back porting of the refactored code. I’m not saying it isn’t possible, just that it is an extra effort if the requirement is to sanitize portions of the code before pushing it upstream.
@CoinGame Thank you for taking the time to write out your thoughts. You’ve raised some excellent points that I agree with.
What is the prevailing opinion among Nu core developers and the QA team about open-sourcing? I am inclined to support the majority consensus of that group, as they will have the best idea of challenges and opportunities that are in front of us.
However, I did want to touch on your statement
Do you not agree with the two risks I identified in my post above? I’m certain that other major projects have noticed the trading volume we’ve managed in our first two months and made a mental note that the Nu design would be worth replicating, rather than contributing to.
I think imitation is flattering and competition is good. Peercoin still imports lots of code from the Bitcoin repo. If others fork our code and build something better we can merge it into our system. If they choose to remain closed source they’ll have the same problems as us right now. I see it as an ongoing challenge. There is far greater risk in shutting out developers from our project. Stable crypo-assets will become the new standard eventually, and we want those developers to help us in building Nu related projects. Open sourcing the code invites them to the table.
If others fail trying to use our design while we succeed it speaks volumes to the implementation of our solution, the team, the brand, and our community. Over 500 altcoins exist and more than half of which bring nothing innovative to the table. They have not hurt Bitcoin very much. There are plenty of failures and clones to list out. In fact I would say their failures have strengthened Bitcoin’s brand.
Had to think about this for a while and good discussion here BTW. I’m still on the fence on the short term, but may jump in shortly especially because of the reasons @coingame quoted in his post above.
The reason which stops me from voting now is the risk of a copycat with a lot of money. Therefore I’m still a proponent of publishing deliberately changed code, so it can’t be compiled and turned to live by each kid with a bit of time. This can be just a copy frozen in time taken at a certain date (fork) while further development continues closed source, which mitigates maintaining two libraries ongoing for the devs but opens it up for development. Full open sourcing can be postponed a bit longer e.g. 2-3 months till the community and product have further matured.
TL ; DR not yet. I believe we should include in the motion a checklist of things that must be completed before release the source, or we risk harming the project.
Here is why :
Personally, I will vote for scheduled open source. IMHO it should be properly planned together with the marketing road map.
I believe we now have some momentum, but we need some extra time to build other things : merchant adoption, bot stability, more custodians, more tools.
At the moment, with 5 custodians, 0 merchant adoption, no mobile app, no Web stats, little to no tools and one block Explorer, we risk to be overtaken quickly by any well funded organization with a community.
I don’t need to quote but there are probably literally hundreds of people waiting for this, since it’s a huge opportunity. It’s not another altcoin, is a possible Nobel prize solution for many of digital currency problems.
99% of crypto community didn’t had the chance to try NuBits yet. We haven’t been covered by any major newspaper or magazine. six months after releasing the code there will be several 1usd coins. Which one was NuBits? Ah, the first one, but who cares. I wasn’t there to try that. People will be confused and will go with the one that paid a review on coin desk.
We have only one product and we are not quite ready for a second. I am still dreaming of inflation adjusted NuBits. I don’t want someone else doing it from day one using 8 months of our work.
Last but not least, I want to hear Jordan. Remember we are a public company sort of, and that we received an initial investment. Without that we will not be here discussing this, so I want to make sure our investor are happy with it.
This is my opinion and people can or cannot share my view.
I would personally write a open source motion where we draw a checklist that must be respected before opening it, and some of the points of the list you can already find above.
Edit : also, being closed source did not created visible trust problems so far. Mobile wallet is one and we handled it probably better than just leave repository open and tell people ‘read the code’. We guided the dev through it.
We did not have many people waiting for the code either, or they have been very silent. Are there many tweets about us being not trusted because of that? I am not following social media lately.
And, as a side note, do not think that open source will bring a lot of free volunteers. (nubot is open source did not received a single comment on it, not to mention PR , and it features API wrappers that normally are paid in the order of thousands $) .
How do we plan to manage paid developer together with free contributors? We don’t have a bounty platform yet.
Moreover, which open source government model do we want to adopt? If we get to the point where we have developers, we need to define processes (NIP?) . Those will probably take time and resources.