New Project Name

We are at a point in this project where we need to find a new name for it.

The reason for this is that the name ‘VSPAT’, which was determined when this was a MS owned project, has not been well received in the broader community, and as project leads we have been discussing finding a new, more trendy name that people
could better identify with.

Now is the right time to rebrand, as the current release we are working on (1.3.20.0) has to change its code namespaces, cryptographic keys, and ownership details anyway. These are massive binary breaking changes, that will not be backwards compatible, which
would need to include the new project name and direction anyway.

We have already had several email discussions and dialog with a group of the closest interested parties of VSPAT and had some good ideas, but I would like to open that discussion to the broader VSPAT interest group, in the spirit of an open project, and
to reap fresh ideas.

I invite you to please participate in this discussion.

This is what we know at this point (trying to summarise a long email thread, and many discussions):

The original project name was ‘PLATU’ standing for Product Line, Authoring, Tailoring and Using. This was deliberately chosen to be an acronym rather than product name so we could remain flexible as the product evolved. As we built the product,
the Product Line emphasis fell away, but Authoring, Tailoring and Using are still part of the DNA of the project.

VSPAT stands for the "Visual Studio Pattern Automation Toolkit" – this brand was originally chosen as a product name to align the project with a MS product (VS2010) around the time the product was being released, to gain more attention.
This alignment is no longer as high priority as it used to be, due to the nature of the ownership of the project now, and the possible directions it could go. (i.e. cross-platform)

The new name of VSPAT should reflect the reasons ‘why’ you should be doing this kind of toolkit development (i.e. why you would want to build and use toolkits to begin with). The motivations behind doing it. It should focus on ‘why’
rather than ‘what’ or ‘how’ because VSPAT needs to *lead* the broader development/deployment audiences towards this new approach, which for many is a new approach and way of doing business. And many in the broader communities don’t
have such tools for this purpose, which is why (we think) they are not demanding them yet. So talking about the ‘what’ and ‘how’ would be referring to activities that most would not be familiar with right now anyway.

The name could either have a unique sounding name that is catchy, or could use some of the more trendy naming patterns of other successful development tools out there today (such as: N* or Nu*, or *.Net, etc.)

The new name should be uniquely identifiable in an internet search. Any other ‘near’ search results that come up for the name should not contradict the objectives or approaches of VSPAT.

The name should be short, say lest than 15 characters, so it is not a mouthful to say repeatedly in a presentation, and ideally not subject to cultural differences in pronunciation.

Suggestions already been made:

Some words that describe the ‘why’ actions:

To reproduce consistently, predictably, economically, higher quality

To enforce (govern) established practices consistently, reliably

To automate rapidly, economically,

Capture

Repeat

Proven

Guide

demonstrate

Some words that describe the ‘what’ and ‘how’ actions:

Patterns

Pattern Model

Patterning

Modeling

Domain Specific Tooling

Automate

Automation

Templates

Templatize

So, what name stands out as indicating ‘why’ you should this product to make your lives easier to build or deploy software, and that adds value and save money in doing it faster, more economically and produces better quality and more consistent
results?

I like the first one... It's like Nu (from NuGet) and Mate from Automate :). Coincidentally, Mate is a very popular Argentinean drink that drove much of the development of VSPAT :) http://kzu.to/W3Twko

I know the word 'meta' is really important in the understanding of how VSPAT works, and perhaps even for some insiders it defines the action of what it is (i.e. a meta tool, with meta model and meta framework etc.), but my concern is that the people
we are trying to convince to look at VSPAT and adopt it in their development/deployment processes will not have a deep understanding of what 'meta' is all about, or that is has any concrete meaning to them. I dont think they want meta, they want repeatability
or automation or consistency and whatnot.

I don't think they are thinking, "I want to do something 'meta', or need something 'meta' to solve this problem I have of making things consistent or more economical or more higher quality etc".

There are still alot of these names I like, here are my favs (no particular order):

(remember that selecting a name is trying to find a meaning that we think others will readily associate to it, and avoid the associations we prefer people to avoid.)

RePlate - becuase plating something (think hardening) has good menaing here, and re-plating it is giving it more strength

NuPlate - I still like this one, and still like the idea of owning that namespace to follow suit with NuGet.

NuAutomate and NuTemplate - awkward to say, but just the way it sounds good, its like a new way to automate or a new way to template something

NuMate - to me, not so strong, but still better than VSPAT

Ingeminate.Net - I love this word, it is interesting in a geeky way and obscure of course, but the .Net part I dont like, because it can handle more than just automating .Net, even though it is actually based on .Net. I think the potential perception of
this name constrains it too much.

NIngeminate - hard to pronounce correctly. But has a kind of Ninja sound to it, that apparently is in vogue these days.

I was attracted to VSPAT because of the work Udi has done with NSB Studio.
To me it's all about getting things done, and doing it properly (now that's very opinionated).
A tool like yours would allow devs to not rely as heavily on other productivity tools like resharper.
I value the investment in custom productivity tools. Maybe it's prevention vs the cure.

VSPAT is more of a prevention
Resharper is the cue - to fix the crappy code that is churned out by rogue coders trying to practice TDD or whatever acronym is the flavor of the month.

Sorry to be negative about the naming of the project but I'm not fussed what you call it!
I can see the light at the end of the tunnel from such an investment.
Don't get me wrong I appreciate all your effort.
I plan to streamline my CQRS coding environment with VSPAT

This is a great response, I am not seeing it as negative at all. The responsibility for keeping the project relevant, growing adoption for it, marketing it to the right audience, and therefore naming it is mine, and I welcome all input from everyone's perspective.

Since its release in March this year, we havent recieved much feedback of any kind from the community, and the feeling in the core team from listening to some people talk publically about it, was that VSPAT seemed a bit bland, a bit of a mouthful, and hard
to get the acronym right. So we were thinking a shorter, more recognizable name would be better. Something that has meaning to the value of it of course, but something a little more colorful than an acronym.

Your input has been very welcomed. Its great to see that the value of VSPAT is recognized for what it was intended to do.

much appreciated

p.s. please let us know on the discussion board, or on your blog (if you have one) your experiences with VSPAT. We would love to share them.

To me Nuget is a technology for fetching dependencies. I know it also does a lot of stuff to install them, but from a value perspective, as a user, it is the technology that I use to find and get the dependencies from a repository into my projects.

Nu - dont know what the orign of the prefix is. Would love to know.

"Get" - being the action verb

NuGet being the product/extension/technology whatever that does this for me.

In this naming regime then, isn't VSPAT -> NuTool? Since you use VSPAT to "tool" your development? Mind you it could just as easily be "NuAutomate" or "NuTemplate" then I suppose, as you could just as easily say: I use VSPAT to automate my development,
or I use VSPAT to template my development. Depends on how you see it I suppose.

This is really just a note to myself at this point, but I put it here so you could see the visible impact of a rebranding VSPAT, to our users using it.

Some of the names and monikers we would need to change when we rebrand. If we chose arbitrarily to go with the new name "NuStuff" for this exercise, then this might be how the names and monikers would change.

Product Name - VSPAT-> NuStuff - the overall name of the technology, and common name in all marketing materials.

RootNamespace - Microsoft.VisualStudio.Patterning.* -> NuStuff.* - the root namespace of all the code, starting with original author, followed by the system, followed by the technology name.

Name of Runtime VSIX - Pattern Toolkit Manager -> NuStuff Manager - the name of the runtime component of VSPAT. Only visible in VS Extension Manger.

Name of Authoring VSIX - Pattern Toolkit Builder -> NuStuff Builder -> the name of the auhtoring tools. Visible in VS Extension Manager, and also the name of the extension in the VS Gallery

Name of the Automation Library VSIX - Pattern Toolkit Automation Library -> NuStuff Automation Library - the name of the automation library project for the builder. Only visible in teh VS Extension Manager.

Name of HOL VSIX - Pattern Toolkit Builder Labs -> Nustuff Builder Labs - the name of the HOL for authoring toolkits. Visible in VS Extension Manager, and also the name of the extension in the VS Gallery

VS Settings Name - Pattern Toolkit Extensions -> NuStuff Extensions - The name of the settings dialog in VS, error dialog, and the output window pane used for diagnosing issues.

Pattern Toolkit Project Template - Pattern Toolkit -> NuStuff Toolkit - the name of the project template for creating a new toolkit.

Main Tool Window Name - Solution Builder -> Solution Builder - the name of the tool window where developers create and work with toolkits in their solutions.

'Toolkit' Moniker - Pattern Toolkits -> NuStuff Toolkits - the name of the toolkits that are built and deployed containing all the patterns, assets, templates and automation. The things you build and are installed by others.

Just my view, and I enjoy the discussion. 'Fractal' is geeky for sure, to me is a something that keeps expanding to finer levels of detail as you dig deeper, definately repeating patterns that unveil themeselves as I dig deeper. I see a nice analogy there
with unfolding, and important action verb in templates. But do you think that someone who is unintiated to VSPAT is going to think 'fractals' is something that describes a tool that is going to address an existing problem they may have in their software development
process/practices? The kind of problems that VSPAT addresses - I mean?

I keep thinking its important, that if we are going to use a known word in the english language (as opposed to a made up one, which is also an option) that that word draws a picture in the mind of the person evaluating VSPAT for the first time that resonates
with how they understand both the problem and the solution (VSPAT). "Yeah, that fits!" kind of a thing. The bit I have found so hard to do, since I am so close to it, is locating the state of mind of a person who would approach VSPAT for the first
time, and hear from myself the kinds of thoughts and words I would use to describe what VSPAT would do for me, if I was looking at it the first time. Do you know what I mean? Perhaps I am on the wrong track though?

First of all, I think we should agree on the market that we're targeting. I consider it is Managers, Software Architects and Technical Leads. Developers are just consumers of VSPAT, and they will use it only if they get directives of use an specific Pattern
Toolkit implemented on VSPAT. So, our new name should "seduce" our Target.

I like to think about VSPAT as an evolution of t4 templates, because it's more powerful and you can create advanced scenarios. Also, it allows you to define how developments should take place using an already proven Pattern.

Although I understand Jezz's justification about using a name that describes the "why", I found nouns to be more useful for "Search terms". I got the following stats from
Google Keyword Tool:

Regarding 'N' and 'Nu', I prefer 'N' because it comes to my mind a lot of products that starts with it: NHibernate, NRefactory, NUnit & NCover. For 'Nu', I'm only remember NuGet, and it's from MS, and our idea is to sound like an open source project, not
a MS one.

I like Fractal very much. It's a cool name, and Jezz, nobody has the slightest chance of grasping what VSPAT is about just from its name, no matter how well chosen ;). Unless it's a VERY LONG acronym, hehe.

How about NuFractal? You build a NuFractal to automate the repetition of the patterns, using the NuFractal Builder, etc. "I think you need a NuFractal for that" :)

Awesome discussion thanks guys, please keep it going. I will just aim to guide this discussion to a decision point.

Just getting back to Eze's first premise on his brilliant post, a few back. I second that it is real important to correctly identify our customer base. So we can focus on how they would interpret what they see with a first look at VSPAT (the new name and
explanation that goes with it). Perhaps even get a few of them to share their own opinion? so we can correctly identify what seduces them.

To me, VSPAT is likely to get adopted by the development/deployment experts first, once they become aware of what it can do for them, not the managers nor the architects. Here is why. The former won’t know about VSPAT unless told by their SME's what
it can do for the project in terms of *cost*, and by the time the manager prescribes VSPAT to any development project they will have already been sold on it from a SMEs recommendation. The architect? depends how you define that role. I don’t have a lot
of faith in folks who identify with this term as their title and primary role in a software project - a debateable generalization for sure - but in my experience with hundreds of them at all levels of ability and rank, those that consider themselves 'professional
architects' by function on a project know it all already, and are unlikely to seek nor trust automation to do their design for them better or faster in the first place. Should they? Absolutely! Should this tool appeal to them? Absolutely! Could this tool make
them more effective in a project?, again, yes absolutely! I just don’t think they are the primary audience who will pick up this kind of tooling, have the motivation to tinker with it, and have the assets at hand to make an effective and functional toolkit
that could deliver significant and immediate value to their project. Will an architect see value in a built toolkit to use on their project? absolutely! but then they are just users, not builders.

We learned from bitter experience years ago, back before we started the VSPAT project that the spectrum of users of this kind of technology spans at one end of the spectrum from those who could, to those who should. Those that could, but shouldn’t,
were the few large organizations, with lots of investment dollars who could support a strict program of model driven techniques with rigid and complete architectural analysis. These tend only to be the highly-funded research projects that did not necessarily
need to deliver value to a real software program. Those that should, but couldn’t (because of the cost) were the ordinary development/deployment leads, who have been delivering the same kind of solutions years over, and who already have factored out
and refined the best practices with real assets and relevant knowledge that they carry to every project, and try to duplicate. They just need help with automating it.

<snip> to cut a long conclusion short, given an economical process and highly productive tools, this latter audience can deliver enormous value

So, I am absolutely convinced that our target audience is indeed the broader audience of project leads and technology experts who know 80% of the solutions that are going to be deployed in their organization/community inside-out. The ordinary workers at
the coal face, who already possess ‘template-able’ assets, reusable patterns, and prescriptive guidance, with lots of variables and constraints.

The good news, is that these people are abundant, and critical to the success of every IT project. These are the folks who could benefit the most from this kind of technology. They just have to know about it, trust it, and invest in playing with it.

If we agree that this is our target audience, then the naming (and explanations that go with it, marketing material) is critical to capture this audience, and get them interested in wielding it themselves to help resolve their issues on every project.

I'd say that kind of target is the one that has already built a project template, or even attempted (and typically failed) to provide some automation for himself or his team. After realizing it's too damn hard to be worth it, they just continue with simple
templates, nuget packages and maybe some powershell automation on those.

I am not so sure that the target audience we desire to have, have even tried yet - (probably didn't know where to start, or that there was a way forward for them?). The audience that has not tried is far larger than those who have.

But yeah, I am starting to conclude the naming is starting to converge now. What do other think?

BTW: what would be the justification for Nu* versus N*? I mean why Nu* versus just N*? What benefit does Nu* bring us? I heard you say one reason because its pronounced *new* (according to Phil Haack), any others?

It's true that "Architect" role always causes confusions lol. I was thinking on people like the one you described, those who know about most of the IT project on his organizations, and they already tried to do some automation / templating and
failed because there's not an easy tool to do it.

I also agree that most of the people that could use this tool, don't know about it yet. And that give us hope for the future. Talking more about this, I'm sure a Web Site or some videos are not enough to invite them go on-board and be early adopters
of this tool. Talks, Events, Courses (etc.) will be required to achieve our audience. Take into account that they're not always surfing the web looking for new tools to help them. They usually go to events/talks when this kind of knowledge is shared,
and our tool should be there.

However, the word 'Pattern' in the name of the tool is not as powerful as say 'Template' because people wont think they need a pattern to repeat their stuff. A template is something wellknown to use to replicate something (such as a pattern). So
to me, 'template' trumps 'pattern' in the actual name of tool you would use to repeat something. Fine distinction I know, but its there nonetheless.

If you would permit me, I have a late entry that may be able to resurect the 'template' verb.

How do you like the name "ReTemplate"? - as in Repeat-Template. Or perhaps, "now that you have a template (pattern), lets repeat it". Or, how about "now that you have a template, lets re-work it" (with automation etc).

Name of Runtime VSIX - Pattern Toolkit Manager ->
NuPattern Manager - the name of the runtime component of VSPAT. Only visible in VS Extension Manger.

Name of Authoring VSIX - Pattern Toolkit Builder ->
NuPattern Builder -> the name of the authoring tools. Visible in VS Extension Manager, and also the name of the extension in the VS Gallery

Name of the Automation Library VSIX - Pattern Toolkit Automation Library ->
NuPattern Automation Library - the name of the automation library project for the builder. Only visible in the VS Extension Manager.

Name of HOL VSIX - Pattern Toolkit Builder Labs ->
NuPattern Builder Labs - the name of the HOL for authoring toolkits. Visible in VS Extension Manager, and also the name of the extension in the VS Gallery

VS Settings Name - Pattern Toolkit Extensions ->
NuPattern Extensions - The name of the settings dialog in VS, error dialog, and the output window pane used for diagnosing issues.

Pattern Toolkit Project Template - Pattern Toolkit ->
NuPattern Toolkit - the name of the project template for creating a new toolkit.

Main Tool Window Name - Solution Builder -> Solution Builder - the name of the tool window where developers create and work with toolkits in their solutions.

'Toolkit' Moniker - Pattern Toolkits ->
NuPattern Toolkits - the name of the toolkits that are built and deployed containing all the patterns, assets, templates and automation. The things you build and are installed by others.

I am indifferent about 'NuPattern.Tools' as the namesapce for the authoring tools, but we do have to somehow get rid of the double namesapcing issues we currently have in the authoring codebase (i.e. MS.VS.Patterning.Authoring.Authoring.*). But we can keep
NuPattern.Authoring and change the rest of the namespace instead. How about: NuPattern.Authoring.Tools ?? as the namesapce of the actual authoring VSIX?

As for the name of the runtime VSIX (that is all we are talking about here), we made the change to "Pattern Toolkit Manager" a while back because frankly, 'runtime' has little meaning to our customers. They see themselves perpetually in 'design
time' anyway, and 'runtime' is not a well socialized word for an actual tool engine. That may indeed be debateable, but 'Manager' seemed to fit better for the name of an extension in Extension Manager, to give a sense of the piece that controls the running
of pattern toolkits - and it follows suit with NuGet.