I can't speak for Ben or the Dev.to team, but I think the key to justifying open source is to explain that the business value isn't in the code, but elsewhere. Take Dev.to for example: the value of their business is in the community they created. They have a bunch of users creating content, and other users coming here to view it. Because they have this community, they can go to tech companies and ask for sponsorship. Those companies will pay Dev.to to get their products/services featured in this large developer community.
None of this changes after Dev.to is open sourced. Someone could create a clone, but why would people leave the original for the clone? The clone wouldn't have an existing community or content creators. As long as people are happy with the way the original is being managed, they won't leave. The clone could try to offer new features or functionality, but under GPL they are obligated to publish those changes. The original could incorporate any killer features, and ensure that people don't leave for the clone.
I hope this is a helpful example about why open sourcing Dev.to isn't bad for their business. If you can explain why the value of your business isn't tied into the code, I think you can justify open source to people with a non-tech background. Caveat: if your business value is tied to your code, then you probably cannot justify open source.
If your closing your explanation with 'open sourcing isn't bad for business', sounds like you don't have a good argument for 'why is it good for business?' or 'why should we waste our time on this?'.
Good point. The biggest draws are probably:
1) Code contributions. This is an optional part of open source, as you can open source a codebase without allowing contributions. But if you institute a code review process, you can allow technically inclined users to fix bugs. Even if you choose not to allow code contributions, your users may still help you find bugs by looking through the codebase.
2) Community. This is derivative of the previous point. If you have users looking through your codebase, submitting bug fixes and involving themselves in feature design, you have a group of users invested in your project. They are more likely to do things like add documentation, or evangelize your project to other people. You might even find new employees through this process.
3) It inspires confidence in your users. This is the biggest one. When you open source a project, this lets developers know they can trust this project. If they have an issue, they can look through the codebase and try to solve it. If they want to change part of the application to suite their own needs, they have that option. They can audit the code to make sure there isn't anything nefarious going on.
Now all three of these points are all centered around developers. But the non-developer users will still benefit from the work done by tech savvy users. And while your non-developer users may not fully grasp the benefits of open source, you can still include it in your marketing. Take the telegram website for example, which includes a small blurb on openness in their list of "Why switch to Telegram". If you're trying to differentiate your product with similar competing products, it may be beneficial to say something about how your product is more transparent and open with your users.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I can't speak for Ben or the Dev.to team, but I think the key to justifying open source is to explain that the business value isn't in the code, but elsewhere. Take Dev.to for example: the value of their business is in the community they created. They have a bunch of users creating content, and other users coming here to view it. Because they have this community, they can go to tech companies and ask for sponsorship. Those companies will pay Dev.to to get their products/services featured in this large developer community.
None of this changes after Dev.to is open sourced. Someone could create a clone, but why would people leave the original for the clone? The clone wouldn't have an existing community or content creators. As long as people are happy with the way the original is being managed, they won't leave. The clone could try to offer new features or functionality, but under GPL they are obligated to publish those changes. The original could incorporate any killer features, and ensure that people don't leave for the clone.
I hope this is a helpful example about why open sourcing Dev.to isn't bad for their business. If you can explain why the value of your business isn't tied into the code, I think you can justify open source to people with a non-tech background. Caveat: if your business value is tied to your code, then you probably cannot justify open source.
If your closing your explanation with 'open sourcing isn't bad for business', sounds like you don't have a good argument for 'why is it good for business?' or 'why should we waste our time on this?'.
Good point. The biggest draws are probably:
1) Code contributions. This is an optional part of open source, as you can open source a codebase without allowing contributions. But if you institute a code review process, you can allow technically inclined users to fix bugs. Even if you choose not to allow code contributions, your users may still help you find bugs by looking through the codebase.
2) Community. This is derivative of the previous point. If you have users looking through your codebase, submitting bug fixes and involving themselves in feature design, you have a group of users invested in your project. They are more likely to do things like add documentation, or evangelize your project to other people. You might even find new employees through this process.
3) It inspires confidence in your users. This is the biggest one. When you open source a project, this lets developers know they can trust this project. If they have an issue, they can look through the codebase and try to solve it. If they want to change part of the application to suite their own needs, they have that option. They can audit the code to make sure there isn't anything nefarious going on.
Now all three of these points are all centered around developers. But the non-developer users will still benefit from the work done by tech savvy users. And while your non-developer users may not fully grasp the benefits of open source, you can still include it in your marketing. Take the telegram website for example, which includes a small blurb on openness in their list of "Why switch to Telegram". If you're trying to differentiate your product with similar competing products, it may be beneficial to say something about how your product is more transparent and open with your users.