PLM and Open Source Checking Tips

PLM and Open Source Checking Tips

Open Source Software (OSS) is a wonderful thing. For the last decade, open source changed the world of software development. PLM industry has their own open source rock stars. While I can see less hype around ‘open source’, I keep watching open source initiatives in PLM space. One of the things that very often debated in open source community is the definition of open source. In my view, the definition of open source provided by Wikipedia is getting better. Here is the one I captured today:

Open-source software (OSS) is computer software that is available in source code form: the source code and certain other rights normally reserved for copyright holders are provided under an open-source license that permits users to study, change, improve and at times also to distribute the software. Open-source software is very often developed in a public, collaborative manner. Open-source software is the most prominent example of open-source development and often compared to (technically defined) user-generated content or (legally defined) open content movements.[1]

However, this definition is still very vague. In order to prevent usage of the open-source software term as a meaningless marketing buzzword, we need to apply some rules. Usually, the discussion focuses on what type of OSS license is used. However, I think it is not enough. Few days ago, I bumped into the following article – How to evaluate open-source software. The article is short and worth reading. I found it very practical. It provides 7 checking tips for OSS: license, activity, age of project, unit test, code quality, basic use test, and modification test.

Does Open Source PLM fail the test?

There are few open-source PLM products, initiatives and projects I’m following. They are not equal and clearly cannot be compared. At the same time, I tried to poke open source PLM websites and tried to make some initial conclusion about how these products and projects are compatible with 7 points checking tips.

1. Aras PLM. Aras is the most visible player in open source PLM community. It includes a mature product, many reference customers and well-established community of developers and service providers. Aras is using “enterprise open source” term to describe Aras model. You can get most of the information about Aras including licensing here. Aras relies on several open source licenses. You can get Aras’ source, but for my best knowledge, it requires a specific subscription level.

2. Open PLM. Open PLM project started few years ago. Open PLM focuses on ECM (I assume “content management”) around product data. The project is using Django framework and includes some other OSS like Apache and PostgreSQL. It uses GPLv3 license.

3. Open ERP / PLM. Another project I tracked connected to open source PLM space. This project is connected to OmniaSolutions. You can get more details here. It features many typical PLM functionalities starting from CAD integration and ending with BOM management and Manufacturing processes. Here is the link to Open PLM ERP wiki with documentation, video and downloads.

4. Open Source PLM activity from Prodeos. The website is a codeplex link to variety of PLM-related project and tools. Most of them related to Aras PLM and quite outdated (2010). Nevertheless, the project list is interesting and includes some utilities you can probably use not only for Aras – Office connector, AutoCAD 2011 connector, 3Dxml viewer, etc. It uses Microsoft Public License (Ms-PL).

What is my conclusion? Aras is clearly the most mature and dominant player in “open source PLM” eco-system. From the standpoint of compliance to 7 points check list, I think three of them are the most important – license, update history and code quality / unit test. Coming to OSS, you first check you license rules. Then you check how many people are using that and trying to see how to re-use the code for your project. I’m interested to learn about additional OSS PLM initiatives. If you know them, please contact me. Also, I’m very interested to learn more about your open-source experience. Speak your mind.

Best, Oleg

Share

Share This Post

  • EdA

    Perhaps the confusion stems from an assumption that all community
    contributions — in order to be open — are always explicitly licensed. I can
    understand why: Aras must apply an industry-recognized
    OSS license to something other than Innovator to rationalize the “Enterprise Open Source” marketing position.

    But
    surely the assumption is incorrect.

    Undoubtedly
    you’ve noticed that some contributors, irrespective of OSS project, provide little more than bare files (minimal
    descriptions, no user help, no implementation guides) with uneven quality and utility.
    As Android apps demonstrate, expert users may find uncurated OSS interesting while casual
    users find it painful to wade through.

    In
    contrast, our approach to building community solutions is a rifle, not a
    shotgun. We value and encourage active collaboration with our customers, jointly developing complete,
    coherent, documented solutions. The extra “scaffolding” we provide appeals to our
    typical small/medium business users, who have little interest in — and often no IT
    resources for — mastering PLM system rules and interfaces.

    Of
    course, individual users can tailor solutions based on our XML-based object
    model (www.plmx.org), custom attributes, ODBC data views, XSLT transformations,
    and templates for legacy data import. But customers purchase PDXpert to solve
    their engineering data management problems, and not because developing open
    solutions is inherently appealing or economically justifiable. So, their first stop is usually to contact us for advice and guidance; we counter with expertise to enhance
    their work, explore design tradeoffs, describe the implementation, and even test
    the finished solution.

    In
    this context, our customers’ contributions are truly open, with the added advantage
    of being curated and augmented to increase their utility to others.

    As
    we developed these solutions, we never considered controlling the related downloads
    by a license. The full solutions were created collaboratively; related files are
    simply part of the published application notes, acknowledged by all as freely
    downloadable and modifiable.

    So,
    although ASI “could” apply an OSI license to our solutions, our reluctance
    to do so is because such license will be more restrictive, not less. We don’t limit
    how the world uses our collaborations, even outside our product or industry.
    And we ask for nothing in return, not even that derivative works also be OSS (i.e.,
    copyleft).

    Meeting
    the Aras EOS definition is a trivial exercise in semantics and my original point
    remains: “Enterprise Open Source” starts with a standard PLM architecture, slaps
    an OSS license onto an inherent capability, and celebrates the emperor’s newer
    clothes.

    EOS
    is the OSS equivalent of cloud washing, and I think Aras can do better.

  • EdA

    Marc, perhaps the confusion stems from an assumption that community contributions — in order to be open — must be explicitly licensed. I see why: Aras must apply an industry-recognized OSS license to something other than Innovator to rationalize the “Enterprise Open Source” marketing position.

    But surely the assumption is incorrect.

    Undoubtedly you’ve noticed that some OSS contributors provide little more than bare files (minimal descriptions, no user help, no implementation guides) with uneven quality and utility. Similar to Android apps, uncurated OSS may be interesting to experts while casual users find it painful to wade through.

    In contrast, our approach to building community solutions is a rifle, not a shotgun. We value active collaboration with our customers, jointly developing complete, coherent, documented solutions. The extra “scaffolding” we provide appeals to our typical small/medium business users, who have little interest in — and often no IT resources for — mastering PLM system rules and interfaces.

    Of course, users can create open solutions based on our XML-based object model (www.plmx.org), custom attributes, ODBC data views, XSLT transformations, and templates for legacy data import. But customers purchase PDXpert to solve engineering data management problems, not because solution development is inherently appealing or economically justifiable.

    Users naturally first turn to us for advice and assistance; we respond with expertise to enhance their work, explore design tradeoffs, describe the implementation, and even test the solution. In this context, our customers’ contributions are open, with the added advantage of being curated and augmented to increase their utility to others.

    We never considered controlling these solutions by a license. All contributions are simply part of the published application notes, acknowledged by all participants as freely downloadable and modifiable.

    So, although ASI “could” apply an OSI license to our solutions, our reluctance is because such a license will be more restrictive, not less. We don’t limit how the world uses our collaborations, even outside our product or industry. And we ask for nothing in return, not even that derivative works also be OSS (i.e., copyleft).

    Meeting the Aras EOS definition would be trivial, because “Enterprise Open Source” starts with a standard PLM architecture, slaps an OSS license onto an inherently open aspect, and celebrates the emperor’s newer clothes.

    EOS is the OSS equivalent of cloud washing, and I think Aras can do better.

  • EdA

    (Sorry for the delay, Marc. I seem to have problems with Disqus.)