We’re close. Just working around a problem with invalid email addresses.
Archive for the ‘ePublisher’ Category
2009.1 emails going out on Wednesday
We’ve migrated a large portion of our legacy licensing information into the new system. We should be sending out the first batch of upgrade notifications tomorrow.
A couple of notes…
Getting 2009.1 out the door
Here’s an update for those of you looking for your copy of ePublisher 2009.1.
We closed out the code tree last week and certified our build (2009.1.20966 if you’re interested). That was the easy part. Actually, that was challenging. We integrated our new licensing technology into the release. It works great! Getting it there wasn’t always fun.
Why change ePublisher licensing?
or “What just happened to my 2008.1 keys?”
Back at RoundUp 2007, I presented the WebWorks ePublisher 2008 road map. Development was excited to start work on the new feature set. We were also a bit overwhelmed by the tasks we had set for ourselves: full FrameMaker 8 and Vista support (delivered with 2008.1), Eclipse Help (delivered with 2008.2), and wiki publishing to MoinMoin and MediaWiki servers (delivered with 2008.3). Everyone was pumped up about the new offerings, especially our Sales team.
And then someone asked the question, “How do we limit these features to folks on the new release?”
Um, new license keys?
Well, new license keys are one way to do it, but they really aren’t a great solution. You see, we issue keys per feature and per product. In the simplest case, that means at least 2 keys per order. For users who leverage our full platform, that number could increase up to 6 or even 9 keys per order. Now, consider that someone is supposed to deploy 6 or 9 keys to 20-30 members of their organization. That’s a real problem for a company like WebWorks who want to fit in and do well in the Enterprise market. And its no fun for small shops either.
So what to do about it.
Why use ePublisher Express?
2006 was the year the ePublisher Platform became whole. That was the year WebWorks.com introduced ePublisher Express. It’s been two years now and customers still ask the question:
Why should I use ePublisher Express?
Why can’t I just stick with ePublisher Pro?
ePublisher Express was the result of a focused effort by the WebWorks.com Marketing group working in conjunction with dedicated customer sites. Marketing’s goal was to understand the challenges faced by those customers who were facing difficulties with the deployment of ePublisher Pro and ePublisher AutoMap into their corporate environment and then do something about it. The process involved customer conference calls, field testing of Beta releases, and a final thumbs up by the project Customer Advisory Board before we knew we had something that was “Just Right”. The experience enabled all WebWorks.com departments to understand the strengths of our previous publishing platform, WebWorks Publisher, and recognize how best to address shortcomings in the ePublisher Platform of early 2006 (ePublisher Pro with ePublisher AutoMap).
What hasn't changed
When WebWorks.com created the classic WebWorks Publisher product for FrameMaker back in 1994, we wound up doing two things.
1. Created the standard for single-sourcing web deliverables with FrameMaker.
2. Defined authoring guidelines for users to control Help behaviors from their source documents.
When ePublisher was launched in 2005, our goal was to replace our custom code base and macro language with a workflow based on XML and XSL. We wanted to change how we delivered #1 and allow customers to keep #2.
No one knows that.
Quarterly Releases == Trust
Quarterly Releases
Our first ever quarterly release is scheduled to ship early next week. On the one hand, you could say our first quarterly release will be at the end of June. On the other hand, even if customers cannot yet perceive the change, internally we’re experiencing shifts in our approach to building and shipping software. It’s been an interesting journey.
In the past, WebWorks.com has always shipped “Big Bang” releases. You know, the ones where if we couldn’t label it “Newer!” and “Tastier!”, Marketing and Sales wanted more. This mentality meant most any desired feature could delay a release. Bug fixes and Support issues be damned! The thought process evolved to become, “Introducing feature X will cause customers to forget about defects A, B, and C.”
Is that the right way to build and ship software? What message does that convey? What message do we want to convey?
(more…)
