

Show HN: Helium - Simple web automation - mherrmann
http://heliumhq.com
Hi everyone,<p>I&#x27;m working for a startup called BugFree Software and would love to hear your feedback on a new product we are launching today.<p>Helium is a library that wraps around Selenium to simplify web automation. It does away with many of the technicalities involved with web scripting. For example: Here is a Selenium script. Can you guess what it does?<p><pre><code>    &gt;&gt;&gt; ff = Firefox()
    ...
    &gt;&gt;&gt; text_area = ff.find_element_by_id(&quot;u_0_1q&quot;)
    &gt;&gt;&gt; text_area.send_keys(&quot;Hello World!&quot;)
    &gt;&gt;&gt; button = ff.find_element_by_class_name(&quot;_42g-&quot;)
    &gt;&gt;&gt; button.click()
</code></pre>
Here is the same script rewritten using Helium:<p><pre><code>    &gt;&gt;&gt; start_firefox()
    ...
    &gt;&gt;&gt; write(&quot;Hello World!&quot;, into=&quot;Update Status&quot;)
    &gt;&gt;&gt; click(&quot;Post&quot;)
</code></pre>
Can you now guess what it does? That&#x27;s right; It updates your Facebook status.<p>In an extended comparison that we were invited to write for the December issue of Professional Tester (professionaltester.com), we found that an example script automating Gmail took 66% fewer lines of code and 75% less effort using Helium than with Selenium alone.<p>You can find more information and download Helium from http:&#x2F;&#x2F;heliumhq.com. Any feedback would be highly appreciated.<p>Hoping to hear your thoughts and comments,
Michael Herrmann
heliumhq.com
======
teh_klev
First of all let me say that I have no problem with paying for software, even
closed source or otherwise. I already pay a chunk of personal money for
JetBrains tools and stuff from RedGate to let me get on and do my job more
efficiently, and my company does the same.

However your license condition:

"If you want to run Helium on another machine then you must first remove it
from the computer you were using it on previously."

I work across a few different machines - work PC, other work PC and PC in
lounge at home, VM's etc. This license condition just isn't practical or
financially viable for solo developers or small dev shops who work like this.
Do you actively check for multiple installs under the same license i.e. with a
registration server? Altova XML Spy used to do this and it quickly got binned
after the first year's license came up for renewal because they messed up the
licensing records (PC crashed, couldn't de-register in-use licenses etc,
hassle, hassle hassle) and we had developers working in VM's for a bunch of
different projects all at once. Yes we could defeat the LAN sniffing it did to
find out if two copies of the XML Spy were running with the same license, but
it was too much effort and we resented having to do this - despite each dev
being properly licensed.

Vendors such as JetBrains and RedGate license the software to me/company for
use by a single developer/user, I don't have restrictions such as "you must
first remove it from the computer you were using it on previously".

I/we are happy to buy licenses for each developer on our team "using" the
software, but not for each and every VM or dev env a single developer is
working in. As such I haven't bothered to let my colleagues know about this
tool which sounds pretty cool, nor have I tried to download it (forcing me to
part with contact details to try something really puts me off).

I understand that you have to eat and pay the rent, but even for a company
like ours, that has a fairly generous budget for development tools, this type
of "per-installed machine" license is considered hostile for the type of tool
being sold.

I'm generally not a negative person when it comes to "Show HN" and I truly
appreciate the efforts people put into their projects whether it be for a
paid-for product or showing off some hacks or tricks, but your license....it
frustrates me.

~~~
mherrmann
I see. I'm very sorry to hear that you are so frustrated with the licensing
scheme. We should also offer "floating" licenses which are not tied to a
particular machine. Would that be OK for your needs?

~~~
teh_klev
If you emulated the JetBrains style of license, where the license is purchased
for a developer such that it can be installed wherever he/she is working then
I'd be interested.

For example, today I'm running three Linux VM's on my PC, each one has a
launched instance of PyCharm because I'm multi-tasking over three different
projects and switching between them as and when I need to. If I couldn't do
that with PyCharm then I'd be buying a different tool.

ps: don't apologise, I suspect this is probably your first foray into
licensing, I hope the feedback is useful.

~~~
mherrmann
I can see the attraction of JetBrains' style of license. We'll look into this.

It's not our first foray into licensing and we actually have offered a
"floating" licensing scheme which seems to be what JetBrains offer before. We
just have not implemented (=coded) such a scheme yet for Helium.

------
adambenayoun
@mherrmann - There are various ways you could monetize Helium and be open
source - here are a few ideas. All of them assume that you will be open
sourcing your code. The reason for open sourcing this would be to basically
achieve wider adoption which will in turn allow you to monetize 5-10% of your
audience (Enterprise customer for example).

1\. Open Core Licensing - You could create a community edition and an
enterprise edition. The community edition would be completely open source and
available for free. While you work on the community edition you could identify
the 5% of additional features that certain customers (Enterprise for example)
would pay for. I think this is a pretty fair way to balance between giving
away a free product and creating an enterprise/professional edition where
you'd charge a license fee from customers who would have the ability to pay
for it. One of the challenges with this model is to make sure you find the
right balance between the community and enterprise edition since some people
will be upset that certain feature aren't released in the community but make
it into the enterprise edition.

2\. SaaS - If you open source it and gain widespread adoption - at some point
it might makes sense to create a service that allow users to run these tests
on the cloud and create a complete suite of features around it. Many
developers are happy to pay a service fee for using an hosted version of the
open source software that allow them to not deal with hosting, patching and
servicing that software. If you do that releasing it under the AGPL will give
you a competitive advantage since if someone would like to create a hosted
service and improve the open source software, they would have to release all
changes to the community (or license a commercial version from you), however
if you decide to add some secret sauce in the hosted solution, you ARE NOT
required to release it to the community since you could license it under a
commercial license to yourself.

3\. Offer professional services, support and training - Once developers will
start using this in their workflow and start being dependent on that software,
they will want the peace of mind of paying for support (or the ability to
contact you and ask questions). You could have various SLA of support. For
examples: Community edition (FREE) would have access to community forum where
users could help each other - at first you'd seed that forum with your own
support to kickstart the community. Then you could offer several level of
support, from email (9-5 or 24/7) to phone support to various customers.
Additionally you could offer up to a certain amount of training or consulting
to write custom tests for customers who will need your help integrating this
into their workflow. Most often people will opt for paying for a basic license
even if the software is free just so they have someone to nag and talk to if
things go south.

There are more ways that you could monetize open source - if you found this
reply useful and would like to learn more - feel free to reach out to adam
(at) binpress (dot) com - I am the co-founder at
[http://www.binpress.com](http://www.binpress.com) \- the marketplace for
commercial open source - we're on a mission to help developers monetize their
open source projects.

~~~
mherrmann
@adambenayoun Many thanks for all these suggestions.

I see several advantages with open sourcing our product. Most notably, wider
adoption and community support available on the net.

Unfortunately, all three options you propose defer the point in time from
which we can earn money. For a startup, this is very risky. If we run out of
resources before say we have enough users to set up a SaaS service or offer
support & training, we will go bust with nothing but wasted money and time on
our balance sheets.

I am sorry to be so direct, but I think the three options you propose are not
currently viable for us. We might revisit them later though, and I might be in
touch via your email! - when we know more about the limitations of our current
approach.

Thanks again! Michael

~~~
adambenayoun
Michael No need to apologize :) As another user in this thread suggested -
ultimately this is your company and you'll decide what is the best course of
action to turn it into a profitable business. By all means do whatever is
possible to make that happen and don't be afraid to experiment.

I suggested a few ideas that could work and would basically allow you to enjoy
from both world (both open sourcing your product and monetizing it) however I
can understand if you think you don't have the time to get the kind of
adoption you'd need to successfully open source it.

Additionally this could be done backward - you could start with your current
model and at some point once you are more economically confident switch to
another model that is more open source friendly.

Good luck! :)

------
oblio
I hope you succeed with your project, but sorry, I feel that your pricing is
batshit insane, pardon my French.

$200 per year subscription for 1 machine for the basic license with support
only for the installation, basically. And probably bugfixes, I'm guessing.

If for whatever reason I'd like to create a 3-4-5 VM test farm I'd have to pay
$600-$800-$1000 per year.

And, again, subscription. If I don't pay after one year I cannot use this
anymore.

Combined with the closed source factor, I really don't like it, sorry.

~~~
mherrmann
Thank you for the honest feedback and the good wishes.

Here's why we think our subscription model makes sense: In our evaluation
(heliumhq.com/AutomatingGmailWithHelium.pdf), developing a script with Helium
took 75% less effort (man-days) and 66% less code than a script written in
pure Selenium. The average developer salary in the US in 2010 was $90k a
year([http://money.usnews.com/careers/best-jobs/software-
developer...](http://money.usnews.com/careers/best-jobs/software-
developer/salary)). Say this developer works 260 days a year, so makes roughly
$350 a day. If it doesn't take him 75%, but only 25% less effort to write and
maintain some web automation code, then each day of him working with Helium
saves the company $87.5. This means that after about 11 working days, using
Helium will have paid off, leaving potentially 249 more days in the year
during which to reap Helium's benefits.

~~~
hyp0
Most developers aren't scripting web interaction fulltime.

This gives you a target: in which businesses _are_ they doing lots of it? Have
some copy on your website that speaks to the _managers_ of those specific
businesses - since they are the ones who decide and pay for it.

The scenario plays out: developer is sick of testing, hears about Helium,
tries it, it works great, he badgers his boss to buy it, boss looks at
website, says this is fantastic, let's buy 100, he goes to the next tier of
management for approval, and has all the answers for their concerns.

~~~
mherrmann
Very valid points. Especially the barrier that the developer is not the one
who makes the purchase decision is one we have already encountered in a
previous product.

------
Edmond
I read through the comments and see you are catching a lot of flack for being
closed source and daring to charge. My advice, do what you think makes sense
for your company. You seem to have already done some cursory market research
and I am guessing based on that you've decided on your current course of
action...stick with it unless you have a good reason to change direction.

Feedback is definitely important and useful but take it with a grain of salt.
The HN crowd is a rather biased one and doesn't really reflect the broader dev
world. Maybe try attending some dev meetups where you are likely to get a more
diverse opinion.

You've already quit your day job to do this, unless one of these folks is
going to be paying your rent, you should absolutely focus on monetizing your
product.

In terms of the open vs closed source issue, I do agree that dev products
should make their source code available, but that is only so it is easy to fix
problems and address security concerns. You don't have to make it "open
source", as in: allow people to freely alter and redistribute. I use this same
approach with my company's product, which is also a dev tool (see my profile
if you want to check it out).

~~~
mherrmann
Thanks for the realistic and encouraging words. I was beginning to feel like a
bad human being for charging for my work ;-)

So you give the source code for your product to your customers, once they have
bought it?

~~~
Edmond
Yes most of the source code is included with the product.

There is a small portion of it reserved for commercial entities, mainly the
source code for our middleware, but even that will be included in the future.

------
lfx
Hey, looks nice. Wonder how lib is detecting inputs by "user-visible labels".
Looks by html structure, or uses some "magic" methods?

~~~
mherrmann
Thanks! For now, it looks by (x, y) position on the web page.

~~~
hpaavola
Position of what? Why?

Given following markup:

    
    
        <label for="foobar">Lorem ipsum</label>
        <input id="foobar">
    

Does

    
    
        write('omg', 'Lorem ipsum')
    

write into #foobar? Just to clarify since position of those two elements might
not be similar at all.

~~~
mherrmann
In that case, it will write into #foobar because it is smart enough to
understand that <input/>s can be written to, and not labels. It works in a way
that is very similar to us humans: If someone tells us to "write 'Michael'
into the 'First Name' field", we look for the text "First Name" and then to
the right and bottom of this text if there is a field that can be written to.
So, position in this case is position on the page in (x, y) coordinates.

If there are multiple occurrences (eg. two "First Name" fields) then Helium
scans the page top-to-bottom, and closest to the element you last interacted
with. Like a human would normally also do.

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

~~~
mherrmann
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
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
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.

~~~
hyp0
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.

~~~
mherrmann
Interesting post full of ideas - many thanks. I agree that it would be great
for us to be able to get the best of both worlds - paying business customers
and (probably) non-paying users that supply the google-juice, as you so aptly
put it. Maybe we can offer a "Social license" that allows people to use Helium
for free if they tweet about it.

~~~
hyp0
Tweet-for-license is a logical idea, but it feels too paid-for-compliment -
even though people must be sincere, since they want the license... like
Dropbox's referral program.

However, maybe google juice isn't that important for your market... if you can
reach them in some more specific way, you don't need lots of freebie-loving
hackers. Also, there's a downside to lots of free users: by whetting the
appetite of people who will never pay, you create a vacuum for a clone to
fill.

PS: rmrfrmrf's
([https://news.ycombinator.com/item?id=6915104](https://news.ycombinator.com/item?id=6915104))
comment on Heroku's plugins sounds close to "service components" I mentioned
above. Building on his idea, [http://pingdom.com](http://pingdom.com) offers
free user alerts, and [https://travis-ci.org/](https://travis-ci.org/) offers
continuous integration testing via github hook - both have a free tier.

~~~
mherrmann
Tweet-for-license is working well so far, we'll see how it goes. And the
required tweet "Trying #helium web automation (heliumhq.com)" is imho really
not that much of a compliment. But obviously, we want something in return for
giving away free(!) licenses.

I can see your point of creating a "vacuum". Since we are giving away licenses
for free now, the challenge will be to not let such a vacuum happen, yet
create enough demand for businesses to pay for licenses.

I really don't see us offering a hosted SaaS platform at the moment. I can see
the advantages for the subscription model, but we're busy implementing Helium
for languages other than Python, so don't have time to set up a platform. It's
just not our core competency.

~~~
hyp0
Cool, you've tried that twitter idea already. Looks good. Iterating so quickly
bodes well for your success.

~~~
mherrmann
Advantages of a startup :-) And thanks for the kind words :)

------
hipsters_unite
A question (not meant facetiously) but what's the benefit of this over say,
Capybara/webrat, which already has the click and fill_in human readable
methods? The block of example code looks pretty much like an RSpec/Capybara
spec, is all.

~~~
mherrmann
Several things. I claim it's still more high level than Capybara. And it's
available for languages other than Ruby. Right now, you can download it for
Python. But we'll also release bindings for (hopefully all) languages
supported by Selenium.

~~~
hipsters_unite
Okay, thanks. Is this aimed at developers then, rather than say the product
team?

~~~
mherrmann
I would say it's aimed at anyone willing to do light programming / scripting.
I don't think a particular role within a company precludes this. (Sorry for
the late reply by the way, I lost track among all the comments here.)

------
mherrmann
We have now added a Social License to our Purchase page
([http://heliumhq.com/purchase](http://heliumhq.com/purchase)). It gives
everyone who tweets about Helium a free license!

~~~
resu
That's an excellent idea :)

------
briancray
I would suggest also allowing CSS selectors as a fallback. Text changes often
whereas a selector will change less often, producing a more reliable point of
interaction.

I would also suggest you put a screencast of a hello world. With many people
new to testing using headless webkit, they may have the wrong perception of
how selenium tests are run. Additionally what may not be obvious to people
used to javascript-based headless webkit tests is that Selenium/Helium tests
are written in python. Might want to clarify that as well.

Good luck!

~~~
mherrmann
Hi,

thanks for the suggestions! I'll discuss them with my colleagues.

CSS selectors are supported, because Helium is fully compatible with Selenium.
Eg.: You can say click(driver.find_element_by_css_class('btn')), where
click(...) is a Helium command and driver.find_element_by_css_class(...) is
from Selenium. Helium and Selenium are 100% interoperable.

Thanks again! :-)

------
Taurenking
this seems an iteresting project...how does the click() function work? Is it
possible to automate other actions beside the ones in the example?

~~~
mherrmann
Sure, you can find other actions on the docs page,
[http://heliumhq.com/docs/api_documentation](http://heliumhq.com/docs/api_documentation)

------
devspade
Trying to figure out what this gives me that Selenium doesn't? If I already
have a large code base using Selenium why should I switch?

~~~
mherrmann
Good question. It can't do anything that Selenium can't, but it's a lot easier
to work with. It's like developing in Assembler vs developing in C: Both are
equally powerful in what they can achieve, but the former is much more
technical to use than the latter.

The analogy extends further: We were invited to write an article about Helium
in the December issue of Professional Tester (professionaltester.com) in which
we compared automating Gmail with Helium vs pure Selenium. The code with
Helium was 66% shorter, but ran on average 26% slower than an (optimized)
Selenium script. You can find a thorough analysis covering the differences
between Helium and Selenium here:
[http://heliumhq.com/AutomatingGmailWithHelium.pdf](http://heliumhq.com/AutomatingGmailWithHelium.pdf)

~~~
devspade
Interesting. We have a ton of work put into Selenium already so switching
costs would be rather high for our team. But probably worth keeping an eye on
this project.

You're going to have some big obstacles to overcome trying to get people to
pay for this versus using Selenium.

~~~
mherrmann
Just would like to comment that you wouldn't have to "switch" completely.
Helium is fully interoperable with Selenium, that is, you can freely mix calls
to Helium to calls with Selenium. So in your case, you could add the Helium
library to your project and when you extend or maintain it, at every step,
choose whether you want to perform a particular step with Helium or Selenium.

------
duked
Hi, I like the idea and I used watir [0] in the best to do a lot of automation
but I fail to see what's different with Helium. Can you please tell me what
are the differences besides python vs ruby ?

[o][http://watir.com/](http://watir.com/)

------
fygwtclub
I overheard "Selenium" is the cure for "Mercury" poisoning. What's behind the
name "Helium". Just curious.

I would love to use "Helium" soon. All the best for your work.

~~~
mherrmann
The answer is simple: Helium is lighter than Selenium! ;-)

You can already use it today by downloading from
[http://heliumhq.com/download](http://heliumhq.com/download).

Thanks for the kind words!

