The new Cyn.in version 3 is finally here and I am excited to announce its public availability. Cyn.in v3 brings with it great new features, tons of fixes and performance improvements and an all new user interface.

It has been an exciting year for us since the last major release of Cyn.in. I have been overjoyed with the response and adoption of Cyn.in within organizations spanning across nearly every major vertical and every continent across the world. From successfully enabling a company wide collaboration platform for businesses with over 50,000 employees to connecting together a 4 person strong startup, we have applied Cyn.in to a broad spectrum of requirements and learnt a great deal in the process.

Our key motivation while designing Cyn.in v3 came in from the needs of our customers and the community. Demanding market situations have caused businesses to push collaboration tools harder towards increasing efficiency and productivity while reducing costs. Cyn.in v3 was designed with a focus to speeden communication and facilitate rapid and seamless knowledge sharing.

A great new user experience:

Cyn.in evolves and changes the way knowledge workers communicate with each other, and in some cases, especially in very large organizations, this change could curb widespread adoption. The all new user experience has been redesigned from ground up to eliminate the learning curve and accelerate value discovery.

Discussion boards:

One of the most asked for features has been discussions independent of the contextual discussions as comments. The new discussions application in Cyn.in is the perfect tool to initiate conversations and fluid knowledge exchange.

Video / Audio streaming:

You can now share video and audio content with your team using Cyn.in. Its like having a secure internal Youtube for your organization. Uploaded media can be further embedded into other Cyn.in applications like wikis and blogs.

The Quick Adder bar:

The "Add New" interface in v2.1was simple but wasn't ALWAYS available. With v3, you can add spaces or content from anywhere, with a click. The Quick Adder bar is always available at the top of every Cyn.in screen enabling you to create new content in a space of your choice. If you are looking at starting a conversation or just asking a question, use the discussion text box to post it without navigating away from the page.

Faceted search and filtering:

Knowledge workers spend the likes of one day per week searching for people or information - connecting to people through people while looking for answers. V3 introduces faceted search and navigation to speed up information retrieval and allow users to filter down quickly to the answers they need. Faceted filtering allows you to multi-dimensionally slice-n-dice information in a manner that best accommodates your specific needs.

Customizable applications in a  space:

Customers told us they wanted more flexibility in the Spaces - freedom to select application types in a space. Now you can turn on/off any application in a Space and even define the default view of the Space. That means in a Space you can enable discussions and files or disable wikis. Or, you can turn off the dashboard and choose any application to be the default view of that Space.

Crowd rating / voting:

Encourage conversations and capture innovative ideas by getting peers to rate / vote for content in the site. Top rated items bubble up to the top and by applying the "wisdom of crowds" concept, top rated items can complement decision-making processes resulting in better decisions.

Cyn.in - On Demand now exclusively hosted on Amazon EC2

Get your own dedicated virtual servers in the cloud hosted exclusively with Amazon Web Services. We will not be offering shared instances of Cyn.in from this release. Each Cyn.in On Demand package with now provide a dedicated server instance in the cloud. This makes Cyn.in On Demand a true 'Appliance in the Cloud' offering and provides much stronger control and security to our customers. We will continue to provide the shared instance offering to our existing customers for the next one year.

Lots more - These are just some of the interesting features introduced in Cyn.in v3. Check out the list of Cyn.in v3 features here. Along with new features, we have worked hard towards improving speed and stability of Cyn.in and squashed hundreds of bugs in the process

A select set of customers have been using v3 actively in the production environment for a while now, and their response has been encouraging to say the least. We look forward to hearing your feedback.

Presenting the brand new Cynapse.com and the Cynapse Community!

Customer feedback and the open source community are the top innovation drivers at Cynapse and have been instrumental in the success of Cyn.in. We intend to take this interaction to a whole new level with the brand new Cynapse.com with a unified community built using Cyn.in integrated with the versatile Drupal CMS.

In the true spirit of open source, we invite Cyn.in users, enthusiasts and developers from across the world to come and share your ideas, provide feedback about Cyn.in, discuss and ask questions in our Cyn.in powered Community.

Check out the latest Cyn.in v3 features   |  Download Cyn.in v3  |  Join the Community

 

Video Notes: HiDef (1280x720), switch to full screen for best effect. Low bandwidth users should probably switch HD off by clicking the button which appears when you play it.

We've been working on improving the cyn.in buildout for the upcoming version. One of the things we've added is the collective.omelette recipe. Leaving the funny name aside, (it's a pun intended on the fact that pretty much whatever you do in a buildout is based upon pre-defined "recipe"s and that this one is really special in that it mashes up all the code in all available products, projects and everything that's there in your buildout together into a single linked folder chain. And if you didn't get the pun, ignore it, it'd not important for the rest of the stuff here.) Let's start with the usual alert:

Warning !

Warning! Danger, Will Robinson! Geek Developer alert! This video and blog post is for the software developer audience. And probably only of interest to people who think that building out cyn.in from source is pretty cool, and would appreciate another productivity tip that would greatly enhance their way of working with cyn.in. Everybody else will probably not make much sense of this, but is of course welcome to try, and fit in. ;) Ok. So here's my list of assumptions:

1. You got cyn.in working from buildout
2. You're surprised at the complexity of the codebase - all of cyn.in stuff exists in the src folder, but when you go into parts, and eggs, there's just too much stuff there to really comprehend and figuring out which code goes where, is really painful. This recipe is for you.
3. You're getting a hang of things. You understand that most of the plone codebase is concentrated around the CMFPlone product, and then you look for plone's kss and you can't find it, for example. This recipe is for you!
4. You'd actually like to use a GUI IDE tool to work with, rather than just using Notepad++,  gedit, vi, or whatever else it is that you do use for that sort of thing. Something that will give you intellisense for autofilling function names, showing you function arguments, and doing reference lookup jumps into outside code files, when the need arises. This recipe is for you, also.

In this video, I show how one can add the plone collective recipe called Omelette to your buildout. And then how it can be used for fulfilling the above. In this example, I show how the Komodo IDE product from ActiveState can be set up to work with cyn.in. This will give you the above intellisense, and yes, that's a major improvement over what you do currently. You could alternatively set up Wingware's Wing IDE for the same effect, in the same way, (and then some - in that you can actually hit debug breakpoints, and inspect variable values, but I use Komodo IDE to show this off because it's a bit simpler to set up and to use as well). And then there's some other IDE projects out there, but I'm unsure of their maturity. The first step is to get a normal running buildout. Then you just add a new "part" to your buildout and then configure it to the way you want it to be. In the setup I show, (which is the way it's going to be present in the upcoming code-base in cyn.in), we're setting up all source code in a predictably named "allsrc" folder, which is a sibling to the currently existing src folder that you're possibly already comfortable with. Once you build the buildout after you add the new part to it, you'll notice the folder getting created, and then when you go into the folder and have a look, you'll see that all source code that you need is neatly arranged in non-nesting folders. This is the linux "ln" command at it's finest, your code is not actually copied, it's just linked to. And yes, this recipe only works on linux, for now. All of zope, plone, cyn.in and all constituent products will be available in the allsrc folder after you run it, all linked up to go to their original locations, but still usable directly as it is available in the allsrc folder.

Cool?

Did you really get that? Let me restate. The code files you're staring at in the allsrc folder are not actually present, there. They're still at the original places they were at. This is a convenience recipe to "virtually" aggregate all the source code into a single root folder. Do not be confused when you're using your version control system (svn,git,mercurial whatever) with this. That said, editing the source in the allsrc folder is perfectly fine, and in fact that's the whole idea in the first place! Your code, your edits will all be done in this conveniently rooted folder, from your IDE. Just be careful that you're editing your own code and not going modifying plone itself, or any other external (non-development) egg directly. If you do this, your code will actually work on your instance, but will not go to other developers when you commit it, and worse, when you re-buildout, your changes will be overwritten - editing base stuff is still to be done in the normal way, by overriding and subclassing, and so on, in your own products. The video shows how convenient navigation becomes. Note the simplified folder chaining, there's no need anymore to have src/ubify.xmlrpc/ubify/xmlrpc and then, the code for it. xmlrpc is directly available at allsrc/ubify/xmlrpc, with the other parts lining up right beside it. Once you've looked at the refined code structuring that the Omelette recipe does for you, then it's time to move on to the next phase, actual editing. The video shows how easy it is to configure your Komodo IDE project to point source code lookups to the allsrc folder, and then goes on to show how the in-code lookups for functions, arguments and Ctrl+Click jumping to actual resource works. Try it out, it really aids in understanding the code flow.

Links:

• The plone collective Omelette recipe's PyPI page.
• The zc.buildout PyPI page (lots of in-depth info here on buildout and the available features/options)
• Komodo IDE, by ActiveState
• Wing IDE by Wingware

A big part of being a cyn.in developer is being one with the fine art of building out... your buildout. Geek / Tech warning! This post is best read if you're a software developer interested in working with cyn.in (and / or plone) and are interested in improving your development productivity. Ok, that dire warning out of the way, let's get down to it, shall we? :)

I restate my assumptions:

1. You downloaded the cyn.in source snapshot.
2. You actually opened the README file and went through it.
3. Figured out the dependencies and got through the buildout procedure
4. OR you're starting off from the plone.org community and have got a plone buildout running (yes, this applies to you too!)
5. You'd like to reduce the bandwidth / time it takes to build a buildout

So why does buildout take so long?

Well because cyn.in depends upon a whole lot of python eggs (and even a few old-style zope products) that are downloaded during buildout. The biggest of these is plone itself, because that depends upon more code than you'll ever end up going through (or at least that's what it looks like when you're starting out).

So how do we optimize our Internet usage? Well, several ways. Read on:

download-cache: This is most important to you if you build a lot of new buildouts from scratch. And when I say from scratch I mean on new operating system installs, or if you're into virtualization and appliance building then this one's for you! You can set this to a path outside your main buildout directory and instead of downloading directly from the Internet, buildout will first consult your download-cache directory to see if the file's already there. So while buildout will still spend time looking on the net for the correct version to download, for each egg, once it does figure out which one, it'll usually find the file already present in your cache. The idea of course is that your downoad-cache directory will be a network share somewhere that's mounted locally on a path, so you always have a pre-primed cache. You should have this setting in your own personal override config, (user.cfg in cyn.in buildout is a great example of this!). This is the minimal override that is usually required for per-buildout case, where you set up your personal settings, like port and network ip to bind to, the effective user to run under and so on. If you keep your download-cache setting in your main buildout.cfg then all developers will be forced to use or override it, which is not a good thing to do.

download-directory and eggs-directory:

Most developers should already be aware of this one. When developing you often have to recreate new buildouts repeatedly on the same computer with different filestates, typically in a multi-developer team where everyone's working on different branches in subversion and so on. For this kind of scenario, buildout provides these 2 settings to speeden things up, some. In buildout, packages can be marked to be on particular versions or they default to the latest (more on this in the newest=false setting). The idea with these 2 settings is that you should set them in your user-account-wide defaults file. Where? In linux, usually in your /home/username/.buildout/default.cfg folder.

/home/username/.buildout/default.cfg

That's:

• /home is where your user homes are
• /username is your's (just used cd ~ to land there, and then the pwd command will show you where it's at)
• .buildout is a folder you create in it
• default.cfg is a file that contians your defaults for buildout

In this default.cfg file you should put in these 2 lines:

download-directory = /location/to/where/you/want/all/downloads eggs-directory = /location/to/where/you/want/all/eggs

If you put these settings in the correct home folder location (and then go and actually create the target folder paths - buildout will error if they're not already present!) then buildout saves downloaded files in these locations as a default. The advantage to doing that account-wide for your user is that by default all buildouts will go there and re-use the files already present first. This is best used in combination with the below setting, newest=false. Note that the files here are used directly by every buildout made by your account. That's different from the download-cache where they're downloaded from. Why is this important? Well in the very, very, rare case that something in your normal download or egg directory is causing a problem, you can override it in your user.cfg override and fix the problem.

newest = false

This should be present by default in your main buildout.cfg itself. That way when any developer builds the buildout, it will by default only download the dependencies that are missing, if it finds matching dependencies already met, it will not go looking for a better one. This setting when combined with the above user-account default one is like magic, you can re-buildout any number of times after the first one, and do it without any Internet consumption at all! When you actually want buildout to look for better alternatives, then you simply add -n (that's small n, not capital. Capital N does the exact opposite, same as the setting above!) to your buildout command line and it will go hunting for the latest and the best.

So what's your buildout command line looking like now?

First time or force-check for newer dependencies is like this:

./bin/buildout -c user.cfg -n -vvvvv

And "normal" re-buildout is like this:

./bin/buildout -c user.cfg

The -c user.cfg part means that buildout should use user.cfg as configuration. user.cfg extends buildout.cfg, overriding just the personal settings that you want to change from default. -n tells buildout to go hunting for fresher eggs -vvvvv is a way of getting as much verbose log output as possible. More the v character's here the more the verbose the output. You want verbosity when you're doing it the first time - to diagnose error messages correctly, if they happen. In normal re-buildout you don't need these settings because you want the default, newest=false and verbosity is just pointless scroll. Hopefully that should speed up things some, especially if you're struggling. There are some more advanced techniques, of course, like ingeniweb's eggproxy product, which is the perfect way to create a fast, pass-through cached mirror of the PyPI on your LAN - that too only the eggs you need and re-use. But that's out of the scope of this post, perhaps some other time.

More?

If you want to read more about these sort of things then do let me know by adding your comments. If you have other tips to improve buildout efficiency then do put in the reference links or whatever else you can tell us about them, thanks!

It is often tricky to justify tangible, monetary benefits of Enterprise 2.0 software to customers. Starting from the age of NNTP, IRC, Email, Enterprise forums and Bulletin boards - these technologies, all concentrate on Increasing collaboration and benefiting from the collective intelligence. How is E2.0 different?

The focus of Enterprise 2.0 software is on the user experience. Enterprise software is complex to use and that makes it suck. The most basic yet the biggest challenge is to persuade employees to use these tools in their daily work. Enterprise 2.0 software inventors are walking that last mile to make these tools more intuitive, facilitating interactions and conversations among people and their knowledge. How? Spend a few minutes to check out the presentation below - published by Oscar Berg & Henrik Gustaffson.

In a very succinct manner this presentation accurately explains what is Enterprise 2.0, it's importance in the Enterprise and how increased level of collaborative working among employees can benefit organizations.

If you're using cyn.in in your organization and have a support question, you can email, call or post a ticket on the Cynapse Customer Care portal - whichever is easiest for you. The open source community forums are a great place to get detailed solutions to technical issues you face while using the cyn.in community edition. And If you're evaluating / using cyn.in and need a super quick solution to a problem, just tweet about it with #cynin or address it to @cynin. A Cynapse team member will surely respond to your query in real time with a solution.

The Cynapse team has been actively using Twitter for a long time where we have conversations with thousands of passionate cyn.in users across the world. We listen to what users are saying about our product cyn.in, our company Cynapse and discuss their views on collaboration and Enterprise 2.0 software. Its a huge marketplace out there in Twitter and we listen to the word on the street, are on the look out for spontaneous unsolicited feedback about cyn.in and sometimes for tips on new business. For the uninitiated users, we use it as a channel to educate them about the all the great technological products that we are inventing and the benefits it brings to their business.

Our goal is to help users wherever possible and to make ourselves available such that our customers talk to the real people who are behind the product and get their problems solved. We at Cynapse use Twitter for some of the following:

1. Customer support
2. Open source community support
3. Offer Tips about using cyn.in
4. Engage in conversations with customers and users
   
5. Publish company updates
6. Distribute deals and offers
7. Get feedback and feature requests
8. Evangelize Enterprise 2.0 and collaboration technologies
9. Identify prospects

Everyday we find new ways to help our customers through Twitter ... the possibilities intrigue us. Cynapse has 4 employees using Twitter actively, including the CEO and the CTO.

CEO - Apurva Roy Choudhury-  @apurvarc
CTO - Dhiraj Gupta - @dhiraj
COO - Viraf Sarkari - @viraf
Business Director - cyn.in - Romasha Roy Choudhury - @romasha

Follow us on twitter, introduce yourself and interact with us. We'd love to listen to your ideas, opinions, feedback or simply converse :)

Aside from the complex deployment, challenging back up-restore and an unusable interface for end users, Sharepoint is EXPENSIVE! A recently released market study conducted by Information Architected found that half of the organizations using Sharepoint experienced more effort and budget than expected.

While some of you might argue that you already own Sharepoint licenses, it actually requires an army of MOSS components to run along with it for a successful implementation. These components include (but are not limited to) Windows licenses, SQL Server licenses, base and enterprise CALs, Search servers and the list goes on. Add to this support, upgrade and integration costs, the total cost of ownership (TCO), overtime, simply goes through the roof.

One customer who has now successfully implemented cyn.in, was initially deciding between Sharepoint or cyn.in to be used as their collaboration platform. Listing out feature differences wouldn't work as Sharepoint has it all. The unmeasurable stuff - like Sharepoint's complex user interface that an average non-technical employee would find difficult to use, was not something he was willing to buy in. I used a Sharepoint Price Calculator tool developed by the folks at Bamboo Nation that gives a good ballpark estimate of total licensing expenditures. To my surprise (and the customer's too), Sharepoint pricing turned out to be astoundingly high for a 500 user company!

Here's a snapshot of the Sharepoint pricing:

The one time cost is approximately 91 times that of cyn.in!

If you are looking out for a collaboration platform and are comparing Sharepoint with other products, go ahead and get a ballpark estimation of the implementation cost here: http://community.bamboosolutions.com/blogs/sharepoint-price-calculator/default.aspx

In the times of the economic downturn, market researcher IDC is projecting a steep growth of the SaaS model - of over 40% in 2009. The right-sized, zero-CAPEX alternatives offered by SaaS vendors is going to lure customers to adopt such technologies. Even as companies seek to reduce thier capital expenditure and postpone new technology investments, Robert Mahowald, director, On-Demand and SaaS research IDC, says:

With a broad slowdown across IT sectors, businesses are increasingly bearish about their short-term ability to invest, whether for stability, growth, or cost savings down the road. But SaaS services have benefited by the perception that they are tactical fixes which allow for relatively easy expansion during hard times, and several key vendors finished the year very strong, reporting stable financial and inroads into new customer-sets.

From our experience of selling cyn.in On-Demand, I find it to be more true than ever. The economic conditions have forced businesses to consider a "change" that was not considered necessary during more affluent times. We've been in the SaaS business since 2006 and since the last quarter we have seen a steep increase in sales in our SaaS edition. Some of the most important reasons that we've seen are:

1. Businesses are looking at reducing travel costs for team meetings and even client meetings
2. Recession is making companies encourage their employees to work from home - reducing infrastructural spends at the office premises
3. Reduced staff due to layoffs is forcing companies to focus internal IT initiatives only on direct, line of business technology - and outsource infrastructure related management
4. Low, cost-saving technology options - Companies are aiming to reduce their capex by exploring hosted applications, wherein they have to pay-as they consume without making upfront investments

Is your company looking at adopting SaaS technologies? Do share your opinions in the comments. Read more about Benefits of SaaS