So what’s the big deal?

I am sure that every .NET developer has some experience with creating strong named assemblies by now. All you need to do is create yourself a *.snk file (sn.exe –k) that contains both a (public and private key by default), and then configure a couple of assembly level configuration in your project and you are done. This is all fine and good if you are permitted to create and access your own private keys. But if you work in an organization and want your software identified to that organization, chances are that your organization wants to control access to those private keys. Because compromising them amounts to a security vulnerability, and you may have to jump though hoops to get your bits signed in the organization. Many organizations wish to have, and have defined strict processes and governance around getting bits signed using their private keys which they keep under lock and key, quite understandably.

The NuPattern project is a member of the The Outercurve Foundation, and as well as attributing the projects ownership to the foundation, we also sign and certify our binary deliverables using certificates provided by the Outercurve Foundation. We DelaySign our code with the public key which we store in the source code tree. But in order for the project to sign the bits for public consumption, we need to sign our bits with a private key, which we don’t have access to.

Like many software projects, we strive to build an identity and trust with our customers, and ensure that the authenticity and the integrity of our deliverables are protected. As part of that, we like to strong name and Authenticode sign our assemblies, we also like to Authenticode sign our deployable packages (i.e VSIXes and MSI’s) so they can be downloaded and trusted. Have you ever downloaded something to be told by your browser that it does not look to be trusted, and you should perhaps not install it? So, signing and certifying deliverables is pretty key to building trust with customers, and is a very common practice in use by many software organizations to ensure that what you download and consume are genuinely from the source, and have not been tampered with.

Back when we first developed and released NuPattern (then called VSPAT) before it was open sourced, it was a proprietary product from Microsoft. At Microsoft, any released binary deliverable must go through a rigorous release process to ensure it meets many compliance standards  - as do all software deliverables from Microsoft. There are some very good tools around Microsoft for managing this process as a whole. But one of the critical steps in that process is to get your deliverables signed by the organization. Microsoft, like other large software vendors don’t give their staff access to the private keys of their certificates and asymmetric signing keys. Those private keys are guarded carefully, locked up and protected well behind authorized processes. So how did we get our assemblies strong named signed, and other deliverables Authenticode signed at Microsoft?

Well, at Microsoft they have created their own in-house tools and process flows for getting your deliverables signed for you on behalf of the organization. It is a tightly controlled process, and not that easy to navigate to be fair. The basic idea is that you get time-boxed access to the signing tools in a convoluted approval process. Then you login to a internal corporate web site, you go through an online wizard where you configure the kind of signing you want, then you upload the deliverables to sign, and then at some time later (like days) you get an email to tell you they were signed and can be downloaded from a file share, which requires authorized access as well.

I remember that when I first went thought this process: it took about 4 days to get authorized access from some administrator over email. Then I had to meet strict software configuration on my machine, and dependencies in my browser. Then it forced me to download specific version of some ActiveX control, which was problematic in many browser versions, even Internet Explorer! Then, I got immediately stuck on what option to select for what kind of signing I needed. I just wanted assembly strong name and Authenticode signing at first. But there were many options for all the different kinds of things and keys they have to support. (As you might expect in a company that size, that sign anything from every Microsoft product on the marketplace ever!) After someone (with prior-experience with the tools) gave me the right coordinates, I was away. I would submit my batch job and wait a few days for the results. Overall, end-to-end the process took several days to release the bits – just from signing. It required intense manual configuration in the signing tool, and multiple rounds of signing in our case (see later). Naturally, I was never really very comfortable that I hadn’t forgotten a signing step, or configured each step correctly. The only sense of comfort I could find that things were done right, was intensive, tedious and manual verification that the bits were indeed all signed in the right places, for which there are very rudimentary tools available to help.

When the project was finally assigned to Outercurve and made open source, we faced the same issue of how to get our bits signed with the private keys held by the Outercurve Foundation. At the time, signing bits for other .NET projects at the Outercurve was not in high demand! Which I have to say surprised me, but on reflection appears to be representative of many software organizations. Why? Simply, because providing tools that do such a task in an automated fashion (even partially automated) are HARD to implement correctly and reliably. This is evident from the lack of any online services that can provide such a service to software organizations. [There an idea for an online entrepreneur. Not without its trust challenges I might add].

At the time however the Outercurve strongly desired to support such a key scenario to its projects, and work began in earnest to provide this signing service to its project owners. The results of that push are now realized and fantastic. We have Eric Schultz to thank for all his hard work and dedication for getting us there, and furthermore, for enabling the NuPattern project to continue creating regular releases. But first let me explain how we got there.

At the start, there was nothing except a couple of private keys for both strong naming and Authenticode signing assets, and a will to create a signing process.

Eric began working on providing services for automating the signing of project assets. I actually don’t know the details of what Eric started with or how Eric began the work (perhaps you can ask him yourself), but at some point, shortly after, we were working together intensely on Skype signing our assemblies and packages, by exchanging binaries over a online file share (Skydrive), and some time later (minutes to hours) Eric would pass me back my bits signed.

From the project side, initially we had no automation to help us provide Eric with the right bits at the right time. We started off with an automated build that yielded our built packages (VSIXes in this case, which are renamed ZIP files), and an MSI installer. But our VSIXes contain other VSIXes like a Russian doll they nest inside of each other, and every VSIX contains one or more assemblies that would need strong name signing. We also needed to Authenticode sign every assembly, every VSIX package and the MSI package. The signing process, end-to-end requires several steps, with multiple signing phases, it goes something like this:

• Extract all assemblies from all built VSIXes (we have 8 VSIXes, and about 50 assemblies)
• Sign all 50 assemblies (both Strong-Name sign and Authenticode sign)
• Reconstruct all 8 VSIXes with the signed assemblies.
• Sign the 6 nested VSIXes (Authenticode sign)
• Reconstruct the 2 containing VSIXes with the 6 nested VSIXes
• Sign the 2 containing VSIXes (Authenticode sign)
• Recompile the single MSI installer which packages the 8 signed VSIXes
• Sign the 1 built MSI installer

That’s four signing steps each with different assets, each with different signing keys.

Even though we could automate the building of the code to yield the VSIX packages and MSI package, and automate the extraction of the unsigned assemblies  from those VSIXes with some basic batch files, the reconstruction of the VSIXes with signed assemblies had to be performed manually using tools like 7-Zip on the desktop. Over the course of a few hours, we had built a few automated batch files for performing one or two of the steps. None of which automated either the signing or reconstruction steps. You could see those initial batch files in a previous version of the source code (now removed).

The first time around the process, it was basically Eric and myself on Skype uploading the files to a Skydrive, and then Eric downloading them and running his signing routines on them, then uploading back the signed results to the Skydrive. The overall process took about 6 hours to complete. We both had various interruptions with meetings, home life, meals etc., as we were also spanning an 8hrs time zone difference. We finally go it done just before 11pm at night for Eric, and so he signed off for bed. That left me to verify the results and upload the release to our project site. And wouldn't just you know it, it was only at that point that I discovered I had missed a step in the process, and we had signed the wrong bits!! At this point, I had no choice but to wait another half day until Eric and I could get back together again online, and rather frustratingly/embarrassingly (for us both) go over the whole process again. We got lucky that time, at least that’s how it felt given the number of steps and opportunity to miss or muck up a step – hardly a robust and reliable procedure. But it worked that time, thankfully.

Several weeks passed after that first experience, and Eric suddenly announced that the Outercurve signing service had been created and is now available online!!! He even created a GitHub open source project for it! And wouldn’t you know it, just in time for us to create a new release of NuPattern, which would need signing again. It has to be said at this point, that although we strive to create regular maintenance drops of the projects, the signing process and its overhead had caused some resistance to dropping whenever we wanted to. Clearly, not the best position to be in.

After Eric had provided our project with the necessary credentials to use this new signing service, and some examples of how to programmatically use it (in both PowerShell and MSBUILD) we were entirely unblocked from building a totally automated process around signing our bits. One that could be executed anytime! like after a CI build! perhaps not that frequently, but certainly that easily.

Work began in earnest at NuPattern. We had already discovered the process we needed, we had already documented it fully, and had it partially automated it with some rudimentary batch files. All we need to do was convert the batch files into MSBUILD scripts, and weave into that the signing pieces using the new signing service, using the MSBUILD tasks that Outercurve had provided.

The results of this MSBUILD code can now be seen in a single file in the NuPattern project: SignBinaries.targets. We needed to add the MSBUILD tasks/assemblies provided by Outercurve in our source tree, and also include the 7-Zip binaries in our source tree for this to all work. And we have a simple batch file (Make-AllAndSign.bat) that builds the code and executes the signing process in one click.

The outcome is phenomenal! in one click (or one step added to a CI process) we get our bits built, signed, repackaged and re-signed (as described above)! The overall process takes close to 1 hour to complete. (Most of that time taken to upload and download the various assets to and from the signing service).

In terms of productivity, we have gone from tying up 2 people for about 6hrs, to tying up a CPU for 1hr. But the most important improvement has been the reliability of the overall process. No longer do we have to worry about making manual human errors at any step in the process. The process is entirely automated, and as long as we got the automation steps right, we can guarantee the results are 100% reliable. And that cost saving (in verification and rework) is priceless to us.

At anytime, anyone on the project can now sign the bits. and perform a release. The instructions are fully documented as well.

If you are reading this and are interested in how to reap similar benefits in your project, you may want to talk to Eric. The code for this signing service is open sourced, and I believe its based on a set of simple Azure services. So why not build one in your organization? and save heaps of time and money getting your projects bits signed the right way?

Perhaps this signing service could be the first of its kind to lead the way in a new set of services that could be provided for *any* organization? who knows?

We need someone to attend or present NuPattern.

On May 29th, 2013, the first Software Development Automation Conference (SDAconf) will be held in Amsterdam. SDA is a conference for anyone who wants to learn more about automating software development, using model-driven development (MDD), domain-specific languages (DSLs), code generators and language workbenches.

SDA specifically targets software developers, architects and managers. So, not only technical issues, but also organisational and commercial aspects of software development automation will be addressed. Main purpose of the conference is to exchange knowledge of and experience with model-driven development, across industry and academia.

Model driven development has enthusiastic supporters, but also has to face sceptical critics. By means of this conference, we want to revive this subject. Efficient construction and maintenance of software is becoming more and more important. Change is constant. Software is more and more becoming a living organism. Software has to evolve continuously in order to satisfy its users. Model driven development is the answer to this.

Many tools exist for model driven development. These are evolving towards complete language workbenches, for rapid development of domain specific languages and code generators. Next to these, one can also find out-of-the-box model-driven solutions for business automation. The SDA conference is the place to see these developments at work.

So, do you want to increase quality, efficiency and predictability of your software development process? Then join us at SDA 2013, on May 29th, 2013.

Our web site: http://www.sda2013.nl/
Our email address: sdaconf2013@languageworkbenches.net
Follow us on Twitter: @SDAconf

However, for the first time EVER we appear in the ‘Updates’ of the Extension Manager in Visual Studio.

I have to tell you that this IS a big deal to me, and perhaps others on the project who started with the project back in late 2009. We have had to wait a very long time (more than 3 years) to have presence in this nifty piece of UI with our stuff in it. Helping make sure everyone stays up to date with the technology! It is huge for us.

If you are wondering why we have had to wait so long for this, here is a summary:

• The NuPattern project started in late 2009, and our first release followed 3 weeks later. We had something like 15 regular releases in 2010 as the project was incubated, proven and hardened. However, all these releases were hidden from public view as part of a ‘internal’ enterprise initiative between Microsoft and Raytheon. You can learn more about that here and here. After that initiative concluded, VSPAT (as it was known at the time) continued to be hardened and applied to other Microsoft initiatives, for other enterprise customers, none of which saw the public light of day. It was used in a public ‘Microsoft Amalga’ product release as their tooling platform, but ‘Microsoft Amalga’ is not really the sort of product you would buy shrink-wrapped, or for general consumption. The platform of VSPAT was as such, kept internal at Microsoft.
• In late 2011, Microsoft finally open sourced the project on CodePlex, and we had the 19th release (1.2.19.0) on the Visual Studio Gallery. This being the first celebrated public release.
• Then disaster struck. Further releases of VSPAT were seriously hampered because of the critical ‘Feature Builder Power Tool’ dependency that we had was not being supported for VS2012 by Microsoft. Prevented us releasing any updates, and that held us up for another 8 months!
• That issue finally resolved, in March of this year we released the 20th version (1.3.20.0) of NuPattern, but the branding, identity and binary compatibility had to be seriously overhauled because of the transition from Microsoft ownership to Outercurve ownership, and with the support for VS2012, and integration of the ‘Feature Extension Runtime’ – i.e. no chance possible for an automatic update of NuPattern there.

Not until yesterday could we finally put out there a release (1.3.21.0) that could ‘automatically’ continue the journey of NuPattern.

We hope you all update soon, and look forward to new updates as we move the technology forward.

Congrats again to all that made this journey possible.

The project delivered two parts:

The first part, the core part, was a Visual Studio extension that hosts Guidance Workflows in Visual Studio bringing contextualized and automated guidance into the IDE. It delivered both a ‘Guidance Workflow Explorer’ window which illustrated the workflow, and a ‘Guidance Browser’ window with which to browse the content of the individual elements in the workflow. A ‘Guidance Workflow’ is composed from of a set of instructional or informational steps, that can be sequential and multi-branched, and can be conditional on both manual gestures (like a tickbox) and automated conditions calculated form the development environment. The benefit of using such rich workflows is that they can not only help you understand a process where you could check off steps as you perform them manually, but also the workflow itself can calculate completed steps based on what you have done in your solution. The workflows allow multiple threads of concurrency in the workflow, which enables teams to complete complex or long running processes concurrently. As steps are completed in the workflow, new steps and paths through the process light up. You progress through the workflow until it is completed. Basically, it is an automated workflow processing engine. Very powerful indeed, especially for instructional kinds of guidance.

The second part of the power tools was the set of developer authoring tools that you used to design such guidance workflows.

Both part one and two were bundled together in the ‘Feature Builder Power Tool’ extension.

At the time, the Visual Studio Architecture team decided to base the ‘authoring’ tools of the FBPT on the new UML Activity Diagram that they were marketing heavily. As such they purposely decided to restrict the building of guidance workflows to Visual Studio Ultimate customers only. A huge oversight in my mind, as it put contextual guidance out of reach for many who could have benefited from utilizing guidance. This move also inadvertently stifled the uptake and adoption of guidance workflows across the marketplace for ordinary developers, since they were not privileged enough to create it. IMHO building guidance should have been a thing Microsoft should have encouraged to all and any Visual Studio user, building bigger momentum around this new technology and approach. But alas, the authoring experience with the UML Activity designer turned out to be super clunky, very tedious and ultra esoteric. And furthermore, the guidance that shipped with the authoring tools, that was supposed to help you build better guidance workflows!, was a very poor example of why there was any value in building guidance workflows in the first place! A lot of hard but important lessons were learned from that release, especially how not to treat and address your potential marketplace. However, the technology did speak for itself, and as such has seen some adoption and praise.

Unfortunately, soon after the public release of the FBPT tools, the team that built them was disbanded quickly, and the tools have had little support since. Its predecessor: the Guidance Automation Toolkit (GAT) was being made obsolete around the same time. And when VS2012 was being announced there was no plan from Microsoft to support the ‘Feature Builder Power Tool’. Unaware of this, FBPT customers who had taken a bet on the technology were left high and dry and without an alternative, or roadmap, as was the whole software factories community.

Until very recently, the ‘Feature Builder Power Tool’ project has been slowly languishing. With many bugs, installation issues, a poor authoring experience, bad ratings, and no encouragement and support from the Microsoft Visual Studio team. Sadly, the project has suffered a great deal of loss over the last few years, and has even angered a few.

However, there is now some great news about the FBPT project. If you remember, at the start of this post, I mentioned that the FBPT was a component of a larger strategy around delivering a full suite of software factory tooling. The other components of that strategy came together, with the guidance workflow piece, into the NuPattern project. There is a great story to tell here one day, but the short story is that NuPattern was designed to build upon the guidance component that was shipped in the FBPT, and extend it out much further to complete the overall tooling strategy, and it is still evolving. NuPattern was to be the set of domain specific development tools and integration platform that you built and ran your software factories upon. However, the NuPattern project called ‘PLATU’ at the time, was concealed from public view and so this remaining part of the strategy was invisible to people interested in how the FBPT technology was going to evolve, and what Microsoft was doing in that space.

The NuPattern project has always had a very large and deep binary dependency on the runtime component of the FBPT, right from the start. This is because it not only drove the requirement for building the FBPT technology in the first place, but it also needed to deliver the missing piece around domain specific development tooling that was needed to build a software factory or toolkit. About a year ago NuPattern (called ‘VSPAT’ at the time) was finally released.

As the FBPT wasn’t supported for VS2012 or later, the NuPattern project faced the reality of having a stagnant foundational dependency, that prevented shipping NuPattern for VS2012. After several months of negotiation and due process with Microsoft, they contributed the source code of the runtime components of FBPT to the NuPattern project. This single and celebrated collaborative act enabled the NuPattern project to finally ship a VS2012 version, and removed the crippling stagnant dependency. And with that one move, support for the core runtime components of the FBPT have moved to the NuPattern open source community. Great news for anyone who was either interested in, or still interested in the ‘Feature Builder Power Tool’.

NuPattern has always had guidance workflow support. And its has always had its own supported authoring experience for building guidance workflows, that is a great deal easier and far more intuitive than using UML Activity diagrams. Which makes creating guidance workflows available to all Pro/Prem and Ultimate customers in NuPattern!

If you are still using, or used the ‘Feature Builder Power Tool’ extension to build ‘Feature Extensions’, and you saw value in the concept of sharing guidance workflows. And you want to create more of them - look to building a NuPattern Toolkit instead. A NuPattern toolkit brings a far superior platform for your guidance and automation to be experienced by your Visual Studio users. (and just quietly, its a great deal easier to create and support than a feature extension).

That said, there is no direct and supported path to migrate a ‘Feature Extension’ built with FBPT to a NuPattern toolkit. You can however, keep the code and guidance you may have had in your feature extension, and with some rework, repurpose them in a NuPattern toolkit. The concepts are almost identical because NuPattern has always used the foundation of the FBPT runtime. Same concepts, same classes, but now a different namespace, and richer context for your guidance.

In a nutshell: for all those on the ‘Feature Builder Power Tool’ or those who lost faith in the FBPT project, and still have an interest in the technology - check out the NuPattern project and give us your suggestions and feedback on how to continue to evolve contextual and automated guidance for you.

Well now we have such a candidate video on YouTube - but it is silent – no voiceover!

The director and producers have done the hard work in scripting the video and producing it, but we are missing the most vital element, someone to explain what’s going on in the video!

The producers of the video don’t feel that their voices are suitable for the narration, so just for fun we are going to try a new idea, and recruit a narrator from the community.

So, the project is looking for anyone who would like to step forward, who likes the sound of their own voice, to be our voice of NuPattern, and bask in the glory of influencing many people to step in the direction the project is tracking.

Please apply within, post your interest on this discussion thread.

Well, instead of just documenting step-by-step instructions on how to implement these patterns, best practices or solutions, and then just hope someone understands it as well as you do to a degree they can repeat it reliably – you could instead build a Pattern Toolkit that applies and automates the implementation of your solution or pattern reliably, consistently and correctly for them.

A toolkit that not only includes all the assumptions, details and information about the solution to be built, but includes custom tools and guidance to build it, and integrate it into an existing solution. A toolkit that has a simplified user interface, with templates, wizards, custom automation, menus, drag & drop and integrated guidance etc. that can be configured to suit the specific needs of those using it.

Your Pattern Toolkit will allow others to make choices and selections about how the pattern can be configured to apply and accommodate their specific requirements and constraints. It can even allow other pattern toolkits to plug into it, extending it further.

It will integrate and apply your best practice or patterns automatically, correctly and rapidly, and still allow manual customization of the final solution if needed. And, if your Pattern Toolkit does not quite or exactly meet the needs of the next project/community, anyone can install NuPattern, take your Pattern Toolkit, and extend or customize it for their specific needs (requirements, technical constraints etc.) without having to start from scratch again – and without your source code!

Finally, it’s important to understand that the intricacies of building and deploying custom tooling in Visual Studio are conveniently taken care of for you. A Pattern Toolkit is generated for you and is packaged in a single deployable package that can be emailed, posted on a blog, or downloaded from the Visual Studio Gallery. You will never need to learn all about the complexities of Visual Studio commands, menus, tool windows. It is all generated for you.

If this sounds like something you should be doing, go and get NuPattern today!

I say first version version, because prior to this moment in time the product was called VSPAT, for which we have 19 previous releases. But NuPattern isn’t just a new name for the thing, it is a new direction and alignment that marks the independence of this product from its prior benefactor Microsoft, and opens it to a new community direction in developer tooling. NuPattern is now free to evolve by the development community to address broader market concerns around domain specific development and custom tooling development in Visual Studio. It is a huge milestone in this space.

One of these days, the story of NuPattern will emerge for those interested in its roots of development. For now though, we are hoping to start to build a new community around the project and take it in a new direction that adds value to any and every software development or deployment project. Please get involved.

This is fantastic news, and the NuPattern community is very grateful to all those at Microsoft who have made this generous contribution.

For those that may not be familiar with the significance of this move, the ‘Feature Extension Runtime’ (FERT) engine is the foundation upon which the NuPattern project was build, a key strategic dependency, and FERT exposes not only the some critical runtime components for NuPattern, but also provides the ability to run contextual and stateful guidance in Visual Studio. The ‘Feature Builder Power Tool’ is no longer supported in Visual Studio 2012, and having this contribution allows NuPattern to move forward to support Visual Studio 2012.

The ‘Feature Builder Power Tool’ was created by the Visual Studio Architecture Team as a first step in the direction of a new generation of contextualized automation tooling, which NuPattern then extended to add an automation platform and model-driven development approach for creating a new wave of domain specific tooling in Visual Studio, now available to everyone.

Now that the FERT components are integrated into the NuPattern project, we shall be able to support and extend this technology moving forward in current and future Visual Studio versions, and provide the ability to all developers to benefit from in-solution contextual guidance.

It marks a great moment in the history of the NuPattern project, and brings to light the work that Microsoft had invested over the last 5 years in a new generation of automation technologies that continue the to deliver on the vision of ‘Software Factories’ and ‘Domain Specific Development’.

More than anything though, this contribution now makes it possible to complete a new version of NuPattern for Visual Studio 2012. Which has been long awaited, and is now imminent.

We would like to recognize the efforts of the following people who have been key in this contribution: Brooke Hamilton, who has done all the hard work in driving and shepherding this contribution from Microsoft to the NuPattern project. This task which has taken months to complete, has been monumental in both effort, patience and tenacity to bring this valuable asset to us. To Gareth Jones from the Visual Studio Ultimate team who has worked closely with the project to make this key contribution. The team that originally created this contribution: David Trowbridge, Jack Greenfield, Michael Lehman, Christof Sprenger, Daniel Cazzulino and Mariano Rodriguez. And finally to the efforts and care of the Microsoft legal team, and the Outercurve Foundation team for getting us to this point.

Roll on the VS2012 version of NuPattern!

I’ve been consulting globally for Microsoft for the last 11 years and been helping software development organizations across many industries and geographies, assuring delivery of their solutions and products. Now that I have left Microsoft as a Principal there, I am now looking for new opportunities in the local or global marketplace where I can contribute my experience. Ideally, I would wish to have a significant impact in generating new value for a progressive software organization or community, who perhaps need help in moving to more efficient and sustainable product development practices and processes. Keen to pursue new opportunities or existing ones.

Ideally, the organization or community will recognize that they have significant customer value and revenue to grow, and that their IT capability may not be realizing its full potential in delivering business value efficiently, or at a level of quality and integrity that delights their customers, and grows their social capital in the marketplace. They probably recognize that their current IT capability may be wasteful and slow to apply itself to new market opportunities, or unable to change to serve changing business needs cost effectively. They recognize that fostering self-empowered teams, continuous improvement and the requirement to drive delivery excellence and higher quality is critical in moving forward in today’s business environment. They are looking for strong and experienced leaders to help develop and mature their IT capability.

Please let me know if you may know of any opportunities you think I should pursue.

The acceptance and adoption of the technology has evidently been very slow to date, and this is understandable given that most people who encounter the technology are given little draw to it from any real visual example or illustration of what it can do for them. Its a great platform, so we say, but who has used it?

If there was only one thing I would wish for right now, its that someone could create a screencast of a toolkit built with NuPattern.

We Need Help!

We don’t even need someone to build a new toolkit to do this. We have such a toolkit over at the MVCPAT project, and I have even documented each step of a walkthrough showing off all the cool features of it. It is just that we need a video of that walkthrough to excite people and given them a quick look at what NuPattern can do for them or their communities. This is such a critical asset for generating interest in the project, that without this first step it it is extremely hard to sell the value of the NuPattern platform.

After the screencast we will need more examples of toolkits other have built in the public domain. Its not that no one has built any toolkits with this technology, there are many 10’s of them out there within enterprises, its just that none of them can be shared with the public. Which again does not help demonstrate the effectiveness of the NuPattern technology. We need more publically available toolkits to show off the benefits of building and using toolkits.

If we had the above two things, I believe that is all it would take to get the project moving in the right direction, and have the community involvement to keep it moving. I never in a million years imagined that NuPattern would be pleading for new contributors moving forward given the history and success of the project, but the reality of the situation is that here we are.

So humbly, I am requesting your help.