Development focus #6747
Replies: 7 comments 3 replies
-
|
Thanks for creating the post. When looking to decide where to focus development I think it is important to consider them in the context of the current opportunities and threats. Opportunities
Threats
For the short to medium term I think Bisq should focus it's development on things that strengthen the DAO. Those being continue to decentralize as much as possible and look to increase revenue by increasing the trade volume in bitcoin terms. I see having a strong DAO as; increased contributor and user participation, increased BSQ price, and increased BSQ market cap. I think these things would be by and large the result that come from an increase in trading volume and an improved user experience. Achieving a strong DAO should also help with one of Bisq's limitations, a lack of dev resources. I think one of the DAO's major strengths is the level of decentralization. So I have nothing to suggest to improve this other than I see it as something that should continue to take priority over platform development (a good example of this would be the decentralization of the burning man role). My thoughts regarding dev priorities that would increasing revenue the trade volume are: Address the issue that will be caused with spending longer periods in high fee environments
Address the issue that will be caused with treats to Bisq's XMR trade volume (other p2p platforms and coming increase in atomic swap usage) XMR trades generate 57% of Bisq's revenue but I do not think much if any percentage of dev resources go into developing specific improvements for XMR traders. I think Bisq should use more of it's resources to make improvements for XMR traders. This might bring with it new contributors.
Prioritize what protocols should be developed for addition to Bisq 2 based on the likely revenue they will generate There are lots of great protocols that could be added to Bisq 2 and I think it is important to evaluate them in terms of what will increase the revenue the most. Certain protocols might be technically great but will not have much adoption. Other protocols might not offer much in the way of innovation but will be used a lot. IMHO these should take priority. Long term goals would be to increase accessibility by having Bisq accessed via a mobile, or web app in a standalone decentralized manor. I think this is a long way off though and will be achieved with improvements overtime with technology rather than anything Bisq needs to focus on currently. |
Beta Was this translation helpful? Give feedback.
-
|
Onramping new devs is very difficult at Bisq. We have seen many devs coming by with a lot of enthusiasm, but dropping out shortly after. The codebase is not so easy to understand, that you give it to someone and expect that he will be able to implement a feature. Giving them some guidance and some areas they can work on would be essential because when you come to a new project, you probably dont see what's needed. And then there is the problem of misguided dev-effort as you pointed out. That hurts the project double, not only the money spend for little or nothing, but also the opportunity missed to have something important to be implemented. But to summarize it, I think you have hit the nail on the head concerning the problems why we don't have more devs and effectiveness in development. |
Beta Was this translation helpful? Give feedback.
-
|
Regaring protocols for Bisq 2. There have been discussions about a LN->Liquid->LN protocol based on a suggestion from Adam Back. I think that is the most feasible solution and the concept could be used also for XMR. Let me explain... 2 traders want to trade LN-BTC to fiat and use the Bisq Multisig protocol in the background.
So it is a chain of 3 trades/protocols.
The swaps are conceptually similar as atomic cross chain swaps, so they are to a very high degree secure and can be automated if there is enough liquidity from market makers. If liquidity would be a problem we could use a centralized provider like Bolz.exchange (but I think that is not needed). One can think of it like entering a casino and converting fiat to casino coins. Then one can use those coins for the "services" of the casino. Once done, they convert it back to fiat. Doing multisig in Monero (like Haveno is doing it) is very problematic as multisig in Monero is much more complicate as in Bitcoin and every tx needs quite some time before it can be used in the next transactions, so you cannot create a protocol based on chained transactions without long waiting time in between (I guess its 20-30 min as far I remember). So UX will suck and complexity is very high. My personal roadmap for protocols on Bisq 2 is:
BSQ swaps could be added at any moment, but I guess that's not the most pressing. If Bisq Easy turns out to work well the reputation based approach could be developed further for other currencies and more reputation sources. It could turn out to be a very flexible solution. But lets see first how it gets adopted by users. Beside the protocol development I see those dev areas as high prio:
On Bisq 2 there are a few open areas where we would need highly skilled and experienced devs:
There are a long list of open issues here: https://github.com/bisq-network/bisq2/issues but most will be covered by myself or @alvasw but we will not have the bandwidth for the larger tasks mentioned above. So if any new dev is interested in one of those they are welcome. I am aware that those are not trivial tasks and require a high level of experience and skill set. Here would be my summary a dev should bring when working at Bisq:
On Bisq 1 I do not see a large space for new devs. Work on Bisq 1 is difficult as the code base is highly complex and has quite some "wear" and it takes considerable time to get familiar with it. Areas where it might make sense are:
My 5 cents.... |
Beta Was this translation helpful? Give feedback.
-
Flexibility should be the key for Bisq2. Let's see how the cloning an offer feature works out, I'm very optimistic with it and I think it will generate higher volume, specially for payment methods with lower volume. These are the kind of features that make the difference, but I also understand it's been thought for a long time until you found a viable way to implement it that only looks easy in retrospective. |
Beta Was this translation helpful? Give feedback.
-
|
Yes in Bisq Easy one could trade anything to anything. But to stay focussed on the target user group of newbies who want to get into Bitcoin we decided to stick with Fiat/BTC in the UI. Adding more options (altcoin-fiat) would add friction and confusion to the user group we target. But sure later once we got some experience how its accepted by users we can consider to add for instance XMR-Fiat or BTC-altcoin.... |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the idea that, even if extending the Bisq Easy protocol for other asset pairs is simple code wise, it comes with a cost in terms of UX. Perhaps this cost can be reduced by keeping a UX path focused on Bitcoin that funnels users with little experience in the right way, but allows advanced users to step out of the "usual" path. |
Beta Was this translation helpful? Give feedback.
-
|
I suggest creating a small document with a list of tasks and link to it from the README file. We already have several good tasks for new contributors. Bisq 1 APIIMO we should focus too much on the Bisq 1 API anymore. I used to it to build few trading bots, and it's not well-designed. I have to admit that I ignored the API module when I fixed threading bugs in the desktop app. It was too cumbersome. The only reason to justify to invest more into the API is if someone is using it production. TestsI usually write the tests before implementing the code, and it's not a secret that I like tests. However, when @napoly upgraded JUnit, I had to look through most tests in Bisq 1. It's a mess and the existing tests are too concrete and make the implementation code worse. Little changes break the tests and make them useless. Focus for Bisq 1We should only work on things that benefit our users directly and fix bugs. Focus for Bisq 2Henrik's roadmap for protocols on Bisq 2:
|
Beta Was this translation helpful? Give feedback.
-
Yes you are one of the very few example who write test which totally make sense and even highly complex integration tests. But that is an art not many developers are mastering. I agree totally to your statements! I just had a conversation with @salokiam and he will start to manage those issues (improve/update onboarding documentation and be a point for contact for new devs). Here are a few more open tasks for Bisq 2 I forgot in the above list:
|
Beta Was this translation helpful? Give feedback.
-
|
I am looking at your roadmap for protocols for Bisq2. Given the current development speed (Bisq2 is in development for 2 years, Bisq Easy has probably used 1 year of 1 dev), I estimate it will take several years until we have implemented Lightning. Until lightning is done, we havent even created anything where we can improve the revenue situation. As Bisq Easy wont generate anything and MS is only a replacement for existing, but not generating substantially more users or revenue. Lightning being a very complex, i would think (at current development speed) this will take another 2 years minimum. That makes 4 years until we have a protocol with can drive more adoption of Bisq. From talking to potential users, I regularly hear the following requests:
Since my comment here is only about developing protocols, Lightning is more important than an improved MultiSig. If I find time, I will address mobile in a different post. So upshot of this little article is to change the ordering of your prios for protocol development. After Bisq Easy, go for Lightning and then for improved MultiSig. |
Beta Was this translation helpful? Give feedback.
-
|
The Lightning to Fiat protocol is using the ported Multisig protocol to Liquid. The other option would be the Lightning protocol concept from @stejbac . To the dev time estimations: Yes if we stick with current limited dev resources it will take some time. But hey there are many devs out there, so lets get some work done. If we would have 2-4 more fulltime devs things would look very different. |
Beta Was this translation helpful? Give feedback.
-
There are a few new devs (@AllyKaz, @napoly) around (which is great!) and some work is done in the testing and API area. I would like to discuss what Bisq is intended to focus on dev-wise.
Bisq has suffered in the past from ill-invested money in work which never brought improvements to the project (in some cases even the opposite). That is mainly because the dev area is largely un-managed and new devs are often left alone to figure out what to work on. Communication in the dev area is also very poor unfortunately (everyone too buys with coding and no one wants to play the managing role).
So here some suggestions how we can avoid that from happening again:
Here are my personal priorities and view on what Bisq should focus on and what not:
The Bisq 1 API has been a failure from my point of view. We still do not know if and how many people are using it but from feedback from several devs who wanted to use it (and most gave up after a while) it seems its too cumbersome to use. I have never used it myself, so that is all second hand information. Bisq invested a lot of money in it with more then 1 year dev work. We have to ensure to not throw more money into that grave anymore.
Investment in the test coverage has a similar track record. Bisq invested lot of money in the past in devs who wanted to improve that and in some parts they got for sure improvements but overall the invested money was not justified by the results. In some cases it made the code base worse by adding more boilerplate code without any real improvements (like passing the Clock object everywhere).
Bisq is very different to traditional IT industry projects and need to be treated with that in mind. Also our resources are limited and to get a valuable test environment is a huge effort Bisq simply cannot afford. So what often makes perfect sense in a traditional IT industry project often does not work for Bisq.
I am not talking about pure unit tests testing some limited behavior but about the complex integration tests. Simple unit tests are of course welcome but that is usually not where the problems happens.
The bugs are mostly caused in the highly asynchronous and often multiple domains spanning areas often involving UI. To test that requires very complex mock structures and integration tests. In the P2P network one dev implemented that to some extent, but even the quality of that was very high it turned out that it sometimes did not test the real behavior and the highly complex mock structures caused a huge burden for future changes. A small change code-wise often triggered then a day work to get the tests working again. Not because the change broke something but because the mock structure did not represent the real behavior and thus the change could not be easily integrated.
I think dev on Bisq 1 should be focused on areas where the user gets a direct benefit not in dev infrastructure (also with the limited life-span of Bisq 1 in mind).
Those are features requested by users or by the support team, bug fixes, UI improvements and performance optimizations.
The work done by @jmacxx and @stejbac (he did a lot of amazing performance optimizations) are good examples for that.
Those are my personal views and I invite any reader to post their view. I hope we can come to some consensus on what we want to focus on to avoid disappointments for new developers and ill-invested expenses for the Bisq DAO.
Beta Was this translation helpful? Give feedback.
All reactions