Add draft posts

site/content/drafts/148.rst

+"Open source mistakes for enterprise newcomers" on O'Reilly Radar
+#################################################################
+:date: 2017-05-10 20:40
+:author: James Vasile  
+:category: Uncategorized
+:slug: 148
+:status: draft
+
+[caption id="attachment_150" align="aligncenter" width="300"]\ |A paved path bordered on its left side by a wooden slat fence turns right through woods. The sun sets in the background.| Courtesy of Martin Brigden, under CC-BY. Source: https://flic.kr/p/ngi9Rx[/caption]
+
+OTS partners James Vasile and Karl Fogel recently wrote `a post for O'Reilly Radar <https://www.oreilly.com/ideas/open-source-mistakes-for-enterprise-newcomers>`__ about common mistakes that companies make when they start to get involved in open source.  They write:
+
+   Open source reinvents relationships and business dynamics, turning customers and even competitors into collaborators. Firms embrace it to encourage those dynamics, when the benefits of participating outweigh the gains from going it alone with proprietary code. But open source isn't an outcome in itself. It is an approach for finding where different firms’ interests intersect and helping them cooperate there — but it is the path, not the place. To enjoy its full benefits, one must visibly walk that path.
+
+Thanks to Andy Oram and Adam Flaherty for their expert editing and advice.  You can `read the full article on O'Reilly <https://www.oreilly.com/ideas/open-source-mistakes-for-enterprise-newcomers>`__.
+
+ 
+
+ 
+
+.. |A paved path bordered on its left side by a wooden slat fence turns right through woods. The sun sets in the background.| image:: http://blog.opentechstrategies.com/wp-content/uploads/2017/05/path-pic-300x185.jpg
+   :class: wp-image-150 size-medium
+   :width: 300px
+   :height: 185px

site/content/drafts/165.rst

+Mediawiki Tames Unruly Text Data
+################################
+:date: 2019-01-23 16:20
+:author: james
+:category: Uncategorized
+:slug: 165
+:status: draft
+
+OTS has been working with the `MacArthur Foundation <https://www.macfound.org/>`__. They're doing something interesting with a private install of Mediawiki, the software that runs Wikipedia. They have a largish set of text data and documents that they need to organize and make available to reviewers. Mediawiki turns out to be a very efficient way to turn a pile of undifferentiated text and files into an organized place for interacting with it.
+
+The text data is a csv file. It is a messy collection of giant blocks of text resulting from web forms. There are 1500 rows, which isn't a lot for a computer but is a lot for a human to process, especially when those rows can run for many screens. The text includes links to videos. If you open the csv file and try to read entries there to review them, you're going to have a bad time. The documents are 5 thousand files: 9 Gb of pdfs, Microsoft Word and Microsoft Excel docs, some in Zip files. A lot of the data is private and needs to be live in secure places. Making all that info and those files available to reviewers is a pain.
+
+Macfound came up with what we think is a rather smart idea. Rather than build a custom interface to this data set, we loaded it all into a wiki. Reviewers get a table of contents, easily displayed text, embedded videos, and links to the external documents. They can hit the edit button and leave comments directly on the page. Many of them are already familiar with wikis as users (though not as editors). This is a huge usability win-- the reviewers are not generally highly sophisticated users of technology, but they ramp up fast when you sit them in front of a familiar-looking wiki.
+
+Overall, this is a **very** cheap and fast route to making a jumbled pile of incoming data available directly to the people who need to work with it. We scripted the process of loading it into the wiki, and we can script the process of moving the data to other processes as needed. The wiki gives us all kinds of nice-to-haves for free: change/revision management, fine-grained access controls, indexing, and easy ways to see what has changed most recently. New features are just a plugin away, and Mediawiki has a large set of plugins available for us to use and/or customize. We're working next on exporting subsets of the data to PDF for easy sharing with collaborators.
+
+Of course, we're sharing the software we wrote to get this working. Our first step was sanitizing the messy data input. That work is quite specific to our dataset, and `we share it on GitHub <https://github.com/OpenTechStrategies/MacFound>`__ just so people can see how we approached the problem. The actual code will not work with your dataset unless you make some major changes to it. Then, we ran `a more generic tool to read the sanitized cvs file and put it in the wiki <https://github.com/OpenTechStrategies/csv2wiki>`__. Finally, we wrote an `upload tool <https://github.com/OpenTechStrategies/csv2wiki/tree/master/upload_files>`__ to bulk upload files into the wiki and then add text links to those files. If you want to upload a bunch of files to your Mediawiki instance and then link to those files from wiki pages, there are a lot of fiddly little things you need to do. Hopefully `our tool <https://github.com/OpenTechStrategies/csv2wiki/tree/master/upload_files>`__ can help you shortcut that process. Mediawiki has a ton of safeguards that make uploading files difficult. We don't need those safeguards-- the wiki we're making is for internal use and we don't think anybody is going to try to sabotage it. if you base your upload on our scripts, you might want to retighten security after the uploads.
+
+You might also want to be aware that the Mediawiki API for uploading can be temperamental. The python libraries for accessing it will surprise you, and not in good ways. We had to work around some old Mediawiki bugs (maybe we'll fix them and upstream the changes) and some non-standard behavior. We're using Mediawiki in a way that it wasn't originally intended, so some difficulties were expected. Overall, we're quite happy with the final product.
+
+Having built a custom wiki as a way to present and edit data for team members, we think this is a prototype-level solution. It's fast, dirty, cheap, and effective. The work was fun and interesting, and we are eager to see how this technique might apply to other environments. A second wiki would also spur us to improve the tools and generalize them some more. If you have a largish text dataset and documents that you're having trouble approaching, drop us a line. We'd love to help!

site/content/drafts/229.rst

+New Blog Series
+###############
+:date: 2018-12-13 07:27
+:author: james
+:category: Uncategorized
+:slug: 229
+:status: draft
+
+By now, everybody in the tech world has noticed Microsoft's pivot toward open source. From `joining the Linux Foundation <https://www.linuxfoundation.org/press-release/2016/11/microsoft-fortifies-commitment-to-open-source-becomes-linux-foundation-platinum-member/>`__ to `bringing its deep patent portfolio to OIN <https://azure.microsoft.com/en-us/blog/microsoft-joins-open-invention-network-to-help-protect-linux-and-open-source/>`__, Microsoft has been making splashy public moves and deepening its commitment to the open source path. These visible signs of change within Microsoft reflect a shift that began several years ago, and if you look inside the company, you will see organizational changes and skill building aimed at preparing Microsofties to be "all-in" open source participants.
+
+As a celebration of our community growing in collaboration, and to support Microsoft as it continues to gain open source sophistication, OTS will be publishing a new blog series in partnership with Microsoft. These posts will build on the `archetypes <https://blog.opentechstrategies.com/2018/05/field-guide-to-open-source-project-archetypes/>`__ research we began `with Mozilla <https://opensource.com/open-organization/18/9/mozilla-open-archetypes>`__ and attempt to provide deeper treatments, new archetypes, and practical advice on how to use archetypes to support strategic open source engagement. The audience we have in mind for these posts are managers with real world goals who are using open source to establish ecosystems, build standards, disrupt competitors, or simply to deliver faster/cheaper/better.
+
+Posts in this series will be sponsored. They will not be advertisements for Microsoft, and most will probably not mention Microsoft products or activities at all. Rather, we will write general materials of use to anybody doing open source in an enterprise context. We hope they will be useful to a wide audience.

site/content/drafts/426.rst

+How to Get Involved in an Open Source Project
+#############################################
+:date: 2019-06-30 18:14
+:author: kfogel
+:category: Uncategorized
+:slug: 426
+:status: draft
+
+TBD: will need to find an image.
+
+On Twitter I asked
+
+Hey, folks, what's your best current answer to a person who says "I'd like to get more involved in open source -- how do I find a project that will be appropriate for me?" I get this question all the time. I used to point them to `@\ OpenHatch <https://twitter.com/openhatch>`__ but alas it's now defunct. Thoughts? (https://twitter.com/kfogel/status/1144648353873051649)
+
+Got a lot of answers:

site/content/drafts/577.rst

+Open Source's Eternal September
+###############################
+:date: 2022-03-11 18:57
+:author: james
+:category: Uncategorized
+:slug: 577
+:status: draft
+
+| History lesson on Eternal September
+| Description of growing ecosystem
+| Legacy companies vs new entrants
+| Not enough experienced people to keep up with need for knowledge
+| OSPO implications

site/content/drafts/579.rst

+TBD re Governance
+#################
+:date: 2022-03-11 18:59
+:author: james
+:category: Uncategorized
+:slug: 579
+:status: draft
+
+I think people often ask about open source project "governance" when they're really asking about "participation". Participation comes before governance. Participation ranges from basic things like "How do I contribute (e.g., code or documentation)?" to larger questions like "What are the available routes for investing in this project?", "How would one go about gaining influence in this project?", etc.
+
+That last one might sound like a governance question, but it's really not. For the most part, influence in a FOSS project is achieved by committing developer time and other resources. Of course, it's still important to implement those commitments in smart, strategic ways -- different techniques are appropriate for different projects. One can't just barge in with massive PRs. All I'm saying is that it's usually not about governance. One can go very far along the participation road before ever running into a genuine governance issue.
+
+So what is actual governance about?
+
+Governance is what groups use to make decisions about the allocation of collectively-owned non-replicable resources. Since these kinds of resources do exist in FOSS projects, there is such a thing as governance. It's just not about the code itself -- since the code can be copied under its FOSS license, it is a replicable (in economic terms, "non-rivalrous" and "non-excludable") resource.
+
+So, for example: how Global MegaCorp Incorporated allocates its developers' time in the project is *not* a governance issue, because the developers' time is not the project's resource to make decisions about. On the other hand, the content on the project's web site is a governable thing, because there can only be one web site (if the project forks, now there are two projects, but each still has its own web site).
+
+Similarly, the project's trademark policy is a governable thing. Of course, it might be the case that the primary corporate sponsor just owns the trademarks, but that just means the governance mechanism is very simple: that sponsor decides how to use the trademarks. And one good way for the sponsor to gain influence and standing in the project is to invite the project's members to design a trademark policy, and then commit to both adhering to it and enforcing it. (Notice this is a bridge between participation and governance!) Also, sometimes projects have project-owned money or physical resources, and these are obviously matters for governance.
+
+But the *main* governable thing most projects have is the project's overally technical/social identity itself -- its credibility, essentially. That's what I'm getting at with the examples of the web site and the trademark policy. The only thing that makes a project's releases "official" is that everyone (every user, that is) agrees that the project is the source of its releases. That social identity is a non-replicable resource -- its non-replicability is precisely why hard forks are meaningful and schismatic -- and therefore things that affect it are properly a subject of governance.
+
+Thus, while day-to-day development questions are generally just "participation" matters, once there is serious disagreement about whether (say) a given feature should go in to the project or not, the possibility opens up that it may rise to becoming a governance matter. Since dealing with governance matters is usually much more heavyweight than dealing with participation matters, experienced open source project participants will usually work pretty hard to achieve consensus on even contentious technical questions before falling back to formal governance mechanisms.
+
+Now, the formal governance mechanism might just be "the BDFL decides" or "the main corporate sponsor decides, because they said all along that this project is operating in Rocket-Ship-To-Mars archetype mode". That's fine, as long as everyone's up front about it. People can always fork, after all. But I think as projects mature, then generally tend toward more group-oriented governance mechanisms (though B2B open source is at least one exception -- you don't see multi-party democracy flourishing in Android-land, and that's okay: it's no indictment of Android, it's just how the particular copy named "Android" of that code is governed).

site/content/drafts/583.rst

+Your Next Skill: FOSS Product Management
+########################################
+:date: 2022-05-23 15:37
+:author: james
+:category: Uncategorized
+:slug: 583
+:status: draft
+
+| The classic reason to do open source is to share the load across organizations. First-class software-development is expensive. Compared to the cost of developing a software product, any one department's budget is usually relatively. This is true even in a giant, cash-rich company. Open source seems like an appealing way to shift some of those dev costs to somebody else's budget.
+| No matter which open source maturity ladder you look at, the top rung is going to involve having the skill to lead your own open source project. It is not easy to get to this level, but many orgs and companies get there. They write code, they ship it under open source license, put it on github, and they even do a reasonable job of taking PRs when they come in.
+| Most of these orgs stop climbing at that level. The maturity ladder says they are there! But they're missing the real value and they often come away from this experience vaguely dissatisfied.
+| Open source management is more complex than in-house, proprietary development. Somebody has to do the community work to get contributors into the project. Somebody also has to look at those issues and PRs, which don't come in at carefully planned times reflected in your sprints and Gannt charts. And while the software might be better, it doesn't cost less. Outside contributions aren't taking any major roadmap pieces off the internal workload. And all this doesn't add up to a bargain. The net return on time invested is often appallingly low.
+| What's often missing at this point is major partners --- orgs that show up, take a major piece of work off your plate and save you entire sprints worth of work. That's the part that most "mature" orgs fail at. They don't know how to invite those partners in, but more importantly, they also don't know how to negotiate with them and rely on them to take on major roadmap milestones.
+| There are so many reasons why orgs fail here. The biggest is that they have neglected to learn the open source approach to product management. Writing code is different from product management. Orgs have gotten good at the open source approach to writing code. Distributed development is easy-- the devs all know how to do that now.
+| Distributed product management is not the same set of skills. It requires different negotiation. It gets into stickier governance questions. It is much scarier for managers who are comfortable accepting outside development effort but feel threatened by outsourcing management functions.
+| We see this pattern a lot at OTS. Look around at your org's open source investments. Are your outside contributions producing real value? If they're not shaving sprints and milestones off your schedule, open source product management might be the next open source maturity rung you should climb.