I've just found out that Xslimmer 1.2.2 has been cracked. It's not too bad, this release has been out for a few weeks already, while previous versions had the dubious honor of having been pirated in only a couple of days. Is this because we have strengthened our protection system? No, it is not. We haven't changed a bit (or a comma) of our code in that respect. Are we planning to do so? No, we are not. We have too little time and too many things to do. We prefer to spend our precious sleepless hours working on new features and customer support rather than fighting some infantile dumbheads.
The situation is very simple. We have made a lot of effort, and people seem to like our software. If they keep buying copies, we can continue improving Xslimmer and working on the other ideas we have. Otherwise, we won't. Each individual sale is worth much more than the 12 bucks we charge for a license. Each sale is a recognition that we have made something useful and valuable, a boost of morale, a reason to keep on working to the expense of our free time and our families. We strive to provide our customers the best service we possibly can. You see, it's not only the money, it's not even the prospect to become full-time indie developers one day: it's our pride and reputation that are at stake.
I believe that this is clear not only for ourselves, but for the vast majority of the "Mac community". As you may know, being recent switchers we are relatively new to the Mac family. One of the most notorious aspects of owning a Mac involves the feeling that you are part of a group of nice, discerning people. You don't buy a Mac for nothing: you buy it because you are looking for something special. Mac owners are warm to newcomers, passionate about quality and highly discerning about the difference between a carefully crafted application and a quick, careless hack. The first Xslimmer crack came out in less than 24 hours after release of version 1.0. And some of our well-known competitors are freeware applications. And still, some people buy copies of Xslimmer. It doesn't mean that our competitors are crap, it means that people will recognize the different approach in each application, and will buy Xslimmer if they believe it suits their needs best. And, of course, most don't consider downloading a crack, because they recognize the work that has to be done to put an application together. I had not seen this passion in the Windows or the Linux worlds, and I am proud to have become a member of this community.
Other authors have previously explained that most people that use pirated versions of your software will probably never buy it, even if the crack did not exist. Having lived among Mac users for a while, I'm a convert to this theory now. I'm even inclined to measure it. This post is, in fact, a little experiment to test to what extent piracy affects sales. If you are proud to be a Mac owner, feel free to spread the word: there is a cracked version of Xslimmer going around, but also a legitimate one whose purchase is the way to show your support for its development. Do you think our sales will decrease significantly? I'm willing to bet that they won't. But I'll measure the conversion ratio (sales to downloads) during the following days, and will post any meaningful results here, so we'll see.
A final reason not to use pirated copies of Xslimmer, if you need any, is that we are planning to release version 1.2.3 next week. Version 1.2.4 will come a couple of weeks after that. And so on, until we run out of ideas. Do you want to depend on some random drone to enjoy the upgrades? We'll see in a few days what the results of our little experiment are, but I doubt you will.
Latenitesoft: Mac & iOS Applications. Our blog.
Friday, March 30, 2007
Friday, March 16, 2007
Xslimmer, dugg (indirectly)
This week's traffic in our main site has come as a bit of a surprise to us. It all began on Tuesday, 13th -which, ironically, is the Spanish date when bad luck conjures up to make your day miserable-. When I got to bed at around 2am, everything was quite between the normal boundaries. However, when I got up at 6am (yes, it's a hard life for poor little developers with a day job) I immediately noticed that something was happening that was out of the usual: the moment I switched my mobile phone on, I began to receive SMS messages alerting me of events that had been happening while I was asleep. One of the consequences of crafting something that others are willing to pay for, combined with a technically oriented mindset, is that you develop a compulsion to measure, analyze, monitor and graph everything that happens. In my case, I had programmed the sending of SMS messages to my mobile whenever important events, such as sales, take place. Receiving an steady stream of SMS beeps is something I did not expect to happen in a random day with no recent important releases or noteworthy events on our side. This lasted for a couple of minutes, signaling that something had happened in the 4 hours my mobile had been switched off. I got to my MacBook Pro and run a couple of scripts to determine that we were receiving a lot of traffic from this article by Ed Eubanks Jr. at lowendmac.com. Xslimmer was mentioned as one of a variety of options that can be used to help you optimize your Mac. I read the article, dugg it, wrote the author with my compliments and comments, answered to some emails from customers, and drove to work.
Whenever Xslimmer is featured in a popular blog or site, we experience a traffic burst that translates proportionally to sales and mails from prospective customers or new buyers. Although the effect lasts for some days, the main spike declines pretty soon. However, in this case we kept having a relatively steady amount of activity during the following hours. And then, a second burst was noticed at around 15:30: the article had already accumulated 670 diggs and had been deemed "popular" by the Digg team. We kept receiving a lot of traffic, more sales than usual, and therefore had to cope with an increased amount of support activity (mostly derived from licenses that got trapped by spam filters and had to be resent manually). I thought this would last for a day, but that night when I got home the article had snowballed to more than 2,000 diggs and traffic was solid. This continued for another day and a half, and then decreased when the article finally left page 1 of Digg's Apple section.
We are proud and very grateful about the response received from all of you. We have gone through frentic activity trying to answer all your emails as soon as possible, but this activity is much more pleasurable when most of the feedback we receive is positive and encouraging. We'd also like to send our heartfelt thanks to Ed, who originated the best string of sales and response in our short history. And your article is interesting, too, if you don't mind we may borrow some of your ideas for future Xslimmer releases! :)
There are a number of lessons to be made from this story. The obvious one is the immense power of community sites such as Digg. I cannot imagine what would have happened if Xslimmer had been "dugg" in a direct way instead of marginally. A consequence is that quality and word of mouth really, really count: Ed chose to mention Xslimmer because he had liked the program. And because Ed's article was authoritative and respected, it was chosen and made popular by its readers. I believe there is a parallelism between this new wave of user-promoted content and the strong and traditional heritage about quality in the Mac tradition, whose users tend to look for good solutions, recognize them and recommend them to others. Being small software developers, our bet was to provide a "Mac-like" experience to a seemingly sensitive operation and rely on word of mouth to get our message through, hoping that this would pay off in the long run. The process is cumulative, and we do believe that each new customer is a potential referral for new ones; therefore, we have no option but to strive for simplicity, quality, robustness, ease of use, customer support. That's why we chose to distribute 5,000 free (non-upgradeable) Xslimmer licenses during the MacAppADay promotion, back in December, and only a few weeks after having released Xslimmer 1.0: in the hope that this community of users would spread the word if they really liked our application.
You know what? Ed downloaded Xslimmer during MacAppADay, bought it a few days later, and recommended it to the world last Tuesday, 13th.
The next Tuesday, 13th will be in November. After this week's events I'm confident that by then we'll be closer to our goal to "go Indy" and work on this thrilling activities the whole day. We'll keep working to achieve that, and we can't fail because November 13th is my birthday, and I'm determined to prove that bad luck may happen on Fridays, but not on Tuesdays, and certainly not on my birthday!
Whenever Xslimmer is featured in a popular blog or site, we experience a traffic burst that translates proportionally to sales and mails from prospective customers or new buyers. Although the effect lasts for some days, the main spike declines pretty soon. However, in this case we kept having a relatively steady amount of activity during the following hours. And then, a second burst was noticed at around 15:30: the article had already accumulated 670 diggs and had been deemed "popular" by the Digg team. We kept receiving a lot of traffic, more sales than usual, and therefore had to cope with an increased amount of support activity (mostly derived from licenses that got trapped by spam filters and had to be resent manually). I thought this would last for a day, but that night when I got home the article had snowballed to more than 2,000 diggs and traffic was solid. This continued for another day and a half, and then decreased when the article finally left page 1 of Digg's Apple section.
We are proud and very grateful about the response received from all of you. We have gone through frentic activity trying to answer all your emails as soon as possible, but this activity is much more pleasurable when most of the feedback we receive is positive and encouraging. We'd also like to send our heartfelt thanks to Ed, who originated the best string of sales and response in our short history. And your article is interesting, too, if you don't mind we may borrow some of your ideas for future Xslimmer releases! :)
There are a number of lessons to be made from this story. The obvious one is the immense power of community sites such as Digg. I cannot imagine what would have happened if Xslimmer had been "dugg" in a direct way instead of marginally. A consequence is that quality and word of mouth really, really count: Ed chose to mention Xslimmer because he had liked the program. And because Ed's article was authoritative and respected, it was chosen and made popular by its readers. I believe there is a parallelism between this new wave of user-promoted content and the strong and traditional heritage about quality in the Mac tradition, whose users tend to look for good solutions, recognize them and recommend them to others. Being small software developers, our bet was to provide a "Mac-like" experience to a seemingly sensitive operation and rely on word of mouth to get our message through, hoping that this would pay off in the long run. The process is cumulative, and we do believe that each new customer is a potential referral for new ones; therefore, we have no option but to strive for simplicity, quality, robustness, ease of use, customer support. That's why we chose to distribute 5,000 free (non-upgradeable) Xslimmer licenses during the MacAppADay promotion, back in December, and only a few weeks after having released Xslimmer 1.0: in the hope that this community of users would spread the word if they really liked our application.
You know what? Ed downloaded Xslimmer during MacAppADay, bought it a few days later, and recommended it to the world last Tuesday, 13th.
The next Tuesday, 13th will be in November. After this week's events I'm confident that by then we'll be closer to our goal to "go Indy" and work on this thrilling activities the whole day. We'll keep working to achieve that, and we can't fail because November 13th is my birthday, and I'm determined to prove that bad luck may happen on Fridays, but not on Tuesdays, and certainly not on my birthday!
Monday, March 12, 2007
Lossless same-drive Mac HD Repartition
Recently I discovered a lossless way to repartition my Mac's main hard drive, without having to boot from an external drive. I have been looking for this for quite a while, as I wanted to install the Mac OS X Leopard preview in order to test the new development tools and maybe try a new feature or two for Xslimmer.
Some people had suggested to use the Bootcamp utility to resize and partition the drive. But I had already installed Windows (basically for gaming) and did not want to lose that partition.
So, I finally read an article on how to do this using the command line command diskutil, and its hidden feature named resizeVolume. If you check the man pages, you will see that there is no information on this matter, but you can obtain some executing "diskutil resizeVolume":
So, as you can see, to resize a partition you first need to know its name. For that you can use "diskutil list":
In my case, the partition was disk0s2. The partition scheme or the EFI partition should be ignored. As I said before, I already had a Mac OS partition and the Bootcamp partition. I wanted to create a new 20 Gb partition out of the main Mac OS partition, disk0s2.
Now, there are some limitations to the resizing. I guess it has to do with how much free space you have in the partition you want to divide. To verify the limitation, you use "diskutil resizeVolume partition_name limits":
Finally, you have to provide the resizing parameters to the "diskutil resizeVolume" command. In my case, I wanted to keep 414Gb for the main partition and create a new Journaled HFS+ with 20Gb:
In my case the first step, "Verifying" was what took the longest time. After that it all went very fast.
Once done, you should reboot. After rebooting, you can use diskutil or Disk Utility to prepare that new partition for use.
In my case, I used Disk Utility, selecting the new partition, the Erase tab, then proving a name for the partition, and clicking on the Erase button.
(Update) One more thing needs to be done. This time is for Windows to keep running fine. You should edit boot.ini (I used textmate), so it knows the partition is it located in. Mine looked like this:
All set!
Now I have Leopard on my Mac along with Tiger and Windows, thanks to these simple operations. Needless to say, before you attempt to do anything like this, you should have a backup.
[Update: I wrote a second part of this article]
Disclaimer: Visitors do assume all the risk of viewing, reading, using, or relying upon this information. We assume no responsibility for damage to computers or software of the visitor or any person the visitor subsequently communicates this information to.
Have fun!
Some people had suggested to use the Bootcamp utility to resize and partition the drive. But I had already installed Windows (basically for gaming) and did not want to lose that partition.
So, I finally read an article on how to do this using the command line command diskutil, and its hidden feature named resizeVolume. If you check the man pages, you will see that there is no information on this matter, but you can obtain some executing "diskutil resizeVolume":
freeport:~ jorge$ diskutil resizeVolume
Disk Utility Tool
Usage: diskutil resizeVolume [Mount Point|Disk Identifier|Device Node] size...
Non-destructively resize a disk. You may increase or decrease its size.
When decreasing size, you may optionally supply a list of new partitions to create.
Ownership of the affected disk is required.
Valid partition sizes are in the format of.
Valid sizes are B(ytes), K(ilobytes), M(egabytes), G(igabytes), T(erabytes)
Example: 10G (10 gigabytes), 4.23T (4.23 terabytes), 5M (5 megabytes)
resizeVolume is only supported on GPT media with a Journaled HFS+ filesystem.
A size of "limits" will print the range of valid values for the current filesystem.
Example: diskutil resizeVolume disk1s3 10G
JHFS+ HDX1 5G MS-DOS HDX2 5G
Valid filesystems: "Case-sensitive HFS+" "Journaled HFS+" "Case-sensitive Journaled HFS+" "HFS+" "HFS" "MS-DOS FAT32" "MS-DOS FAT16" "MS-DOS" "MS-DOS FAT12" "UFS" "Linux" "Swap"
So, as you can see, to resize a partition you first need to know its name. For that you can use "diskutil list":
freeport:~ jorge$ diskutil list
/dev/disk0
#: type name size identifier
0: GUID_partition_scheme *465.8 GB disk0
1: EFI 200.0 MB disk0s1
2: Apple_HFS Macintosh HD 434.0 GB disk0s2
3: Microsoft Basic Data WINDOWS HD 31.4 GB disk0s3
In my case, the partition was disk0s2. The partition scheme or the EFI partition should be ignored. As I said before, I already had a Mac OS partition and the Bootcamp partition. I wanted to create a new 20 Gb partition out of the main Mac OS partition, disk0s2.
Now, there are some limitations to the resizing. I guess it has to do with how much free space you have in the partition you want to divide. To verify the limitation, you use "diskutil resizeVolume partition_name limits":
freeport:~ jorge$ diskutil resizeVolume disk0s2 limits
For device disk0s2 Macintosh HD:
Current size: 466003951616 bytes
Minimum size: 213448208384 bytes
Maximum size: 466003951616 bytes
Finally, you have to provide the resizing parameters to the "diskutil resizeVolume" command. In my case, I wanted to keep 414Gb for the main partition and create a new Journaled HFS+ with 20Gb:
freeport:~ jorge$ diskutil resizeVolume disk0s2 414G JHFS+ Leopard 20G
Started resizing on disk disk0s2 Macintosh HD
Verifying
Resizing Volume
Adjusting Partitions
Finished resizing on disk disk0s2 Macintosh HD
You will need to manually reformat your new partitions.
WARNING: You must now reboot!
In my case the first step, "Verifying" was what took the longest time. After that it all went very fast.
Once done, you should reboot. After rebooting, you can use diskutil or Disk Utility to prepare that new partition for use.
freeport:~ jorge$ diskutil list
/dev/disk0
#: type name size identifier
0: GUID_partition_scheme *465.8 GB disk0
1: EFI 200.0 MB disk0s1
2: Apple_HFS Macintosh HD 414.0 GB disk0s2
3: Apple_HFS 19.9 GB disk0s3
4: Microsoft Basic Data WINDOWS HD 31.4 GB disk0s4
In my case, I used Disk Utility, selecting the new partition, the Erase tab, then proving a name for the partition, and clicking on the Erase button.
freeport:~ jorge$ diskutil list
/dev/disk0
#: type name size identifier
0: GUID_partition_scheme *465.8 GB disk0
1: EFI 200.0 MB disk0s1
2: Apple_HFS Macintosh HD 414.0 GB disk0s2
3: Apple_HFS Leopard HD 19.9 GB disk0s3
4: Microsoft Basic Data WINDOWS HD 31.4 GB disk0s4
(Update) One more thing needs to be done. This time is for Windows to keep running fine. You should edit boot.ini (I used textmate), so it knows the partition is it located in. Mine looked like this:
[boot loader]As you see, it says partition(3) for the Windows partition, which is now wrong. I changed it to partition(4) and it worked like a charm. Notice partition(3) appears twice, you should change both.
timeout=30
default=multi(0)disk(0)rdisk(0)partition(3)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
All set!
Now I have Leopard on my Mac along with Tiger and Windows, thanks to these simple operations. Needless to say, before you attempt to do anything like this, you should have a backup.
[Update: I wrote a second part of this article]
Disclaimer: Visitors do assume all the risk of viewing, reading, using, or relying upon this information. We assume no responsibility for damage to computers or software of the visitor or any person the visitor subsequently communicates this information to.
Have fun!
Tuesday, March 06, 2007
Back...after the break
As with every major release of an application, not only the days prior to the release are very intensive, but also the days after. With Xslimmer 1.2 it has not been different. Issues, doubts, questions, bugs, feedback. Lots of hours of dedication and little sleep.
The most important bug was what I initially called the "UK English Bug", which at the end also had an important impact on our German customers. After a few hours of being detected, we released 1.2.1 in order to fix it. Incredibly, none of our beta testers were German or UK English people. We apologize to those who suffered this issue.
A few days later, with 1.2.2 we fix some other minor fixes and tweaks were introduced. Then, we took a break. For a few days, we had enough with our day jobs and our families.
Right now we are back, and starting with 1.2.3 and our general Xslimmer roadmap. We shall keep you posted.
The most important bug was what I initially called the "UK English Bug", which at the end also had an important impact on our German customers. After a few hours of being detected, we released 1.2.1 in order to fix it. Incredibly, none of our beta testers were German or UK English people. We apologize to those who suffered this issue.
A few days later, with 1.2.2 we fix some other minor fixes and tweaks were introduced. Then, we took a break. For a few days, we had enough with our day jobs and our families.
Right now we are back, and starting with 1.2.3 and our general Xslimmer roadmap. We shall keep you posted.
Subscribe to:
Posts (Atom)