Concerns with DevToys for Mac

[veler]

Hello @ObuchiYuki,

I'm Veler, the co-author of the DevToys for Windows. My friend @btiteux and I are very impressed by how quickly you ported our app to MacOS and we believe it's a great job! Congrats!

However, we would like to share some concerns about the direction you took and would like to try to address them in a friendly way.

Feedback

Legal issue regarding the logo

We realized a few weeks ago that the DevToys's logo was violating the license of Windows Terminal logo. See https://github.com/veler/DevToys/issues/238 . As a consequence. DevToys for Mac's logo is also violating the license of Windows Terminal. Therefore, I'd highly recommend you change the logo of your app to avoid the same license issue as us.

Association with DevToys for Windows

We see some significant differences with our DevToys app that make us question the association made with our app by naming your app DevToys for Mac.

1. There doesn't seem to be any reused code from the DevToys app.

2. There are some tools that require an internet connection. This is going against the main goal of DevToys: having an app that works entirely offline and that doesn't require any internet connection (at all). We're making DevToys completely offline as an argument of security as many developers are pasting sensitive data on tools that have an internet connection (or even websites).

3. The list of tools available in the app seems to be hard-coded. In the app, we're trying to make the tools dynamically discovered (at runtime instead of build time). This approach allows us to limit duplicated code, improve maintainability and extensibility. We have in mind to make the application even more extensible, and the approach you took in your implementation doesn't seem to go in this direction, which might interfere with the advertisement we're planning to do for DevToys.

4. You announced on your Twitter some new tools coming in DevToys for Mac. https://twitter.com/yuki_obuchi/status/1488793587475415040?s=20&t=Le0dFJUTe9SB5zhXKrZ4Vw We have plans to develop some of these tools, but we're not planning to develop others in the near future, in particular Image Uploader, API Tester, and IP Information since we assume they require an internet connection.

Because of these differences of approach in the development of DevToys for Mac, having your app being named DevToys may confuse both of our user bases. The main confusion here is why DevToys on Windows is 100% offline but DevToys on Mac isn't and vice-versa.

Suggested outcome

Our goal isn't to bother you but we believe that the community of users will be confused by the current state of both of our apps. We believe your app is great and we're happy to see such a tool open source for Mac (most of other similar apps for Mac aren't free). However, we're truly bothered by the association made with ours. Therefore, we'd like to propose a resolution of this inconvenience, so we don't overlap on each other and don't confuse our customers.

Propositions

1. Please rename DevToys for Mac to something else that doesn't contain DevToys and communicate it clearly to your consumer base.
2. Please change the logo to avoid confusion with DevToys and legal issue with Windows Terminal.

As an alternative, if you would like to keep the association with DevToys and partner with us on the developement of our both app, we would need to impose the following non-exhaustive conditions which are representative of the core values of DevToys on Windows:

1. Remove tools that require an internet connection.
2. Refactor the app to have some code in common and plan for extensibility.
3. Collaborate with us to have the same UX on Windows and Mac (for example, the UX of HTML Encoder/Decoder is a bit different on Mac, according to some video you shared on your Twitter).
4. Collaborate with us on what tool to develop and when to release them so we can have the same tools on each platform.

In addition to this, we can:

1. Advertise your app on our website, social media, contacts...etc so you / we can have access to a wider public.
2. Synchronize updates / work together on a road map.
3. Make you an official developer on DevToys and merge your repository with ours.

Feel free to answer us here, on GitHub, or contact us in private on Twitter, LinkedIn and other communication channels. :)

Congrats again for this app! All the best, Etienne Baudoux and Benjamin Titeux

[ObuchiYuki]

Thank you for contacting me! @veler

I used DevToys on Windows and found it very useful, so I ported it to mac. I'm very honored to receive such an issue. I'm glad to address your feedback and concerns.

Legal issue regarding the logo

I was not aware of this issue, and I am thinking of updating the icons to match the DevToys changes. How about the following icon? (on macOS, the dot is on the left.)

Association with DevToys for Windows

I would like to partner with DevToys to develop together.

Are thses what I should do?

• Remove tools that require an internet connection.
• Refactor the app to have some code in common and plan for extensibility.
• Collaborate with us to have the same UX on Windows and Mac.
• Collaborate with us on what tool to develop and when to release them so we can have the same tools on each platform.

"Remove tools that require an internet connection.", "Collaborate with us to have the same UX on Windows and Mac.", "Collaborate with us on what tool to develop and when to release them so we can have the same tools on each platform.".

I think that these can be done easily. (I'm a student, so I'm sometimes a little busy during test periods, etc.)

I have a few questions about "Adding extensibility to tools"

Does extensibility in this case mean loading tools dynamically? Right now DevToys for mac defines the list of tools in enum, and I think that this is indeed an extensibility issue. This is an easy improvement and I will try to make it soon.

If this extensibility means to load tools at application runtime (such as loading JavaScript code), it will be very difficult to implement.

If it's the first one, I'll take these actions right away.

Thank you once again for contacting me. Your wonderful products have helped me a lot.

[veler]

Hello @ObuchiYuki

Thank you for your answer. :)

I got a conversation with @btiteux, and we believe we will have to go slowly, step by step into this partnership. The reason why is that many challenges are ahead of us. Here are a few I can think of.

Technical challenges

• Your project is made in Swift, ours is made in C#. For now, we don't want to have to rewrite the entire Windows app from scratch to make it work on macOS. At the same time, it would make sense to share some common code, in particular from the backend. Therefore, a problem to think about is how to have some code in common while staying native as much as possible?.

• Our repositories are currently separated and have different owners. To put some code in common along with keeping translations in common, we may need to consider creating a GitHub organization and either transfering the repository to that organization, or merging our repositories to one or several new ones in this organization.

Legal challenges

• Your repository and our are under MIT license. Just in case, we should probably have a conversation to determine whether the project stays under this license or not.

• I (veler) am the owner of DevToys repository. You are currently the owner of DevToys for Mac. Assuming we would deliver the app on Windows and Mac (and other future platform) under 1 single name (DevToys), we should probably have a conversation regarding the ownership of it to solve questions like:

  • Would the macOS app be published under your name, my name, an organization name?

  • Who validates Pull Request on which repository?

  • Who owns which repository(ies)?

  • While we would talk all together about what feature, UI changes to make in the app in the future, we should clarify who would have the ability to make the final decisions?

Human challenges

• As you mentioned, you are a student and sometimes you have more important things to do (like, preparing your tests) that makes you less available. No worries! We have the same issues. 😉 @btiteux and I aren't students, but our professional and personal life makes that we can't work on DevToys every day / weeks. We are developing DevToys in our spare time, based on our motivations, feeling and availability. This is 100% voluntary work and there is no expectation of delivery / deadline. So far, with this approach, we were able to release updates for DevToys almost at any time we want, since we had only 1 source code to manage. But with 2 source code (assuming both app stay native on their platforms for now), synchronizing our efforts to release feature updates at the same time will be challenging. For example, we would not want to have a release blocked because the development on Mac or Windows is very late compared to the other platform. Therefore, I'd suggest that we think and chat about how to keep the app on Windows and Mac as much synchronized as possible while not pressuring ourselves if we aren't able to work on the project.

• If I understood correctly, you are living in Asia. I am living in North America at the moment, and @btiteux is living in Europe. Because of our timezone differences, it will make the communication between all of us challenging too.

• @btiteux and I are very familiar with C#, but not at all with Swift. We will need some time to get used to it. By the way, do you have any experience with C#?

• @0x0c told us that another app named DevToys is under development for iOS and macOS. https://github.com/0x0c/AppleDevToys Perhaps we can all work together instead of overlaping?

Next step

All these challenges are things we can talk about together. Perhaps we can set up a public or private group chat to interact on a more direct basis, like a Discord server for example.

What do you think about? :)

Thank you for your time!

Etienne and Benjamin

[ObuchiYuki]

Thanks for the reply! @veler

It's very helpful of you to share about your challenge on partnership!I'm looking forward to discussing this challenge in more detail. I've followed you on Twitter and Linkedin at @ObuchiYuki. I would like to send you a Private Discord invite via DM here.

Thanks!

[veler]

Thank you :) I added you. Feel free to also invite @btiteux (twitter => b_titeux)

[stamminator]

This whole exchange is an excellent example of professionalism and class. Good to see such constructive steps taken to overcome the issues.

[farfromrefug]

@ObuchiYuki @veler i jump in a bit. first i love what you both are doing. i dont know if you know but there is an alternative to make cross platform app with native as much as possible. Tauri is just about to release 1.0. it is a framework where the ui is in a webview but you can very easily write as much native code as you want in rust. you can look it up here https://tauri.studio/ it is dead easy to get on with it.

[austincondiff]

@ObuchiYuki @veler While I understand the argument of being an offline tool (and this applies both the Mac and Windows app), why limit what the app is capable of to account for only offline use-cases? Why not simply hide or disable the online tools while offline?

[veler]

@austincondiff , that's something we're planning to do on Windows for a V2: https://github.com/veler/DevToys/issues/146 Not sure of the feasibility of it on Mac though.