Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I u...
SYS-CON.TV
Free as in Beer By @DMacVittie | @CloudExpo #Cloud #OpenSource
The things to look for in your open source project

(Note: This blog originally posted to the Stacki Open Source project website. It has cosmetic changes to account for presentation differences between the two sites)

Many years ago, I wrote a blog that aimed to help organizations evaluate open source projects in terms of enterprise suitability. That blog was lost when the employer took the publication off-line, and my Google-fu has been unable to recover a copy (if you happen to have it, ping me, I’d love a copy). At the time I wrote it, I considered blogs to be dispensable, with less need to keep a copy than articles – because they were largely opinion. Turns out that precisely because blogs are opinion+insight, you have to refer to them more to update or defend than most articles. I’ve been saving them since shortly after that particular blog was published, but that was no help here.

(Note that my interest at the time of the first article was as a writer and an open source contributor. My interest now is driven partially by open source contribution – though it’s been nearly a year since I submitted to any projects except for a minor change to Stacki – and partially because I work for an open source sponsor, thus am in the market-space a lot more)

That being said, I’ve decided to write another. I was looking for the original blog because we have gotten a bit complacent about Open Source evaluations. It seems that there is a cycle that has emerged in our industry that follows a basic trend. Evaluation of Open Source projects gets important because of spectacular failures or mergings of projects. Evaluators discover that, for the most part, the parameters being looked at are very similar to purchased software, and slowly complacency sets in. Then we do it again. The shriveling of investment money in Silicon Valley combined with the current model of Open Source sponsorship means that many projects tied to existing vendors will be struggling. The ramifications of significant sponsorship are broad, and that’s why we’re here.

But the topic is more broad than investors causing problems. Projects in the best of times lose sponsorship because the needs of sponsors change – think of Satellite and Spacewalk. Spacewalk – and by extension Cobbler and several other technologies – has seen downgraded RedHat support when Satellite moved to a new architecture. Oh, officially they’re still supported, but the investment that RedHat is willing to make is obviously reduced, as they focus on the new architecture.

And that doesn’t even touch internal project politics. How many projects are you aware of that fractured and became less relevant. The one that springs to mind for me – because I was a heavy user at the time that it happened – is the Mambo (since discontinued)/Joomla split. A whole raft of developers and designers left Mambo and forked to start Joomla, leaving us users with a tough choice – convert or hope Mambo could keep up the updates. OpenStack had a tiff that threatened to blow into similar proportions over AWS support, which thankfully sane heads found a compromise path for.

And finally, or rather what should have been considered before all of the above became an issue, is technical capability and road-map. Does it do what you need, and are you able to modify it easily if not? Hand-in-hand with these questions are security – particularly since heartbleed came about and impacted just about everyone – and user management. Can you add/remove/restrict users as needed to get the job done? Does the project support RBAC? If so, is it solid? All questions that need to be asked in an enterprise environment (and should be asked regardless of where it’s deployed).

So, the things to look for in your open source project:


  • Maturity

It still astounds me that after years of experience, multi-million dollar operations will install Open Source that is largely vaporware written by one or two people with no long term roadmap. The idea being “it’s free”, but it isn’t if you’re installing and maintaining it – we’ve documented that over the years, so don’t. Yes, this poses a dilemma for new Open Source projects, but they can show maturity and stability by growing and finding acceptance at highly technical smaller shops.

And there’s the other end of maturity. Look for drop off of developer participation, look for sniping on bugzilla or the forums for a given project – particularly between project devs. This is a sign of trouble, and usually indicates the “ownership” that grows when this piece of the puzzle has been your baby for years. But it causes issues and bad feelings, poisonous to projects from reduced bug fixing to outright splintering.

Finally, in the middle stage, the thing to look out for is acceptance of help. It’s an open source project, people should be allowed to contribute. Large stable projects generally have a process that is designed to limit code changes because they’re in use in a lot of places and need stability, but most projects should be open to direct submission of changes, probably with review by a core team. If there is no process for users to update (my favorite is “You can’t change it, so fork it” – Really? You want people to do their development and not give it back to the community? Are you open source?), updates are routinely rejected, or the project source doesn’t build relatively easily on a new machine (no open source project I’ve worked on built easily on a new machine, but guidelines and helpful tips can make it minimally painful), then you should exercise caution. Resistance to community involvement is a symptom of egos running a project. No need to walk away over this issue – as we’ve already established, some projects have good reasons to limit submissions – but certainly look closely at what those reasons are.

  • Core Developers

The heart of any open source project is its core developers. Those who are there all the time, giving their time and effort to make it a success. Relevant questions for an organization looking to use the system are simple – What experience do those developers have? Is this their first foray into either open source (which is a different political model) or the market the product is entering? How many are there? What is their history of delivering? Are they cooperative, or fragmented? Basically, you need to determine if you can trust them with a core piece of your infrastructure. The other points here touch a little on this topic, but it was worthy of a separate bullet point, because the core developers and their relationships/experience are good predictors of stability, just as the overall number of submitters and the trend in that number is.

  • Sponsorship

If a project has corporate sponsors, look to see how many there are. A single sponsor is going to over-ride user desires when there is conflict. This is not a slap at sponsorship, it is an observation that the project team is motivated to pay the bills that the project generates, and the corporate sponsor sees their needs as important for everyone, particularly if the corporate sponsor is in or adjacent to the space of the open source project. This can have a negative impact. Do you wish the system integrated as easily with competitors of the corporate sponsor as easily as the sponsor? That’s a symptom.

Over time, concerns about consortium sponsorships have lessened. While it was (and occasionally still is) a valid concern when large corporations in direct competition get together to sponsor a project, those days are waning as value-add and services replace lock-in for most corporations’ sales goals. It is still worth watching though, what are the customizations a given sponsor uses? Just like standards body participants will sometimes use the gaps in the standards they helped develop to build lock-in mechanisms, so too do some members of consortiums. It is worth being aware of, but as I said, the concern is much less than it used to be, so not worth wasting too much time on.

Considering the time, a related concern is investor money. Is your project solely sponsored by a venture-backed company? If so, make certain it is not at the whim of investors. Should they pull funding from the backed company, what happens to the project? Oh sure, it’s open source, so it can be kept alive, but don’t underestimate the temporary mayhem and loss of users – and by extension developers – that such a scenario can create. While better than a startup going out of business and leaving unsupported closed-source projects behind, it’s not a ton better unless you have developer man-hours just laying around waiting to be poured in.

  • Technical Capabilities

We’ve all seen the open source project spectrum – from flashy but not much ability to get it to work with all the other tools in your datacenter to downright pliant and designed with integration in mind. Know what your integration needs are – particularly in light of automation and DevOps developments in your organization, and make certain the project can fulfill them. In the automation world for example, it is great to have a tool that can do one thing really well, but better if that one tool can be integrated into the tool-chain you are using to give a coordinated solution to automation issues. As time goes on it will even become necessary.

Check the real cost. Yes, the software is free, but there are a variety of charges from hosting to development to ops that need to be considered, as we all know. Compare what it is likely to cost to keep product A alive and working in relation to the other projects in the space. These analysis have actually sometimes shown that you are better off using purchased software (depending of course on the market and the products) than an open source project… Considering that can be the case even once, certainly a comparison of open source projects on the same TCO grounds can give you an idea what might be a better choice.

  • Support

Another perennial conversation is support. Some open source users are happy to be self-supporting, they have the staff and knowledge to do so. But the complexity of systems and the number of applications running in your average datacenter have greatly reduced this trend. Most organizations want somewhere to go when things go wrong. Forums and Google Groups can do that, but for corporate responsibility, a vendor to get help from is often more appealing, even though it makes Open Source not free (or the famous “Free like a puppy” quote from Sun). Often a sponsoring company is willing to offer its services for a fee (full disclosure, this is the model StackIQ – my employer – uses for Stacki). While the “sole sponsorship” issue (mentioned above) is the other side of this coin, these companies tend to be less obstructive simply because they’re seeing what users other than themselves are having to deal with on a regular basis, and can offer or recommend updates that solve general problems of the user base. Just make certain you include support in TCO calculations, and if you do, don’t include nearly as many man-hours for bug/integration issues. Each open source project is different, so make certain you understand your options.

  • Security

Since I got ahead of myself and mentioned security above, I’ll just reiterate that you have a security infrastructure, how the tool integrates into it and makes use of it matters. So does how well the source is written. While amazing, yes there are still buffer overflow and cross-site scripting vulnerabilities in open source projects (though less and less as time goes on, thankfully). Find a way to gauge the security of the system based on your organization’s needs, and do the tests. No sense putting a vulnerability infested product into the datacenter if you can avoid it. If you’re not familiar with performing such assessments, OWASP is a great place to start figuring it out.


Local conditions always win versus pundit bullet lists, so of course you will have other things to add, and a list like this covers what’s important at a pretty high and condensed level. I’ve seen evaluations that were far more broad and far more detailed than this list, but my aim was to remind people to be vigilant, and do what’s best for their org, not to build an exhaustive list. Heck, this blog is already too long. Adding all that orgs look for would turn it into a book.

As I and countless others have said over and over, in the end you are going to be stuck with this software. Do some due diligence, it is no more fun to have to transition off an open source product than to have to transition off a closed source product – manhours are wasted and frustration runs higher. So a little pre-deployment footwork can go a long way.

Of course none of this should trump suitability to task – if no one else is doing the job you need done, then it’s worth getting involved and driving the OSS project further along, while getting the benefit of not having to completely re-create the wheel.

I will end how I often do… Your organization is running, which is a sign that IT as a group is delivering. Keep doing what’s best for the org, no matter what pundits like me suggest.

Read the original blog entry...

About Don MacVittie
Don MacVittie is founder of Ingrained Technology, A technical advocacy and software development consultancy. He has experience in application development, architecture, infrastructure, technical writing,DevOps, and IT management. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.

SOA World Latest Stories
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one l...
Consumer-driven contracts are an essential part of a mature microservice testing portfolio enabling independent service deployments. In this presentation we'll provide an overview of the tools, patterns and pain points we've seen when implementing contract testing in large development ...
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portabil...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand usin...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is founda...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


SYS-CON Featured Whitepapers
ADS BY GOOGLE