ActiveState seeking Lua community feedback

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

ActiveState seeking Lua community feedback

Jeff Rouse

Hi all,


At ActiveState we feel Lua has a bright future in a variety of application areas (IoT, embedded scripting, and many others), and we are looking for ideas on how to support the community, increase adoption and help enterprises utilize the language more effectively. I’m proud to say that in 2017, we will be providing a community- and enterprise-ready Lua distribution on a variety of platforms, shaped in part by the feedback we receive from the community.


At ActiveState we have been in the open source tools and languages business (Python, Perl, Tcl) for almost 20 years. We also build developer tools, which are our Komodo Edit (open source) and IDE, which has basic Lua support, and we are actively making further Lua development improvements in those products.


If you would like to ask any questions or provide thoughts on where we can best help the Lua community, feel free to respond to this thread, email me, or sign up to our mail list (http://www.activestate.com/lua) for advanced notice of when our distribution is available. We look forward to hearing from you!


Cheers,
-JR

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Luiz Henrique de Figueiredo
> I'm proud to say that in 2017, we will be providing a community-
> and enterprise-ready Lua distribution on a variety of platforms,
> shaped in part by the feedback we receive from the community.

Very nice.
Perhaps you could give more details on what your Lua distribution is.
Does it include external libraries and tools? If so, which ones?

Your site says: "Why take risks with open source Lua and community support".
I don't see any risks in open source Lua. What do you have in mind?

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Jeff Rouse
Hi Luiz, thanks for taking the time to respond.

On Tue, Nov 1, 2016 at 12:16 PM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> I'm proud to say that in 2017, we will be providing a community-
> and enterprise-ready Lua distribution on a variety of platforms,
> shaped in part by the feedback we receive from the community.

Very nice.
Perhaps you could give more details on what your Lua distribution is.
Does it include external libraries and tools? If so, which ones?

We will most definitely be shipping more than just the distribution, as 
we want to add as much value as we can. We often ship more than
just the standard libraries in our distros, as this makes it easiest for
people to use them. This does require some balance as we typically
don't like to start supporting a external library and then have to remove it
later due to maintenance or security issues, so we have to be choosy.

This is one of the reasons we are reaching out in order to get some
feedback on what a fantastic distribution would look
like from your perspective.

In addition any areas that the community could use our help, we would
love to hear about, as we view this as much more than a business

 
Your site says: "Why take risks with open source Lua and community support".
I don't see any risks in open source Lua. What do you have in mind?

The risks for an enterprise is that they need to make sure of issues
like getting timely support, a contractual obligation for service,
assurances and timely security fixes. In many cases they need
the backing of a commercial entity to feel comfortable and in 
some cases this is a legal or compliance requirement. To
them it takes risk away. So its important for us to speak to
that. It in no way reflects on how the community supports
the language.


Cheers,
-JR

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Javier Guerra Giraldez
On 2 November 2016 at 07:21, Jeff Rouse <[hidden email]> wrote:

>> Your site says: "Why take risks with open source Lua and community
>> support".
>> I don't see any risks in open source Lua. What do you have in mind?
>>
> The risks for an enterprise is that they need to make sure of issues
> like getting timely support, a contractual obligation for service,
> assurances and timely security fixes. In many cases they need
> the backing of a commercial entity to feel comfortable and in
> some cases this is a legal or compliance requirement. To
> them it takes risk away. So its important for us to speak to
> that. It in no way reflects on how the community supports
> the language.


Here's some feedback:

- most of the language in the site feels confrontational; offering
your distribution (and support) as an alternative, not a complement to
the community.

- among your solutions, you list "ActiveLua Community Edition",
"ActiveLua Business Edition", "ActiveLua Enterprise Edition".  When I
see these "editions" list, I always have to wonder what each of these
take away from the original and feel that the whole design is geared
to make the most money.  Nothing bad in having solid business model,
of course; but that means that if I choose to do any kind of
interaction with such a company, I have to be on the defensive side.
It's much more welcoming when you design your cost levels in terms of
support and not product.

- "ActiveLua™"  is it ok to include the Lua name within your new
trademaked name?  Not a lawyer (and trademark law is even more
confusing than patents and copyrights) but again, it feels like trying
to stomp on the community.


Obviously, you already have experience in making money with Open
Source development communities.  I honestly hope all these
observations prove to be just a bad first impression and soon find you
a valuable member of the Lua community.



--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

KHMan
In reply to this post by Jeff Rouse
On 11/2/2016 3:07 AM, Jeff Rouse wrote:
>[snip]
> At ActiveState we have been in the open source tools and languages
> business (Python, Perl, Tcl) for almost 20 years. We also build
> developer tools, which are our Komodo Edit (open source) and IDE,
> which has basic Lua support, and we are actively making further
> Lua development improvements in those products.

As a contributor to the Scintilla edit control, I applaud
ActiveState's long history of contributing to that project, and
look forward to seeing more Lua developer tools appearing in the
market.

Most hardware hobbyists have yet to move to IoT/embedded hardware
with plenty of RAM and CPU power, but we're already seeing folks
impressed by trailblazers like nodeMCU. With plenty of CPU and
RAM, scripting and its attendant benefits can be embraced with
minimal downsides, just as the gaming industry has done. When AAA
games are built on game engines with scripting and all, they must
have hit on something right. Complex IoT can benefit from
productivity multipliers in the same way.

Although I have been updating Lua syntax highlighting for the
Scintilla edit control, I prefer to code old-school with a
bare-bones editor, so I will defer to others on the list on what
they wish for in IDEs or platforms. I also welcome contributions
upstream to improve Lua syntax highlighting for Scintilla, if
there are any in the course of ActiveState's work.

It's great to hear of such endeavours, looking forward to future
announcements!

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

KHMan
In reply to this post by Javier Guerra Giraldez
On 11/2/2016 5:17 PM, Javier Guerra Giraldez wrote:

> On 2 November 2016 at 07:21, Jeff Rouse <[hidden email]> wrote:
>>> Your site says: "Why take risks with open source Lua and community
>>> support".
>>> I don't see any risks in open source Lua. What do you have in mind?
>>>
>> The risks for an enterprise is that they need to make sure of issues
>> like getting timely support, a contractual obligation for service,
>> assurances and timely security fixes. In many cases they need
>> the backing of a commercial entity to feel comfortable and in
>> some cases this is a legal or compliance requirement. To
>> them it takes risk away. So its important for us to speak to
>> that. It in no way reflects on how the community supports
>> the language.
>
> Here's some feedback:
>
> - most of the language in the site feels confrontational; offering
> your distribution (and support) as an alternative, not a complement to
> the community.

I hope folks here can give ActiveState some slack, they are not a
huge entity like Red Hat stomping around, they need to promote and
sell the thingy to make it a viable business. There are different
considerations compared to, for example, someone like me
contributing to Scintilla in my free time.

True, if successful, it will impact existing distributions. IMHO,
as an old timer here I think we have too little resources to
maintain a vibrant distro like Perl or Python do. Most folks just
want binaries that work. If ActiveState is successful doing this,
they would have put in time and effort, so, good for them.

> - among your solutions, you list "ActiveLua Community Edition",
> "ActiveLua Business Edition", "ActiveLua Enterprise Edition".  When I
> see these "editions" list, I always have to wonder what each of these
> take away from the original and feel that the whole design is geared
> to make the most money.  Nothing bad in having solid business model,
> of course; but that means that if I choose to do any kind of
> interaction with such a company, I have to be on the defensive side.
> It's much more welcoming when you design your cost levels in terms of
> support and not product.

Businesses will pay to minimize risk, or businesses can instead
roll their own from an open source Lua distro. I think there is no
risk of lock-in. IMHO there won't be a huge community depending on
a single Lua distro vulnerable to lock-in; IoT/embedded platforms,
Lua in apps, modding games with Lua, Lua distros, there is no
big-fat-all-in-one. Say if you don't want ActivePerl, there is
Strawberry Perl, or just use the perl in Cygwin. That said, if one
is suspicious, try "activeperl rant" on Google, nothing there at
all...

> - "ActiveLua™"  is it ok to include the Lua name within your new
> trademaked name?  Not a lawyer (and trademark law is even more
> confusing than patents and copyrights) but again, it feels like trying
> to stomp on the community.

If "Lua" is not trademarked I don't see how this is like stomping.
It's the US of A, a lawyers' paradise, companies need to do these
things...

I am not trying to do cheerleading for ActiveState, just giving my
2 cents so that perhaps there will be a better balanced discussion
going forward.

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Frank Kastenholz-2
In reply to this post by Jeff Rouse
 
 
Hi

A couple of thoughts on this topic

The base Lua distribution from PUC-Rio has a number of extremely valuable
properties as it comes from PUC-Rio.  If, in the process of adding commercial
support (which is A Very Good Thing), you end up reducing or eliminating those
benefits, it would be A Very Very Bad Thing.  

For the project that I recently finished, our end customer was very unsure about
us using Lua ... they were so unsure about it that it went to very high management
levels and I ended up making a whole lot of "why Lua is Good" slides (can't share
them, sorry).  Anyway, some of the good things (that should not be lost) are

- PUC-Rio Lua is extremely stable and seems extremely bug free. The low number of
  releases, along with the low number of follow-on bug-fix releases and the low number
  of bugs they fix in each (which fixes all known bugs) attest to this. In my customer's
  environment, the software-update-rate is measured in years, so never-ending streams of
  bug fixes would be Bad.  

- The VM in PUC-Rio Lua is pretty safe (or can easily be made so by removing a few
  Lua-callable functions like "os.execute").  

- PUC-Rio Lua is small.  Code space for Lua is O(300KB) ...and today, "Kilobytes" often
  are considered rounding errors. Any added libraries, functions, etc, should keep this
  in mind and not bloat it.  The environment where the software I develop runs measures
  memory in 10's of MB, and my customer is considering migrating things to smaller
  devices which might be <5MB, possibly less than 1MB.

  I realize that adding things adds to memory requirements ... but if you could make your
  extensions optional at build time, that would be really cool.

- All The World Is Not Linux, nor is it even Posix (nor Windows nor OSX...).  
  Again, PUC-Rio's Lua has very few, if any, requirements on the underlying OS.
  C99 is a reasonable level of requirement on the underlying system. C++ would
  be really bad -- both from a portability perspective and a memory requirement
  perspective.

  One important thing here is that including object-code extensions as "libxxx.so"
  is not always useful. It presumes that the underlying OS has a dynamic linking
  ability. It may not.  At the very least, there should be an option to build the
  extensions directly into the executables (or be able to package the individual
  object files with the base Lua).

  Another thought --- the underlying "OS" might not even have a useful file system
  in which you can store extension_module.lua ... so how about a build option to
  take extension_module.lua, wrap it in C as a big string, and hard-compiling it in?

- The current license for Lua and most, if not all, extensions, is perfect.  GNU licenses,
  for my environment and customer, are extremely limiting, if not completely
  unsuitable.  This includes the LGPL.

I realize this isn't a "add feature XYZ" list, but to be honest, Lua is pretty good as it
is.  

Frank Kastenholz


Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Luiz Henrique de Figueiredo
> - The VM in PUC-Rio Lua is pretty safe (or can easily be made so by removing a few
>   Lua-callable functions like "os.execute").  

For the record, functions like "os.execute" are library functions,
not part of the VM.

>   At the very least, there should be an option to build the
>   extensions directly into the executables (or be able to package the individual
>   object files with the base Lua).

This is the purpose of linit.c. Just copy and edit it.

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Dibyendu Majumdar
In reply to this post by Jeff Rouse
On 2 November 2016 at 07:21, Jeff Rouse <[hidden email]> wrote:

> On Tue, Nov 1, 2016 at 12:16 PM, Luiz Henrique de Figueiredo
> <[hidden email]> wrote:
>> Your site says: "Why take risks with open source Lua and community
>> support".
>> I don't see any risks in open source Lua. What do you have in mind?
>>
> The risks for an enterprise is that they need to make sure of issues
> like getting timely support, a contractual obligation for service,
> assurances and timely security fixes. In many cases they need
> the backing of a commercial entity to feel comfortable and in
> some cases this is a legal or compliance requirement. To
> them it takes risk away. So its important for us to speak to
> that. It in no way reflects on how the community supports
> the language.
>

I remember working at an organization that would not use opensource
because they needed someone they could go to for support. But that was
10 years ago - things have changed a lot now, and most companies I
know happily use opensource tools / languages.

Lua itself (including its standard libraries) virtually needs no
support as it is mature, stable and almost bug free.

The thing that may be useful if someone 'supported' a bunch of extra
libraries for Lua, and ensured that these were kept up to date and in
sync with Lua releases, and provided consistent distributions across
major platforms. By support here I mean actually fixing issues and
problems faced by customers.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Russell Haley
The Lua community has been excellent and once I found luarocks I was off to the races.

I do see value proposition in tool chain integration and development stack maintenance. This would include ‎ide, process automation and source management, as well as package testing and integration as noted previously. However, all these tools are already present and quite well supported.

Essentially anything that would take time for a developer to do that is not part of writing the line of business software they are supposed to be working on would provide value for a customer. ‎Not everyone wants to be on a lua mailing list (though I don't know why they wouldn't).

I like scintilla. I'm glad to hear they support it. Anyone care to bring scite up to lua 5.3?

;)
Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Dibyendu Majumdar
Sent: Wednesday, November 2, 2016 7:45 AM
To: Lua mailing list
Reply To: Lua mailing list
Subject: Re: ActiveState seeking Lua community feedback

On 2 November 2016 at 07:21, Jeff Rouse <[hidden email]> wrote:

> On Tue, Nov 1, 2016 at 12:16 PM, Luiz Henrique de Figueiredo
> <[hidden email]> wrote:
>> Your site says: "Why take risks with open source Lua and community
>> support".
>> I don't see any risks in open source Lua. What do you have in mind?
>>
> The risks for an enterprise is that they need to make sure of issues
> like getting timely support, a contractual obligation for service,
> assurances and timely security fixes. In many cases they need
> the backing of a commercial entity to feel comfortable and in
> some cases this is a legal or compliance requirement. To
> them it takes risk away. So its important for us to speak to
> that. It in no way reflects on how the community supports
> the language.
>

I remember working at an organization that would not use opensource
because they needed someone they could go to for support. But that was
10 years ago - things have changed a lot now, and most companies I
know happily use opensource tools / languages.

Lua itself (including its standard libraries) virtually needs no
support as it is mature, stable and almost bug free.

The thing that may be useful if someone 'supported' a bunch of extra
libraries for Lua, and ensured that these were kept up to date and in
sync with Lua releases, and provided consistent distributions across
major platforms. By support here I mean actually fixing issues and
problems faced by customers.

Regards
Dibyendu


Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Russell Haley
In reply to this post by KHMan
On Wed, Nov 2, 2016 at 2:56 AM, KHMan <[hidden email]> wrote:

> On 11/2/2016 3:07 AM, Jeff Rouse wrote:
>>
>> [snip]
>> At ActiveState we have been in the open source tools and languages
>> business (Python, Perl, Tcl) for almost 20 years. We also build
>> developer tools, which are our Komodo Edit (open source) and IDE,
>> which has basic Lua support, and we are actively making further
>> Lua development improvements in those products.
>
>
> As a contributor to the Scintilla edit control, I applaud ActiveState's long
> history of contributing to that project, and look forward to seeing more Lua
> developer tools appearing in the market.
>
> Most hardware hobbyists have yet to move to IoT/embedded hardware with
> plenty of RAM and CPU power, but we're already seeing folks impressed by
> trailblazers like nodeMCU.
OMG. WANT!

With plenty of CPU and RAM, scripting and its
> attendant benefits can be embraced with minimal downsides, just as the
> gaming industry has done. When AAA games are built on game engines with
> scripting and all, they must have hit on something right. Complex IoT can
> benefit from productivity multipliers in the same way.

Using lua-http and cqueues I've so far been able to produce a small
IoT proof of concept in a few months at night. The memory usage isn't
where I want it to be right now, but Lua has done exactly what it's
supposed to do: wrap other languages so I don't have to learn them. I
haven't written a lick of C yet and I have a fully polled and threaded
application. Debian and FreeBSD support. Websocket or HTTP, TLS
support, file polling, GPIO (work in progress on FreeBSD). Interrupt
handling is (hopefully) next.

I was hoping to support something small like an M4 or a little PIC,
but I don't know if that's going to be possible. That's a different
post that I'll get to later this week. :)

https://github.com/daurnimator/lua-http
http://www.25thandclement.com/~william/projects/cqueues.html

https://github.com/RussellHaley/lua-http-endpoints (currently broken)

Cheers,

Russ

> Although I have been updating Lua syntax highlighting for the Scintilla edit
> control, I prefer to code old-school with a bare-bones editor, so I will
> defer to others on the list on what they wish for in IDEs or platforms. I
> also welcome contributions upstream to improve Lua syntax highlighting for
> Scintilla, if there are any in the course of ActiveState's work.
>
> It's great to hear of such endeavours, looking forward to future
> announcements!
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Selangor, Malaysia
>
>

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Emeka
In reply to this post by Jeff Rouse

JR ,

Why not build your own language and throw it to the world instead of painting Lua as a risk at same time you want to run a business off it.  You make the works of this community look trivial because you want to patch up a new distro.

Janus


On Nov 2, 2016 8:22 AM, "Jeff Rouse" <[hidden email]> wrote:
Hi Luiz, thanks for taking the time to respond.

On Tue, Nov 1, 2016 at 12:16 PM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> I'm proud to say that in 2017, we will be providing a community-
> and enterprise-ready Lua distribution on a variety of platforms,
> shaped in part by the feedback we receive from the community.

Very nice.
Perhaps you could give more details on what your Lua distribution is.
Does it include external libraries and tools? If so, which ones?

We will most definitely be shipping more than just the distribution, as 
we want to add as much value as we can. We often ship more than
just the standard libraries in our distros, as this makes it easiest for
people to use them. This does require some balance as we typically
don't like to start supporting a external library and then have to remove it
later due to maintenance or security issues, so we have to be choosy.

This is one of the reasons we are reaching out in order to get some
feedback on what a fantastic distribution would look
like from your perspective.

In addition any areas that the community could use our help, we would
love to hear about, as we view this as much more than a business

 
Your site says: "Why take risks with open source Lua and community support".
I don't see any risks in open source Lua. What do you have in mind?

The risks for an enterprise is that they need to make sure of issues
like getting timely support, a contractual obligation for service,
assurances and timely security fixes. In many cases they need
the backing of a commercial entity to feel comfortable and in 
some cases this is a legal or compliance requirement. To
them it takes risk away. So its important for us to speak to
that. It in no way reflects on how the community supports
the language.


Cheers,
-JR

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Mason Bogue
In reply to this post by Russell Haley
>If you would like to ask any questions or provide thoughts on where we can best help the Lua community

The biggest weakness of the Lua community is probably fragmentation,
so one of the best ways that you can help the community is by working
with the other people in your space. There are a number of "standard
library" attempts:

For PUC Lua:
http://luadist.org/

For LuaJIT:
http://luapower.org/
http://torch.ch/

LuaRocks (http://luarocks.org/) is probably the most important Lua
module system, so of course your product must work with LuaRocks. In
addition to that it could help to discuss with the maintainers of the
above projects how you can support using those distributions in your
IDE (Torch is huge; the other two should be easy).

There are a couple of frameworks for Lua that are popular; one of the
most important projects for hobbyists is LÖVE, which is used for
making little indie games (I think of it as a better Flash but without
the convenience of NPAPI):

http://love2d.org/

There are a lot of other game development frameworks that use Lua, of
course; There are also two (I think only two?) significant Lua web
frameworks:
http://leafo.net/lapis
http://sailorproject.org/
Particularly the latter seems to be tilted towards ease-of-use and so
they would probably be happy to have an IDE that had good support for
it, although whether the project is really ready for that kind of
investment on your part isn't my judgment call.

There are also two significant GUI frameworks, of which Qt Lua is
probably more significant:
http://github.com/torch/qtlua -- binding to Qt (LGPL)
http://github.com/peersuasive/luce -- binding to JUCE (a
GPL-or-commercial product which apparently makes money)
I think the people behind these would be happy to hear from you.

Lua has always had multithreading support, but parallelism in pure Lua
requires the use of an external library. Debugging parallel Lua
programs written with those libraries requires more work on the part
of the debugger than debugging vanilla Lua. The most important
concurrency solutions for Lua are:

http://github.com/askyrme/luaproc
http://cmr.github.io/lanes
http://github.com/torch/threads (integrated into the torch7 library)

Having the IDE actually work with these is a major advantage.
Debugging parallel code is pretty hard, so being able to do it is very
nice.

The other thing that comes to mind is that there is a pretty large
fraction of Lua users who primarily communicate in Portuguese (the
language is from Brazil) and there is also some significant adoption
of Lua by Chinese-speaking users, and supporting those languages would
probably be good for both your marketshare and the community as a
whole.

Anyway there's a lot you can do. You're not the first to try to bring
order to the Lua universe -- just try to be the best.

-Mason

On Wed, Nov 2, 2016 at 9:52 AM, Russell Haley <[hidden email]> wrote:

> On Wed, Nov 2, 2016 at 2:56 AM, KHMan <[hidden email]> wrote:
>> On 11/2/2016 3:07 AM, Jeff Rouse wrote:
>>>
>>> [snip]
>>> At ActiveState we have been in the open source tools and languages
>>> business (Python, Perl, Tcl) for almost 20 years. We also build
>>> developer tools, which are our Komodo Edit (open source) and IDE,
>>> which has basic Lua support, and we are actively making further
>>> Lua development improvements in those products.
>>
>>
>> As a contributor to the Scintilla edit control, I applaud ActiveState's long
>> history of contributing to that project, and look forward to seeing more Lua
>> developer tools appearing in the market.
>>
>> Most hardware hobbyists have yet to move to IoT/embedded hardware with
>> plenty of RAM and CPU power, but we're already seeing folks impressed by
>> trailblazers like nodeMCU.
> OMG. WANT!
>
> With plenty of CPU and RAM, scripting and its
>> attendant benefits can be embraced with minimal downsides, just as the
>> gaming industry has done. When AAA games are built on game engines with
>> scripting and all, they must have hit on something right. Complex IoT can
>> benefit from productivity multipliers in the same way.
>
> Using lua-http and cqueues I've so far been able to produce a small
> IoT proof of concept in a few months at night. The memory usage isn't
> where I want it to be right now, but Lua has done exactly what it's
> supposed to do: wrap other languages so I don't have to learn them. I
> haven't written a lick of C yet and I have a fully polled and threaded
> application. Debian and FreeBSD support. Websocket or HTTP, TLS
> support, file polling, GPIO (work in progress on FreeBSD). Interrupt
> handling is (hopefully) next.
>
> I was hoping to support something small like an M4 or a little PIC,
> but I don't know if that's going to be possible. That's a different
> post that I'll get to later this week. :)
>
> https://github.com/daurnimator/lua-http
> http://www.25thandclement.com/~william/projects/cqueues.html
>
> https://github.com/RussellHaley/lua-http-endpoints (currently broken)
>
> Cheers,
>
> Russ
>
>> Although I have been updating Lua syntax highlighting for the Scintilla edit
>> control, I prefer to code old-school with a bare-bones editor, so I will
>> defer to others on the list on what they wish for in IDEs or platforms. I
>> also welcome contributions upstream to improve Lua syntax highlighting for
>> Scintilla, if there are any in the course of ActiveState's work.
>>
>> It's great to hear of such endeavours, looking forward to future
>> announcements!
>>
>> --
>> Cheers,
>> Kein-Hong Man (esq.)
>> Selangor, Malaysia
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

V S P
In reply to this post by Jeff Rouse
Hello,
thank you for asking.
I felt lack of Enterprise-ready Lua distribution is limiting lua from wider acceptance.
Great that you are coming up with the model.

I can suggest to organize the packaging by industrydomain + Lua containment type

Containment type is:  Software Embedded , Hardware/firmware Embedded, Stand alone
Industry domain (example):  consumer devices, transportation, financial services,  etc. where industry domain guides the packaging, testing and support of industry relevant modules (and may be allows for more industry centric ecosystem for contribution/sharing/dependency management)


In the Software Embedded containment type, the distribution to concentrate on making lua and related modules accessible from variey of technical stacks
(eg .NET, native, .JVM), being able to work with data management platforms where Lua scripts are first-class citizens (eg Redis, Postgres, a couple others)

In the hardware/firmware embedded, it is about minimizing dependencies, insuring tight control/versioning, remote debugging

In the Stand alone, the emphasis should be on supporting UIs, installation simplicity, etc


VSP

On Tue, Nov 1, 2016, at 03:07 PM, Jeff Rouse wrote:

Hi all,


At ActiveState we feel Lua has a bright future in a variety of application areas (IoT, embedded scripting, and many others), and we are looking for ideas on how to support the community, increase adoption and help enterprises utilize the language more effectively. I’m proud to say that in 2017, we will be providing a community- and enterprise-ready Lua distribution on a variety of platforms, shaped in part by the feedback we receive from the community.


At ActiveState we have been in the open source tools and languages business (Python, Perl, Tcl) for almost 20 years. We also build developer tools, which are our Komodo Edit (open source) and IDE, which has basic Lua support, and we are actively making further Lua development improvements in those products.


If you would like to ask any questions or provide thoughts on where we can best help the Lua community, feel free to respond to this thread, email me, or sign up to our mail list (http://www.activestate.com/lua) for advanced notice of when our distribution is available. We look forward to hearing from you!

Cheers,
-JR

-- 
http://www.fastmail.com - The way an email service should be
Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Russell Haley
In reply to this post by Javier Guerra Giraldez
On Wed, Nov 2, 2016 at 2:17 AM, Javier Guerra Giraldez
<[hidden email]> wrote:

> On 2 November 2016 at 07:21, Jeff Rouse <[hidden email]> wrote:
>>> Your site says: "Why take risks with open source Lua and community
>>> support".
>>> I don't see any risks in open source Lua. What do you have in mind?
>>>
>> The risks for an enterprise is that they need to make sure of issues
>> like getting timely support, a contractual obligation for service,
>> assurances and timely security fixes. In many cases they need
>> the backing of a commercial entity to feel comfortable and in
>> some cases this is a legal or compliance requirement. To
>> them it takes risk away. So its important for us to speak to
>> that. It in no way reflects on how the community supports
>> the language.
>
>
> Here's some feedback:
>
> - most of the language in the site feels confrontational; offering
> your distribution (and support) as an alternative, not a complement to
> the community.

>From your page http://www.activestate.com/lua :

"ActiveLua OEM Edition takes the complexity out of open source
licensing by guaranteeing assurance and eliminating legal risk that
goes along with distributing Lua in commercial applications."

This is patently incorrect. There is no licensing risk in using Lua in
a commercial application due to the broad (and almost uniform) use of
MIT and permissive licenses in the Lua community. I think I speak for
everyone in saying you should change this and remove any implication
that licensing Lua software carries risk. While you may offer clients
the service of navigating complex licensing, Lua should not be
directly referenced as carrying any legal risk.

Also, I believe one reason for a "confrontational" feel is due to a
lack of any indication that Lua is in fact extremely business
friendly. You have not provided any positive attributions to using Lua
in a commercial environment and one would get the feeling that it
would be similar to using GPL and copy-left software. Again, the use
of an MIT license allows commercial applications the ability to create
proprietary extensions and embed Lua into their software WITH ZERO
LICENSING RISK. It's my opinion that you would make the community feel
more comfortable by changing from "OMG License risks!" to "No License
Risks, great software and we have the latest toolchains prebuilt for
you!". It is also a smart business case to encourage businesses to use
a software you support.


Regards,

Russ  (And I didn't even rant once about GPL!)

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Andrew Starks-2

On Thu, Nov 3, 2016 at 11:16 Russell Haley <[hidden email]> wrote:
On Wed, Nov 2, 2016 at 2:17 AM, Javier Guerra Giraldez
<[hidden email]> wrote:
> On 2 November 2016 at 07:21, Jeff Rouse <[hidden email]> wrote:
>>> Your site says: "Why take risks with open source Lua and community
>>> support".
>>> I don't see any risks in open source Lua. What do you have in mind?
>>>
>> The risks for an enterprise is that they need to make sure of issues
>> like getting timely support, a contractual obligation for service,
>> assurances and timely security fixes. In many cases they need
>> the backing of a commercial entity to feel comfortable and in
>> some cases this is a legal or compliance requirement. To
>> them it takes risk away. So its important for us to speak to
>> that. It in no way reflects on how the community supports
>> the language.
>
>
> Here's some feedback:
>
> - most of the language in the site feels confrontational; offering
> your distribution (and support) as an alternative, not a complement to
> the community.

>From your page http://www.activestate.com/lua :

"ActiveLua OEM Edition takes the complexity out of open source
licensing by guaranteeing assurance and eliminating legal risk that
goes along with distributing Lua in commercial applications."

This is patently incorrect. There is no licensing risk in using Lua in
a commercial application due to the broad (and almost uniform) use of
MIT and permissive licenses in the Lua community. I think I speak for
everyone in saying you should change this and remove any implication
that licensing Lua software carries risk. While you may offer clients
the service of navigating complex licensing, Lua should not be
directly referenced as carrying any legal risk.

Also, I believe one reason for a "confrontational" feel is due to a
lack of any indication that Lua is in fact extremely business
friendly. You have not provided any positive attributions to using Lua
in a commercial environment and one would get the feeling that it
would be similar to using GPL and copy-left software. Again, the use
of an MIT license allows commercial applications the ability to create
proprietary extensions and embed Lua into their software WITH ZERO
LICENSING RISK. It's my opinion that you would make the community feel
more comfortable by changing from "OMG License risks!" to "No License
Risks, great software and we have the latest toolchains prebuilt for
you!". It is also a smart business case to encourage businesses to use
a software you support.


Regards,

Russ  (And I didn't even rant once about GPL!)


Russ,

First, you don't speak for everyone on this list. I think you meant something much less emotionally charged there, but I won't guess.

It's good to remember that marketing people tend to use emotionally charged language, just as you are doing and amongst technical people who know better it has the same predictable result.

It is fine if you want to try to right this wrong, likely committed by an overzealous, non-technocrat who wants to compel IT managers to fork over cash by "stretching the truth".

To illustrate their challenge, consider that one way to say what they are trying to say is: "If you end up having a problem with Lua or it's extremely liberal license (both unlikely), we can be the neck that you ring!"

That is a valid reason and it might be a good enough reason for them to choose ActiveState. But it's also unlikely to compel a manager that may look at all "free as in beer" software as "something that has to go through an internally painful review process."

-Andrew
Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Peter Hickman-3
There is also the outcome that the manager see it and goes "I thought so, this open software has - complexity of open source licensing - big problems that require us to pay a 3rd party to mitigate. But who are this ActiveState anyway, never heard of them before. Probably just some scammers trying to rip us off. Besides I will have to get this past legal to make sure we are covered for the problems that open source licensing has and make sure that this 2bit operation called ActiveState wont disappear when the problems arise"

Gee ActiveState, thanks for helping out.
Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Russell Haley
In reply to this post by Andrew Starks-2
On Thu, Nov 3, 2016 at 9:37 AM, Andrew Starks <[hidden email]> wrote:

>
> On Thu, Nov 3, 2016 at 11:16 Russell Haley <[hidden email]> wrote:
>>
>> On Wed, Nov 2, 2016 at 2:17 AM, Javier Guerra Giraldez
>> <[hidden email]> wrote:
>> > On 2 November 2016 at 07:21, Jeff Rouse <[hidden email]> wrote:
>> >>> Your site says: "Why take risks with open source Lua and community
>> >>> support".
>> >>> I don't see any risks in open source Lua. What do you have in mind?
>> >>>
>> >> The risks for an enterprise is that they need to make sure of issues
>> >> like getting timely support, a contractual obligation for service,
>> >> assurances and timely security fixes. In many cases they need
>> >> the backing of a commercial entity to feel comfortable and in
>> >> some cases this is a legal or compliance requirement. To
>> >> them it takes risk away. So its important for us to speak to
>> >> that. It in no way reflects on how the community supports
>> >> the language.
>> >
>> >
>> > Here's some feedback:
>> >
>> > - most of the language in the site feels confrontational; offering
>> > your distribution (and support) as an alternative, not a complement to
>> > the community.
>>
>> >From your page http://www.activestate.com/lua :
>>
>> "ActiveLua OEM Edition takes the complexity out of open source
>> licensing by guaranteeing assurance and eliminating legal risk that
>> goes along with distributing Lua in commercial applications."
>>
>> This is patently incorrect. There is no licensing risk in using Lua in
>> a commercial application due to the broad (and almost uniform) use of
>> MIT and permissive licenses in the Lua community. I think I speak for
>> everyone in saying you should change this and remove any implication
>> that licensing Lua software carries risk. While you may offer clients
>> the service of navigating complex licensing, Lua should not be
>> directly referenced as carrying any legal risk.
>>
>> Also, I believe one reason for a "confrontational" feel is due to a
>> lack of any indication that Lua is in fact extremely business
>> friendly. You have not provided any positive attributions to using Lua
>> in a commercial environment and one would get the feeling that it
>> would be similar to using GPL and copy-left software. Again, the use
>> of an MIT license allows commercial applications the ability to create
>> proprietary extensions and embed Lua into their software WITH ZERO
>> LICENSING RISK. It's my opinion that you would make the community feel
>> more comfortable by changing from "OMG License risks!" to "No License
>> Risks, great software and we have the latest toolchains prebuilt for
>> you!". It is also a smart business case to encourage businesses to use
>> a software you support.
>>
>>
>> Regards,
>>
>> Russ  (And I didn't even rant once about GPL!)
>>
>
> Russ,
>
> First, you don't speak for everyone on this list. I think you meant
> something much less emotionally charged there, but I won't guess.
I don't think there was any emotional charge there? Everyone who wants
your MIT licensed software portrayed as a legal risk please contact me
and I will retract my statement.

Russ

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Andrew Starks-2
In reply to this post by Peter Hickman-3
On Thu, Nov 3, 2016 at 12:02 PM, Peter Hickman
<[hidden email]> wrote:

> There is also the outcome that the manager see it and goes "I thought so,
> this open software has - complexity of open source licensing - big problems
> that require us to pay a 3rd party to mitigate. But who are this ActiveState
> anyway, never heard of them before. Probably just some scammers trying to
> rip us off. Besides I will have to get this past legal to make sure we are
> covered for the problems that open source licensing has and make sure that
> this 2bit operation called ActiveState wont disappear when the problems
> arise"
>
> Gee ActiveState, thanks for helping out.


And now it's time for all of us to wonder aloud, "Why doesn't Lua see
wide spread adoption?"

It sounds like ActiveState is not for you?

Dear Jeff,

Thank you for taking an interest in the Lua community. As you can see,
there is broad and lively interest in this awesome, simple language.
As you may have picked up, there is some concern about the tone of
some of the points made in your marketing, at least amongst those that
have been using Lua for quite a while. My hope is that these responses
don't discourage you from including Lua in your portfolio of
solutions.

I also hope that, in spite of some rude ways in which the messages
were delivered, you might consider taking the essence of those
concerns and address them. I'm sure that there is a  way to
communicate the real and important value that ActiveState is providing
while making sure not to imply something that isn't true about the
core Lua distribution or its licensing.

If you believe that your marketing materials are fairly portraying
real short comings in Lua, then everyone would benefit from a
clarification of those points. I would imagine that it would be good
material for your potential customers to review, as well.

All the best!

--
Andrew Starks
612 840 2939
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ActiveState seeking Lua community feedback

Andrew Starks-2
Sorry for the double post. I should not have said "Lua hasn't seen
wide spread adoption."

I meant to say something more like "Lua hasn't seen the kind of growth
and popularity that many of us think it should have..."

Sorry for the noise. I just want to be precise when participating in a
flame war. ;)

-Andrew

123