1) Commercial uptake, with an ongoing upwards growth trend
2) Thriving community of developers, with an ongoing upwards trend.
3) A platform with sufficient stability for commercial use, to provide 1)
4) A platform with sufficient stability for adequate documentation, that leads to sufficient levels of interest to provide 1) and 2)
Here is the vision of the leader of the Pharo project (who is also the head of the European Smalltalk User Group)
the ultimate live environment
a great reflective system
a system well integrated with C
a system well integrated with OSes
a wonderful IDE
In my world view, it is possible for my both visions to be congruent. It is not a given that they are - unless careful attention is paid to both.
So let's see what's what.
Say we had:
the ultimate live environment - that <100 people use
a great reflective system - that <100 people use
a system well integrated with C - that <100 people use
a system well integrated with OSes - that <100 people use
a wonderful IDE - that less than 100 people use.
Would that be a fulfillment of anyone's vision?
The number of users (commercial organisations and individual hobby/student/academic developers) matters - because without a sufficiently large group, the velocity towards realisation of a vision does not keep up with events.
Because of the network effect, the two visions need to be complementary to succeed. In a world full of the network effect, two small items are *disproportionately* less useful than a single item twice the size. And currently developer mindshare for FOSS Smalltalk is split more-or-less in two. We need to unite as often and as much as possible - at least until our community is large enough to have the luxury of becoming different communities.
In the current dialectic, size of community and commonalities between closely-related communities are irrelevant.
However, at best, Pharo is currently a distro of Smalltalk.
It's a fat distro - a very fat distro, definitely the fattest one I use by more than a factor of 2. But it's simply the Kubuntu to Cuis's PuppyLinux.
It uses the same syntax as the other Smalltalks.
It uses the same VM as the other Smalltalks.
It uses the same core classes as other Smalltalks.
Many of its additional classes are ports from other Smalltalks.
What's the old saying? If it looks like a duck, and it quacks like a duck - it's a duck.
The key substantial difference it has over other Smalltalks is the additional Classes. Currently mainly from PhD theses being added into the class libraries. Plus an ongoing effort to port initiatives from other Smalltalks into the Pharo Class hierarchy.
Demanding that it be always and only be considered its own unique thing completely separately from other things just splits the community in two.
Most of the wins claimed for Pharo in the first several years of its life were from elsewhere - Squeak and VisualWorks. So many of the successes listed for Pharo have simply been simply ports of pre-existing software, rather than anything new and unique.
Many of Pharo's substantial and numerous additional classes it has over when it started are either
- minority academic facilities
- insufficiently documented to be used by people other than the package developers
- have a stability half-life of about 18 months.
This last point matters.
For example. DBXTalk. Go to Stack Overflow and search for Pharo and SQL.
You get told about DBXTalk and pointed to the package's homepage. Which until yesterday was a dead link. (I've just fixed it) Until I fixed it, this gives the impression that the package is dead. And that if you want to do something as basic as link Pharo to MySQL you're going to have to roll-your-own solution. (Which is not true!).
Even going to the new link is confusing, if you are arrive expecting to to use dbxtalk. You then get pointed to two different packages, Garage and .. can't remember. Neither of them have a self-descriptive name. Self-descriptive names like like DBXTalk are meaningful and are memorable beacause of their meaningfulness. DBXTalk is fairly obviously a DB Xover for Smalltalk)
If we want Pharo to succeed as a commercial-grade platform,
1) we need to grow the userbase
============================
And by 'userbase' I mean commercially-successful organisations which find Smalltalk compelling enough to use that they keep it in their tools portfolio.
(Please bear in mind that Ericsson created erlang and had a product portfolio which was internally reliant on erlang. And the were still going to drop erlang from its toolset at one point - because they feared the community was too small for it to survive in the long run. Just because a product has some powerful advantages does not mean that it is a compelling choice for an organisation in the long run).
Even better, it should be compelling enough to be adopted *into* their tools portfolio.
And if we can't be adopted into existing organisations' toolkits, we need to be capable of generating new commercially-strong organisations that have successfully used Pharo in their toolkit from day 1. And continued to use Pharo once they have grown larger.
2) we need to grow the developer-base
===================================
The key problems:
==============
Growing the user-base in the absence of a thriving developer base is hard.
Growing the developer-base in the absence of a thriving user-base is hard.
This is a Chicken-and-egg problem. There's a long (but lively!) explanation of just how hard it is and why, see http://www.joelonsoftware.com/articles/fog0000000054.html
- we need to have a breadcrumb trail from
"don't know about it" to
"potentially interested in it" to
"actively interested in it" to
"able to try it" to
"finding something compellingly useful about it" to
"having a sufficiently documented, sufficiently stable, set of facilities that people develop with" to
"having a sufficiently stable set of facilities that things created using them keep working and working and working"
This is true both for developers, and for commercial users.
The answer "I have done this, and so have 3 dozen other people" is not an indication of success in this matter.
One single university in the UK produced 5,000 people trained to use Smalltalk each and every year, year after year.
Without commercial visibility of Smalltalk's use, they each stopped being able to use Smalltalk within a year. (Mind you, they found picking up Java and JavaScript and Ruby and OO Python much easier, so they still gained personally, despite being lost to the Samlltalk community/ies.)
We have already lost the battle against Lua. Against Python. Against Ruby. We were never in the running against JavaScript.
(although there is a mathematically non-zero chance that Amber might beat out jQuery, Angular etc as the way to approach JavaScript. In the same way that Scotland has a mathematically non-zero chance of winning the next FIFA World Cup)
In a world of network effects, splitting the community makes us weaker, not stronger.
In a world where Pharo syntax is Smalltalk syntax, in a world where the Pharo VM is the Smalltalk VM, in a world where Pharo's base 500 classes are everyone else's 500 base Smalltalk classes, Pharo is Smalltalk. And great speakers do get invited to speak about a Smalltalk distro. (I'm presuming because they are a great speaker, and because they have something interesting to say about Pharo's numerous and large extensions to the core distro. They are not being invited because they are working in a new language. And alas, it's certainly not because they are working on something that is growing a userbase and growing a developerbase).
Let's grow our community. Let's embrace the network effect. Let's do this as a Smalltalk community - all the various strands and sub-groups - and do this in concert, together.
Because of the network effect, the two visions need to be complementary to succeed. In a world full of the network effect, two small items are *disproportionately* less useful than a single item twice the size. And currently developer mindshare for FOSS Smalltalk is split more-or-less in two. We need to unite as often and as much as possible - at least until our community is large enough to have the luxury of becoming different communities.
In the current dialectic, size of community and commonalities between closely-related communities are irrelevant.
However, at best, Pharo is currently a distro of Smalltalk.
It's a fat distro - a very fat distro, definitely the fattest one I use by more than a factor of 2. But it's simply the Kubuntu to Cuis's PuppyLinux.
It uses the same syntax as the other Smalltalks.
It uses the same VM as the other Smalltalks.
It uses the same core classes as other Smalltalks.
Many of its additional classes are ports from other Smalltalks.
What's the old saying? If it looks like a duck, and it quacks like a duck - it's a duck.
The key substantial difference it has over other Smalltalks is the additional Classes. Currently mainly from PhD theses being added into the class libraries. Plus an ongoing effort to port initiatives from other Smalltalks into the Pharo Class hierarchy.
Demanding that it be always and only be considered its own unique thing completely separately from other things just splits the community in two.
Most of the wins claimed for Pharo in the first several years of its life were from elsewhere - Squeak and VisualWorks. So many of the successes listed for Pharo have simply been simply ports of pre-existing software, rather than anything new and unique.
- minority academic facilities
- insufficiently documented to be used by people other than the package developers
- have a stability half-life of about 18 months.
This last point matters.
For example. DBXTalk. Go to Stack Overflow and search for Pharo and SQL.
You get told about DBXTalk and pointed to the package's homepage. Which until yesterday was a dead link. (I've just fixed it) Until I fixed it, this gives the impression that the package is dead. And that if you want to do something as basic as link Pharo to MySQL you're going to have to roll-your-own solution. (Which is not true!).
Even going to the new link is confusing, if you are arrive expecting to to use dbxtalk. You then get pointed to two different packages, Garage and .. can't remember. Neither of them have a self-descriptive name. Self-descriptive names like like DBXTalk are meaningful and are memorable beacause of their meaningfulness. DBXTalk is fairly obviously a DB Xover for Smalltalk)
If we want Pharo to succeed as a commercial-grade platform,
1) we need to grow the userbase
============================
And by 'userbase' I mean commercially-successful organisations which find Smalltalk compelling enough to use that they keep it in their tools portfolio.
(Please bear in mind that Ericsson created erlang and had a product portfolio which was internally reliant on erlang. And the were still going to drop erlang from its toolset at one point - because they feared the community was too small for it to survive in the long run. Just because a product has some powerful advantages does not mean that it is a compelling choice for an organisation in the long run).
Even better, it should be compelling enough to be adopted *into* their tools portfolio.
And if we can't be adopted into existing organisations' toolkits, we need to be capable of generating new commercially-strong organisations that have successfully used Pharo in their toolkit from day 1. And continued to use Pharo once they have grown larger.
2) we need to grow the developer-base
===================================
The key problems:
==============
Growing the user-base in the absence of a thriving developer base is hard.
Growing the developer-base in the absence of a thriving user-base is hard.
This is a Chicken-and-egg problem. There's a long (but lively!) explanation of just how hard it is and why, see http://www.joelonsoftware.com/articles/fog0000000054.html
- we need to have a breadcrumb trail from
"don't know about it" to
"potentially interested in it" to
"actively interested in it" to
"able to try it" to
"finding something compellingly useful about it" to
"having a sufficiently documented, sufficiently stable, set of facilities that people develop with" to
"having a sufficiently stable set of facilities that things created using them keep working and working and working"
This is true both for developers, and for commercial users.
The answer "I have done this, and so have 3 dozen other people" is not an indication of success in this matter.
One single university in the UK produced 5,000 people trained to use Smalltalk each and every year, year after year.
Without commercial visibility of Smalltalk's use, they each stopped being able to use Smalltalk within a year. (Mind you, they found picking up Java and JavaScript and Ruby and OO Python much easier, so they still gained personally, despite being lost to the Samlltalk community/ies.)
We have already lost the battle against Lua. Against Python. Against Ruby. We were never in the running against JavaScript.
(although there is a mathematically non-zero chance that Amber might beat out jQuery, Angular etc as the way to approach JavaScript. In the same way that Scotland has a mathematically non-zero chance of winning the next FIFA World Cup)
In a world of network effects, splitting the community makes us weaker, not stronger.
In a world where Pharo syntax is Smalltalk syntax, in a world where the Pharo VM is the Smalltalk VM, in a world where Pharo's base 500 classes are everyone else's 500 base Smalltalk classes, Pharo is Smalltalk. And great speakers do get invited to speak about a Smalltalk distro. (I'm presuming because they are a great speaker, and because they have something interesting to say about Pharo's numerous and large extensions to the core distro. They are not being invited because they are working in a new language. And alas, it's certainly not because they are working on something that is growing a userbase and growing a developerbase).
Let's grow our community. Let's embrace the network effect. Let's do this as a Smalltalk community - all the various strands and sub-groups - and do this in concert, together.
No comments:
Post a Comment