Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

SD West 2009

Tuesday, March 17, 2009 Pablo Santos 2 Comments

SD West 2009 is over and we're just back from our trip to San Francisco. It was great to meet developers there and also some of our competitors such us Accurev and Perforce. I actually had a very interesting and friendly talk with Damon Poole, Accurev's CEO, about a number of different business related things.

We had the opportunity to talk with developers about our newest 2.7 release, which grabbed a lot of attention, especially the new distributed capabilities.

It was our first time at SDWest, and it's been a lot of fun. The booth was located just at the entrance of the expo area, so we had lots of visitors. We gave away hundreds of T-shirts (two different designs) most of them during the first day (until we almost run out of them) in just a few minutes. (We'll have to bring more next year!)

We also gave away Plastic License Cards, a collection of four different pictures which included 2 free Plastic SCM Professional licenses, I don't remember the exact number anymore, but we almost run out of them too.

Wednesday evening we attended the Jolt Awards ceremony which was an exciting event. This year was the first time we submitted Plastic SCM to the Jolts, and we were more than happy to se how it was selected as one of the finalists among a number of SCM systems, so our mission was accomplished, but it was good to see how Open Make finally got the Jolt, after several years on the list. (Note to self: publish a tutorial about OpenMake/Plastic integration asap).

So, we're eager to go back to Santa Clara next year and hopefully unveil there the upcoming Plastic SCM 3.0 :-)
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.


  1. Hi,

    Damon Poole is founder and CTO of AccuRev. Lorne Cooper is CEO.

    Great to see Openmake get some recognition as well, though I'd like to see them win in a Build and Continuous Integration category next year. Given it was the "Change and Configuration Management" category. :-)

    Have a great year.

  2. Thanks Alex for the kudos - Let me clarify why Meister is in the Change and configuration management category - it is a great observation.

    One of the primary purposes of a versioning or source code management tool is to assist with tracking what source code was used to create the executable running in your production environment. But there is one problem with this requirement - SCM tools can't convert source code into binaries. Developers and SCM teams want to be able to validate that the source code they are managing in their SCM repository is actually being used in the binaries. This occurs in the build process (conversion of source to binaries).

    The reason why the Change and Configuration Management category is appropriate for OpenMake Meister is that Meister is the process that actually takes the SCM managed source and manages the process, carefully, of converting the source into binaries. This conversion is a critical step in the change and configuration management process. So there is really no better category for a build automation tool such as Meister.

    Other tools that call themselves build management or Continuous Integration servers really do not manage the compile and link process, they manage a workflow that calls a process that creates the binaries, normally a Ant, Maven or Make script. I would agree, a workflow tool of this kind should not be in the change and configuration management category. These tools, even the "CI" component, is really more like job schedulers.

    Meister has no competitors in the area of build automation. Accept for z/OS solutions like CA Endevor or Serena ChanageMan, no other commercial tool that positions themselves as a build management tool or SCM tool actually does the job of creating binaries and tracking the source back to the binaries with footprinting – regardless of language or OS. And remember, Meister not only reports on what files were used in the compile that were managed under SCM control, it also reports on every other 3rd party library, class, etc that was used in the compile but not under the control of SCM.

    Hope that clarifies why Meister deserves to be in this category. Without a carefully managed build, you never really know what source went into your binaries, even when the source is managed in an SCM repository. The build (conversion of source to binaries) is the missing change and configuration management link.