为开源贡献内部工具值得吗? [英] Is contributing internal tools to open source worth the effort?

问题描述

我知道这是一个普遍的问题，但我想听听其他人对我们案件的看法:

I know this is a general question, but I'd like to hear other people's opinion about our case:

我在一家小公司工作.我们的主要开发工具是PowerBuilder，它是一个非常有限的IDE，社区正在缩小.我们创建了一些工具，供内部使用以解决特定需求.他们没有经过适当的设计或测试，也没有达到生产质量. OTOH，它们确实为我们节省了很多时间，并且可能也会对其他人有所帮助.我确定其他公司也使用相同的工具，并且想知道与他人共享它们的做法有多么普遍.如我所见-

I work in a small company. Our main development tool is PowerBuilder, which is a very limited IDE with a shrinking community. We've created some tools, which we use internally to solve a certain needs. They have neither been properly designed nor properly tested, and are not in production quality. OTOH, they do save us quite some time, and might help others as well. I'm sure other companies have the same kind of tools, and was wondering how common a practice is it to share them with others. As I see it -

优点:

• 好业力
• 更多关注我们的网站
• 也许会从别人那里得到修复和改进

缺点:

• 如果不进行更多开发，这些工具可能会使我们看起来很糟糕
• 发布代码需要付出一些努力
• 某些工具可能过于专业化，无法满足我们的需求
• 鉴于社区规模的不断缩小，整个工作可能会被忽略

您或您的公司是否曾经提供过此类工具，或使用过他人开发的此类工具?值得付出努力吗?

Have you or your company ever contributed such tools, or used such tools developed by others? Is it worth the effort?

对于那些想知道的人，我想到的工具包括-

For those how wondered, the tools I had in mind include -

• 一种工具，它通过列出已签出给当前用户或其他用户的对象，备份签出的对象并重建PBG，使SourceSafe的使用更加容易.
• 像Spy ++一样在运行时识别PB控件的工具(需要目标应用程序具有一些基础结构).
• 用于SQLite的PBNI包装器(进程内访问，无ODBC).
• SQL客户端，文本测量工具等

推荐答案

开放源代码"最初意味着您发布了一个工具，并且使源代码可用.由于某些项目是预期的，并且在某些情况下通过许可证要求要求重新提交对源代码的更改以进行共享，因此开放源代码"现在经常会添加协作开发"的概念混合.我做了(或试图做)后者；请允许我分享.

"Open source" originally meant you published a tool, and you made the source available. Because of some projects that expected, and in some cases through licenses demanded that changes to the source code be resubmitted for sharing, "open source" now quite often adds the concept of collaborative development to the mix. I did (or attempt to do) the latter; allow me to share.

与可用资源和协作开发开源相关的工作量之间存在很大差异.

There are magnitudes of difference between the effort associated with source available and collaborative development open source.

领导力:您需要告诉人们变更的对象，内容，地点，时间，原因和方式.而且很有可能，您需要在外交上p戳和刺探您的志愿者.您可能需要定义愿景并确定项目目标的优先级，然后在有人尝试以其他方式处理事情时强制执行这些目标.而且，除非您只希望人们通过偶然性来使用您的工具，否则您将不得不做广告，在引起注意和花哨的地方做一条非常细的界线(甚至在Internet上更细).如果该项目要实现功绩主义的概念，那么许多开放源代码支持者都认为应该这样做如果发生这种情况，那么有人将不得不判断人们的成就并适当分配权利和责任.

Leadership: You need to tell people the who, what, where, when, why and how of changes. And very possibly, you'll need to diplomatically poke and prod your volunteers. You may need to define the vision and prioritize goals of the project, and then enforce them when someone tries to take things another way. And, unless you only want people to come across your tool through serendipity, you'll have to advertise, running that very thin line (even thinner on the Internet) between attention-getting and gaudy. If the project is going to implement the concept of meritocracy, as many open source proponents say should happen, then someone will have to judge people's accomplishments and dole out the rights and responsibilities appropriately.

工作流程:我还没有通过任何想象力进行详尽的搜索，但是我还没有看到一个能够完成我所需要的一切的协作开发平台.开源协作开发的部分要点是，代码审查涉及的数量将涵盖代码提交质量中的任何潜在问题；我还没有看到集成到协作开发平台中的免费工具，该工具可以干净利落地进行管理(例如，计数代码审查；在 x 审查后自动升级).我们必须处理这些问题，将手动方法侵入现有工具中.可能在某个时候，您必须定义一个版本并创建一个构建.然后是艰巨的任务，例如文档. (每次尝试免费发行新版本的没有发行说明吗?狂怒！咧嘴)

Work flow: I haven't done an exhaustive search by any stretch of the imagination, but I have yet to see a collaborative development platform that did all the things I needed. Part of the point of open source collaborative development is that the quantity involved in code review will cover any potential issues in quality of code submissions; I haven't seen a free tool integrated into a collaborative development platform that helped manage that cleanly yet (e.g. counting code reviews; auto-promoting after x reviews). We had to handle that, hacking manual methods into the existing tools. Probably at some point you'll have to define a version and create a build. Then there's the grunt tasks like documentation. (Ever try to release a new version of something free without release notes? The furor!! grin)

特定于PB的问题:PowerBuilder是一种商业工具，尽管有便宜版本可用，没有免费版本.添加到PB11中的DRM可能减少或消除了开发人员可能正在为复制其办公室PB家庭而制作的盗版行为，而PB11和更高版本具有双重许可政策，允许开发人员合法地将其副本带回家(经许可和合作).的原始许可证所有者创建第二个许可证)，我看不出有很多事情要做. (没有科学研究，这就是我所看到的.)这减少了很多潜在的合作，即使是来自发烧友的合作也是如此. PowerBuilder版本之间的代码兼容性问题，以及每个版本都拥有很少人的事实，将再次限制您的潜在贡献者列表.

PB-specific issues: PowerBuilder is a commercial tool, and while there are cheap versions available, there are not free versions. The DRM added to PB11 has probably reduced or eliminated piracy that developers were probably doing to take copies of their office PB home, and while PB11 and later have a dual license policy that would allow developers to take home a copy legally (with permission and cooperation of the original license owners to create a second license), I don't see a lot doing it. (No scientific study, that's just what I see.) That cuts down a lot of potential collaboration, even from enthusiasts. Issues of compatibility of code between versions of PowerBuilder, plus the fact that very few people will own every version, will limit again your list of potential contributors.

别误会我的意思.我很想在PowerBuilder社区中看到更多的协作开发开源.我很想知道自己如何解决问题，并且正在努力研究是否可以进行新的模型工作. (恕我直言，我遵循流行模式的第一次尝试失败了.)

Don't get me wrong. I'd love to see more collaborative development open source in the PowerBuilder community. I'd love to know how to work out the issues myself, and I have an effort in the works to see if I can make a new model work. (My first effort to follow the popular model failed miserably, IMHO.)

是否有理由对将ZIP文件上传到网络并忘记该文件感到不安?我不知道.与4年前的ZIP文件相比，在3 1/2年前的最新贡献是所有人都在哪里?"的SourceForge项目中，还有更多的骄傲或尴尬吗?为什么 Sybase CodeXchange 从协作开发平台发展到一个可用平台:几乎没有人使用协作开发功能.如果您的代码可用源代码开放源代码，那么您将拥有很多公司.

Is there a reason to feel badly about firing a ZIP file up to the web and forgetting it? I don't know. Is there any more pride or embarrassment in a 4 year old ZIP file as opposed to a SourceForge project whose last contribution 3 1/2 years ago was a post "Where the heck is everyone?" There is a reason why Sybase CodeXchange devolved from a collaborative development platform to a source available platform: next to no one was using the collaborative development features. If you source available open source your code, you'll have plenty of company.

顺便说一句，CodeXchange可能是您对PowerBuilder社区可见性的关注的答案，尽管您会失去网站访问量. PowerBuilder Web Ring 是另一种效果明显不佳的方法，可帮助您保持可见度并保持流量在您的网站上，但是它需要在您网站的目标页面上有一个导航栏. CodeXchange可能也是一种克服您对代码质量和共享目的狭窄的担忧的方法. 咧嘴

BTW, CodeXchange may be an answer to your concern about visibility to the PowerBuilder community, although you'll lose the web site traffic. The PowerBuilder Web Ring is another, significantly less effective, method to help your visibility that keeps traffic on your web site, but it demands a navigation bar on the target page on your site. CodeXchange may also be a way to get over your concerns about code quality and narrowness of purpose of what you have to share. grin

您应该怎么做?不要低估协作开发共享所付出的努力，但也不要让它阻止您使用可用的资源共享.

What should you do? Don't underestimate the effort with a collaborative development sharing, but don't let it stop you from a source available sharing.

祝你好运

特里.

这篇关于为开源贡献内部工具值得吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！