9 ms·

Closed source development tools with a EULA? What is this? 1995?

Taurenking 13y ago
Not everyone can enjoy a part time job or an enviroment in where he can seriously develop side projects, and still have enough money to sustain itself...
mherrmann 13y ago
We quit our daytime jobs to work on this project and have to live off something... Maybe you have a suggestion as to what we could do to allow us to sustain our development in another way?
- moconnor 13y ago
  This is a really interesting problem. There's the expectation - and desire - for all software, particularly development tools, to be open source. This seems to make it harder for independent developers to devote time to creating great tools. Is the future of software tools in the side-effects of teams at large organizations open sourcing things they needed to solve their own problems?
  - mherrmann 13y ago
    I agree that it's interesting and that it is a problem. You could see from mapleoin's comment that closed source software is not looked at favorably. I can see why, but as I said if we want to sustain full-time development of this project, we need an income. One approach that's often used with open source projects is to develop the software for free and then charge for consulting. But, with a tool such as Helium that aims to be extremely simple, I don't see much room for such services. I'd be extremely curious to hear if anybody has an answer to this problem.
    - deleted 13y ago
      [deleted]
    - hyp0 13y ago
      First off, excellent idea. It seems simple and straightforward to automate web site interaction, especially for those lacking APIs (e.g. my stoneage bank, to check for telegraphic transfer payments). But I'm torn. On the one hand, I support developers getting paid for creating tools/libraries (instead of working on in-house software; or consumer/business startups). I think it's better for the world. It's also how I've supported myself for the last 10 years. On the other hand, I don't like your email-wall etc. As I see it, you need to serve two markets: the businesses that will pay for your software; and everyone else, who won't pay, but will promote it word-of-mouth/google juice, through blog posts, stackoverflow answers, reddit/HN posts/comments etc etc etc (this is incredibly helpful for getting sales). Thus, you need to serve both, and make it both easy to buy, and easy to not buy. 1. Your email-wall is one solution. People can still get it free, they just don't like. I think it will fail (but it might work, who knows?) 2. Another way is two versions: free/community/demo and paid. Find features that matters a lot to businesses (or sounds like it), and doesn't matter to everyone else. Quotas are another way, although hard to enforce in a library (easy in a webapp), but also consider that legit businesses prefer buying over cracking. (e.g. pkzip got pirated like crazy, but the guy also made money). 3. A way to do open source is "dual-licensing": GPL + commercial. The GPL forbids closed-source distribution, so you license it to people who want to distribute it. The problem with this (I did it) is long sales-cycles, because there's no urgency for people to buy, they already have it. (they do eventually pay, it just takes a long time). Ghostscript does something similar. But your big problem is more subtle: you have a cool idea that is truly valuable to businesses - but it's easy to implement. I think most coders here could hack a barely-working prototype within 2 hours. All it takes is one of them to publish it on github, and keep working on it for 6 months, and you're finished. It's not because theirs is better than yours - but because they will get ALL the word-of-mouth and google-juice. Thus, you need to serve both markets. This denies oxygen to the copy-cats - why would anyone bother with that half-assed knock-off, when they can get the real thing from you? Even if someone starts a clone, it will languish without any interest or feedback. People also like to reward originators (provided it doesn't actually cost them anything...). Another thing you can do is implement difficult features - from skimming your site, it all looks pretty easy... but if you find some obstacle that seems to kill how it should work, that's a GREAT thing. Solve it, and you have a barrier (this is what happened for me). Or as Joel said, "where there's muck there's brass". But the most important thing for your long-term success is to realize the situation is dynamic. You have to keep improving constantly (this often means discovering new ways to improve, even when it seems there aren't any). Even if someone copies, you still have the latest and greatest. Thus, you can measure your barrier in time - how long before they catch up? Even if it's only 6 months - or even 1 month - provided yours is always significantly better, everyone (businesses and others) will prefer it. There's also some lag, that it takes for word to get out of a competitor, to build word-of-mouth/google-juice, and to convince pragmatists that it really is credible. So this "market" lead also gives you some time (probably only a few months though). Note: even when hackers are no longer excited, businesses will still be interested - because they don't buy cool technology, they buy solutions to their problems. They don't care how sexy it is, they care if it works, and that's it. So don't be discouraged when you are no longer hot. Finally, to address your comment directly: I agree it's a problem, for libraries especially. I think open-source + consulting is a terrible idea (unless you're a consultant - then it's fantastic publicity. But conflict with making it easy to use, so it doesn't need a consultant...). Looking at wildly successful developer tools, they seem to be desktop tools: IDEs (JetBrains on the frontpage now); xmlspy and a bunch of xml tools. I don't know why this is (Maybe it feels like non-code to programmers, unlike a library? Maybe because it's more work, and needs GUI-skills/interest?) I'm intrigued by the idea of "service components": library-like functionality, used through web-APIs. (In contrast, most current web-APIs access data and/or business service, not a computational service). It would sit in the cloud, next to their web-app, so it's fast - but they don't have the source, and can only access it to via the web-API. Note that libraries naturally are accessed through an API - this is just on a different machine, like a DB often is (you probably want to config the query, then run it, to minimize network traffic). Then you can do quota restrictions, like any other web-app. --- One thing though: if it doesn't work, please try a few other strategies before giving up. You have a valuable idea there.
  - rmrfrmrf 13y ago
    It's a matter of sound business decisions more than anything. This is a classic example of not understanding your target audience. Look at the competition: on one end, you have a flexible, open source web testing framework like CasperJS (targeted at developers); on the other hand, you have end-user oriented products like Fake.app that are paid and closed source. One could even argue that Selenium itself (also free) has a nice enough GUI to be considered power user friendly. When you start charging devs for closed source, paid applications, you're getting into the territories of Oracle, Microsoft, and IBM. Is that really how this independent team wants to position itself? Can this team even support the kinds of problems that enterprise clients have every day? Seems like a really terrible segment to target. And if this team was really thinking that indie devs would go and blindly purchase a product like this from an unheard-of company with no established reputation, then, again, they need to go back to the drawing board with their business model and/or hire someone who can provide guidance.
    - mherrmann 13y ago
      I thank you for your honest and direct feedback. Obviously, it's very interesting for us to hear, and if you are right and we do not understand our target audience or our business model is flawed, then we have a problem that we should find out sooner rather than later. You have a lot of criticism for how we position ourselves, and our product. I deeply believe that there is a market for a tool such as Helium, be it open- or closed source. Assuming that we have a product that the market wants, can you recommend a way for us to make this product open source, yet generate an income that allows us to sustain its development?
      - rmrfrmrf 13y ago
        An idea (maybe too obvious) that comes to mind would be to host people's tests and send alerts when tests fail, then work up a deal with Heroku to offer your web testing service as a plugin. Many of the plugin services have the same type of tiered business model. You could do something like a 30 day trial (or, alternatively, 1 test per day free), then offer services for 50 requests, 500, 1000, etc. I'm not incredibly familiar with how frequently web tests run and how many pages/forms/fields the average project has, so obviously you'd have to tweak those numbers based on what you think will generate the most revenue.
  - nfoz 13y ago
    Software has always been set back by an absense of business models that support the development of high-quality software. Either it takes draconian copyright (which severely limits the usefulness of the software), DRM/no reverse-engineering licenses, or advertisement/3rd-party tracking, or some other braindamaged scheme. The future I see is in crowdfunding development up-front. It takes a social change alongside the development of technology to facilitate that (improved payment processing would help; lowering transaction fees and allowing micropayments, etc.). We're getting there, but it's really tough. I don't have a good answer. But copyright and license agreements aren't it.
- rmrfrmrf 13y ago
  I just want to point out, however, that there are other open source frameworks that do the exact same thing. Utility libraries like this are rarely closed source because the target audience is working in code (and there are also security issues to think about). End-user products can get away with being closed source because non-coders don't give a crap about the nuts and bolts of your program. Hate to be blunt, but your business model isn't viable. If you want to monetize, you either need to provide a service to developers or a product to end users.
  - mherrmann 13y ago
    I'd be curious to hear which other open source frameworks "do the exact same thing". I spent hours compiling a list of competition products, and none can really offer an approach as high-level as Helium. The one that comes closest is Capybara, but it's still not quite as high-level as Helium, and only available for Ruby.
    - egeozcan 13y ago
      Using CasperJS, you get more or less the same. http://docs.casperjs.org/en/latest/modules/casper.html#clicklabel http://docs.casperjs.org/en/latest/modules/casper.html#click...
      - mherrmann 13y ago
        Sorry, but in the link you give (clickLabel), I still have to provide the HTML element type ("<a>" or "<button>"). How does CasperJS for instance let me type some text into a text field with a label to its left?
        egeozcan 13y ago
        That is an optional parameter. You also have an easy way to fill a form: http://docs.casperjs.org/en/latest/modules/casper.html#fill http://docs.casperjs.org/en/latest/modules/casper.html#fill
oblio 13y ago
Whoa there you FOSS commie! (just kidding, I know mapleoin)

Not everyone can enjoy a part time job or an enviroment in where he can seriously develop side projects, and still have enough money to sustain itself...

mherrmann 13y ago

We quit our daytime jobs to work on this project and have to live off something... Maybe you have a suggestion as to what we could do to allow us to sustain our development in another way?

moconnor 13y ago
This is a really interesting problem. There's the expectation - and desire - for all software, particularly development tools, to be open source. This seems to make it harder for independent developers to devote time to creating great tools. Is the future of software tools in the side-effects of teams at large organizations open sourcing things they needed to solve their own problems?
- mherrmann 13y ago
  I agree that it's interesting and that it is a problem. You could see from mapleoin's comment that closed source software is not looked at favorably. I can see why, but as I said if we want to sustain full-time development of this project, we need an income. One approach that's often used with open source projects is to develop the software for free and then charge for consulting. But, with a tool such as Helium that aims to be extremely simple, I don't see much room for such services. I'd be extremely curious to hear if anybody has an answer to this problem.
  - deleted 13y ago
    [deleted]
  - hyp0 13y ago
    First off, excellent idea. It seems simple and straightforward to automate web site interaction, especially for those lacking APIs (e.g. my stoneage bank, to check for telegraphic transfer payments). But I'm torn. On the one hand, I support developers getting paid for creating tools/libraries (instead of working on in-house software; or consumer/business startups). I think it's better for the world. It's also how I've supported myself for the last 10 years. On the other hand, I don't like your email-wall etc. As I see it, you need to serve two markets: the businesses that will pay for your software; and everyone else, who won't pay, but will promote it word-of-mouth/google juice, through blog posts, stackoverflow answers, reddit/HN posts/comments etc etc etc (this is incredibly helpful for getting sales). Thus, you need to serve both, and make it both easy to buy, and easy to not buy. 1. Your email-wall is one solution. People can still get it free, they just don't like. I think it will fail (but it might work, who knows?) 2. Another way is two versions: free/community/demo and paid. Find features that matters a lot to businesses (or sounds like it), and doesn't matter to everyone else. Quotas are another way, although hard to enforce in a library (easy in a webapp), but also consider that legit businesses prefer buying over cracking. (e.g. pkzip got pirated like crazy, but the guy also made money). 3. A way to do open source is "dual-licensing": GPL + commercial. The GPL forbids closed-source distribution, so you license it to people who want to distribute it. The problem with this (I did it) is long sales-cycles, because there's no urgency for people to buy, they already have it. (they do eventually pay, it just takes a long time). Ghostscript does something similar. But your big problem is more subtle: you have a cool idea that is truly valuable to businesses - but it's easy to implement. I think most coders here could hack a barely-working prototype within 2 hours. All it takes is one of them to publish it on github, and keep working on it for 6 months, and you're finished. It's not because theirs is better than yours - but because they will get ALL the word-of-mouth and google-juice. Thus, you need to serve both markets. This denies oxygen to the copy-cats - why would anyone bother with that half-assed knock-off, when they can get the real thing from you? Even if someone starts a clone, it will languish without any interest or feedback. People also like to reward originators (provided it doesn't actually cost them anything...). Another thing you can do is implement difficult features - from skimming your site, it all looks pretty easy... but if you find some obstacle that seems to kill how it should work, that's a GREAT thing. Solve it, and you have a barrier (this is what happened for me). Or as Joel said, "where there's muck there's brass". But the most important thing for your long-term success is to realize the situation is dynamic. You have to keep improving constantly (this often means discovering new ways to improve, even when it seems there aren't any). Even if someone copies, you still have the latest and greatest. Thus, you can measure your barrier in time - how long before they catch up? Even if it's only 6 months - or even 1 month - provided yours is always significantly better, everyone (businesses and others) will prefer it. There's also some lag, that it takes for word to get out of a competitor, to build word-of-mouth/google-juice, and to convince pragmatists that it really is credible. So this "market" lead also gives you some time (probably only a few months though). Note: even when hackers are no longer excited, businesses will still be interested - because they don't buy cool technology, they buy solutions to their problems. They don't care how sexy it is, they care if it works, and that's it. So don't be discouraged when you are no longer hot. Finally, to address your comment directly: I agree it's a problem, for libraries especially. I think open-source + consulting is a terrible idea (unless you're a consultant - then it's fantastic publicity. But conflict with making it easy to use, so it doesn't need a consultant...). Looking at wildly successful developer tools, they seem to be desktop tools: IDEs (JetBrains on the frontpage now); xmlspy and a bunch of xml tools. I don't know why this is (Maybe it feels like non-code to programmers, unlike a library? Maybe because it's more work, and needs GUI-skills/interest?) I'm intrigued by the idea of "service components": library-like functionality, used through web-APIs. (In contrast, most current web-APIs access data and/or business service, not a computational service). It would sit in the cloud, next to their web-app, so it's fast - but they don't have the source, and can only access it to via the web-API. Note that libraries naturally are accessed through an API - this is just on a different machine, like a DB often is (you probably want to config the query, then run it, to minimize network traffic). Then you can do quota restrictions, like any other web-app. --- One thing though: if it doesn't work, please try a few other strategies before giving up. You have a valuable idea there.
- rmrfrmrf 13y ago
  It's a matter of sound business decisions more than anything. This is a classic example of not understanding your target audience. Look at the competition: on one end, you have a flexible, open source web testing framework like CasperJS (targeted at developers); on the other hand, you have end-user oriented products like Fake.app that are paid and closed source. One could even argue that Selenium itself (also free) has a nice enough GUI to be considered power user friendly. When you start charging devs for closed source, paid applications, you're getting into the territories of Oracle, Microsoft, and IBM. Is that really how this independent team wants to position itself? Can this team even support the kinds of problems that enterprise clients have every day? Seems like a really terrible segment to target. And if this team was really thinking that indie devs would go and blindly purchase a product like this from an unheard-of company with no established reputation, then, again, they need to go back to the drawing board with their business model and/or hire someone who can provide guidance.
  - mherrmann 13y ago
    I thank you for your honest and direct feedback. Obviously, it's very interesting for us to hear, and if you are right and we do not understand our target audience or our business model is flawed, then we have a problem that we should find out sooner rather than later. You have a lot of criticism for how we position ourselves, and our product. I deeply believe that there is a market for a tool such as Helium, be it open- or closed source. Assuming that we have a product that the market wants, can you recommend a way for us to make this product open source, yet generate an income that allows us to sustain its development?
    - rmrfrmrf 13y ago
      An idea (maybe too obvious) that comes to mind would be to host people's tests and send alerts when tests fail, then work up a deal with Heroku to offer your web testing service as a plugin. Many of the plugin services have the same type of tiered business model. You could do something like a 30 day trial (or, alternatively, 1 test per day free), then offer services for 50 requests, 500, 1000, etc. I'm not incredibly familiar with how frequently web tests run and how many pages/forms/fields the average project has, so obviously you'd have to tweak those numbers based on what you think will generate the most revenue.
- nfoz 13y ago
  Software has always been set back by an absense of business models that support the development of high-quality software. Either it takes draconian copyright (which severely limits the usefulness of the software), DRM/no reverse-engineering licenses, or advertisement/3rd-party tracking, or some other braindamaged scheme. The future I see is in crowdfunding development up-front. It takes a social change alongside the development of technology to facilitate that (improved payment processing would help; lowering transaction fees and allowing micropayments, etc.). We're getting there, but it's really tough. I don't have a good answer. But copyright and license agreements aren't it.
rmrfrmrf 13y ago
I just want to point out, however, that there are other open source frameworks that do the exact same thing. Utility libraries like this are rarely closed source because the target audience is working in code (and there are also security issues to think about). End-user products can get away with being closed source because non-coders don't give a crap about the nuts and bolts of your program. Hate to be blunt, but your business model isn't viable. If you want to monetize, you either need to provide a service to developers or a product to end users.
- mherrmann 13y ago
  I'd be curious to hear which other open source frameworks "do the exact same thing". I spent hours compiling a list of competition products, and none can really offer an approach as high-level as Helium. The one that comes closest is Capybara, but it's still not quite as high-level as Helium, and only available for Ruby.
  - egeozcan 13y ago
    Using CasperJS, you get more or less the same. http://docs.casperjs.org/en/latest/modules/casper.html#clicklabel http://docs.casperjs.org/en/latest/modules/casper.html#click...
    - mherrmann 13y ago
      Sorry, but in the link you give (clickLabel), I still have to provide the HTML element type ("<a>" or "<button>"). How does CasperJS for instance let me type some text into a text field with a label to its left?
      - egeozcan 13y ago
        That is an optional parameter. You also have an easy way to fill a form: http://docs.casperjs.org/en/latest/modules/casper.html#fill http://docs.casperjs.org/en/latest/modules/casper.html#fill

oblio 13y ago

Whoa there you FOSS commie! (just kidding, I know mapleoin)