Showing posts with label open-source. Show all posts
Showing posts with label open-source. Show all posts

Wednesday, July 08, 2026

Is second-order enshittification a thing?

The Enshittification poop emoji, created by No Ideas' Devin Washburn for the Farrar, Straus and Giroux edition of "Enshittification: Why Everything Suddenly Got Worse and What to Do About It" (Cory Doctorow, 2025).

 
Enshittifcation, as a term popularized by Cory Doctrow, has for many become a catch-all term for things generally getting worse. I've found it useful (unsurprising if you know me) to think about it in two categories.
There's the popular definition of how very large, dominant platforms change [to get worse] over time as business/organizational priorities change.

I think there's a second-order version of this that follows as a response.

I'd sum it up like this:

"If [big company] doesn't have to focus on quality, we can cut corners there too."

What happens when "everyone" takes this approach is that things get continually worse. Not all at once and not always in the immediately obvious ways. More in the million paper cuts way.

From a software perspective, it's the increasing number of small bugs that no one seems to care about fixing. This teaches people to not bother reporting them. After all, "what's the point? They're not going to fix it even if I [you] do report it."

With fewer known or reported bugs, the company thinks everything is fine, or worse still, thinks skipping on quality is an approach that works.

And a self-reinforcing cycle continues.


I prefer to think of it another way.

Software exists to help people and to make their lives "better". This could be in one or in many ways.

When people are constantly being interrupted, frustrated, and disappointed by the software they use, it's very hard to argue that it is making them better, happier, or more productive.

This is part of the reason I think that QA, customer service, and fixing bugs are among the most important things that those in software development can focus on.

With AI making copying software easier, it's focusing on how it relates to people that can be the real differentiator. 

Yes, AI may mean you can vibe code a copy of something that exists, but does it include support for all the non-obvious edge cases? Do you even know all the features that exist in what's being copied? How (and?) will you handle any bug reports?

Yes, building software can be fun for you, but high-quality software that works reliably benefits many more people and, in a small way at least, makes the world a better place.


And this can also lead to mediocrity

A small company tries to compete with a large one. They try to do everything because that's what the large company (or their software) does. They try hard, but as they're stretching themselves so thin, everything suffers. "Never mind", they say, "at least we're trying our best." But, for what? Who benefits? The company's staff exhaust themselves producing a mediocre product, and it's no better than the alternatives.
Trying to compete with a large company and basing goals on the perceived [low] standards of another company doesn't produce a great product, happy customers, or happy staff.



_This was written many months before posting--to avoid anyone thinking I'm responding to a single person, company or incident_


Wednesday, November 27, 2024

Open Source Software and "the Church of England's problem"

No, this isn't a religious post.


I was listening to an interview regarding marketing challenges for big brands trying to reinvent themselves. The context was large, older brands that people don't want to go away but whose products they aren't going to buy (any more).

A comparison was made with the Church of England. (It was a very English discussion.) The speakers  said:

  • They wanted it to keep existing.
  • They weren't going to go.
  • And, they certainly weren't going to pay for it.


I immediately saw a comparison with Open Source Software:

  • People want it to exist (and be maintained/updated)
  • (Most) people are unlikely to participate. (Beyond using it.)
  • And, they certainly weren't going to pay for it.


The challenges facing the CofE and OSS have similarities, but I think the solutions each will seek are very different.

That's all, except to say that the impact on anything is highly likely to be the same when people want something but aren't willing to pay or participate.

Thursday, October 10, 2024

Developers like us pledge to support open-source

I was recently previously contributing to a project when something broke on the CI builds due to an issue with how a referenced library was misconfigured.

I didn't realize the library was being used. It was configured in a way that meant it didn't show up inside Visual Studio when working with the solution.

I also knew this library had a special (moral) license. This "required" those using it to support the project financially, but the business wasn't.

I wasn't using the functionality of the library, but when I discovered this, I did two things:

1. I made a personal financial contribution to the project.

2. I highlighted this to the business and indicated that they should be financially supporting the project if they wished to keep using the library. (The person who originally added the library pleaded ignorance--"But, it's open source, so we don't need to pay.")


People like us (developers like us):

  • Support the people writing open-source software. Financially if possible (and requested).
  • Respect the spirit of open-source licenses. Not just the minimum, enforceable legal requirements.


This incident raises other, bigger questions, but I'll discuss them at another time—maybe.


However, I mention this because I recently heard about the Open Source Pledge. An initiative to help encourage companies to "Do the right thing, support Open Source".

No, it's not going to solve the problem of funding and support for open source maintainers, but it will help.

Sunday, December 10, 2023

"Why an MVP shouldn't use their extensions to hijack a developers GeneralOutputPane in Visual Studio to solicit sponsorship and to use it as their own personal advertising space via a class called SponsorRequestHelper.cs."

And the answer is...because entire teams will no longer use the extensions. Because its not cute, it's distracting. Because it's not witty, it's inappropriate. And because I don't believe that blackmailing developers with removal of the nag once they sponsor you is very becoming of an MVP. While I was looking forward to using some of your extensions after a MAUI webinar I attended the other day, sadly, our team will not be using any of your extensions. And hijacking these special method handling attributes is irresponsible, because Im pretty sure Microsoft wont agree that your desire for sponsorship is in any way SPECIAL or more important than the runtime in which you are hijacking.

Monday, January 30, 2023

Did you know that GitHub sponsors can be Private?

When you sponsor someone via GitHub Sponsors, there's an option to make your sponsorship public (so everyone can see it) or private (so only you and the sponsor know about it.)

Partial screenshot of the sponsorship form. Title: Who can see your sponsorhsip? Option 1: Everyone - Others can see that you sponsor mrlacey. Option 2: Private - only mrlacey will be able to see that you are a sponsor

Why might you want to keep your sponsorship private?

Well, you may have many reasons. 

If I had to speculate, one reason I've assumed is that you don't want other people asking you to sponsor them too, or questioning why you are sponsoring a person.

I've had a few well-known people (in the Microsoft/.NET world) sponsor me. This was very surprising and flattering, but I can easily see other people online reacting to this knowledge negatively or demanding that they sponsor them too.

All I can do is thank these secret benefactors.

Whatever your reason, I (or anyone else you chose to sponsor) will always be grateful for your sponsorship.


If you do sponsor me, you will get:

  • My gratitude.
  • The knowledge that you're helping me create tools to help more developers do more. (like this.)
  • Details of how to remove the prompt to become a sponsor that's shown by some of my extensions.
  • Early access to my writings and some tools via a private GitHub repo. (recurring sponsors only--for now, based on how the GitHub sponsors infrastructure makes this possible.)
  • If not a "private" sponsorship, I display your avatar in some of my tools. As below. (Position and duration of inclusion depend upon sponsorship amount and if one-off or recurring.)

partial screenshot of the MAUI App Accelerator windows showing images of all public sponsor avatars


Any amount, one-off or recurring, for as long as you wish. Your sponsorship will be appreciated. :)


And a big thank you once again to all who have, are, or will sponsor my activities.


Tuesday, December 14, 2021

Forking Windows Template Studio

Windows Template Studio is a Visual Studio extension that helps developers scaffold Windows applications. 
I have a long, complicated relationship with the project and have been involved since its inception.

In June, Microsoft stopped funding the internal team who were working on it. I was told there were plans to continue the project with support from the community, but this didn't happen, and my emails have gone unanswered since then. 😢

Sadly, due to the way the project is set up and configured and because of the permissions I have, it's impossible to do anything significant within the existing repo.

So I'm taking it upon myself to do something separately.

Announcing Template Studio for UWP. (preview for VS2022 available now!)

The wizard for 'Template Studio for UWP'
Yes, it looks very similar to the Windows Template Studio wizard.

I'm starting by taking the UWP (and then WPF) capabilities of WinTS and breaking them into separate extensions that work with Visual Studio 2022.

WinUI(3) support will hopefully follow. As will support for creating apps that don't only run on Windows.

There's lots of detail I'll spare you from, but the bits most likely to be of interest are:

- My goal is to help developers now. (When Microsoft has left them in a state of uncertainty.)
- I'm updating the dependencies in the generated apps and will add other improvements and new functionality.
- I want to reduce the dependencies on developers installing the extension(s). You shouldn't need the capability to build any/every type of Windows app just to use the extension.
- I'm starting by focusing on the parts of WinTS that are less likely to be supported by Microsoft (UWP & WPF) if they do resume development (& support) of WinTS.
I'm open to contributing to the WinTS project again, but I'm not just sitting around while I wait.
- I'm doing this in a way that gives me the best opportunity to do other things with the code in the future. (Look at me being all mysterious. 😉)
- I'm taking the opportunity to make some much-needed (in my opinion) updates to the project and its internal dependencies. 
- It's not open source (yet), but I'm not ruling it out for the future. (I have many reasons that I'll save for another day/time/place.)


It's in preview now & I'd love feedback.

The "Template Studio for UWP" entry in the "Create a new project" wizard



Sunday, March 07, 2021

Open-source is like politics - show up to make a difference

Open source is like politics.
But, probably not in the way you're thinking. Not politics in a negative sense as if it's all about power, domination, and control.

hand putting voting slip in box
Photo by Element5 Digital on Unsplash

I think open source is like politics in that many people think about it in the same way as they do the politics of local government.

What do these refer to?

  • Generally, people think it's a good idea.
  • Typically, people take what they can from it and don't give back beyond what's required/forced.
  • People think about getting involved a lot more than they do.
  • Lots of people have [strong] opinions but don't act on them.
  • A few people contribute a lot (of time and effort).
  • People who contribute are rarely rewarded or compensated well.
  • When a person is directly affected, they may show up wanting action on the issue that affects them. But, their desire to look at (or consider) anything else is small, and their enthusiasm is short-lived.

Were those comments about local government or open-source software?

I hope you can see they apply to both.


I think the similarity also extends to how to make a difference in each.

Who are the people who make a difference in local politics?

They're the people who turn up. Repeatedly, regularly, and when it's not always in their immediate interest. They do things to help the community.

Four things to do:

  1. Show commitment. Turn up regularly. (Not just to be seen but also because it's often the only way of knowing what's going on.)
  2. Work for everyone's benefit. Do things that help others, not just you.
  3. Share your knowledge. Not to show off but to help others.
  4. Think long term. Not only immediate benefits.

Doing the above will build trust and a reputation that will support your big ideas down the line.

Yes, large organizations and people with a lot of money, influence, or celebrity can come in and make a big difference in a short amount of time. I'm assuming you're not one of them (I'm not either), and so you have to do what you can with what you've got.


Does this really work?

There are some examples from WinUI where community members (people) have suggested new controls and an alternate syntax that were then implemented by the team.

But what about something bigger?

The most prominent example I have of influencing a Windows-related open-source project is adding support for Visual Basic(!) in Windows Template Studio. This was a big deal as it was a significant change and would be something with long-term consequences.

This is something that I (as a non-Microsoft employee) persuaded Microsoft to add.

  • I did this for a project in which I had built a reputation for regularly participating.
  • I'd previously displayed knowledge so that the project leads valued my opinion.
  • I backed up my suggestion with data. (Not data I had but data I knew they could get access to and assumed would support my proposal.)
  • I suggested something that aligned with the larger goals of the project and organization.
  • I suggested something that wasn't in my immediate interests but would help underserved members of the community.
  • I showed how I could help make the change easy by volunteering to help with the work.


Only big changes?


Let me be clear, contributing to open-source isn't only about big changes!

Every little helps! It's not just true of supermarkets. All the small things we do add up. 

One of the great benefits and advantages of open-source software is that it can be built on many people's wisdom, knowledge, skills, and contributions. Not everyone can make large contributions (in size or number) to every project. But, all contributions help, regardless of size, when they work to build better software for everyone.

Improving documentation, giving feedback on a spec or proposed feature, adding a real-world example, and sharing details of a project. These can all be just as valuable as writing code.  

There are projects where I've only ever made small changes. Yes, even only fixing typos. I know these don't make a massive difference but they do help those who come after me and they do make a difference.

Start small and then work up. Or don't. Staying small is good too.




I drafted the first version of this post in early February.

As part of the WinUI Community Call on 17th February  2021, they included a section on "Maximizing Your Influence on WinUI." (Watch that section on YouTube)

There was lots of good advice in that call/video, and I think it complements what I've said above.

If you don't want to watch a 15-minute video, here are some screen grabs of the slides shown, or check out this document where they summarize the key points.

Phrasing Postively:- Emphasise- Constructive action (what is "won" by doing this?); Clear & detailed "why" - assume an explanation is needed.-Main benefit? -Current alternative? -comparisons can help, but shouldn't replace detail; Mutual empathy

Phrasing Positively | Before: The state of platform is disappointing. I am not going to consider WinUI until my trust has been earned.  After: Deprecation of past frameworks has left me burned. The following would go a long way in earning my trust because my company is trying to launch an app next year and will need it supported for at least 5 more: - OSS, - High confidence 5-year roadmap, - Guaranteed support timeline

Phrasing Positively | Real impact: Team's spec writing process - a story about customer feedback

Feedback shapes the product | Example areas: - Features you care about for your own real apps & projects - Ways you'd like to see the team improve community engagement & interaction - Stories of how our roadmap plans do (or don't) enable your apps - Ways we can improve the developer experience (tooling, docs, blogs, etc.) - Bugs & issues in WinUI!

Feedback that shapes the product | Less likely to shape the product: - Feedback on products beyond WinUI (e.g. Start Menu) - "Stop doing X, start doing Y" - Reaching beyond Windows | Guidance coming soon!


WinUI isn't a project where you can easily come in and make big changes, or expect dramatic changes in direction. But you can help make a difference, not only to the project but also to the lives of the developers and the people who use the software they create.

My impact on the spec process is the most significant change I've made there, but I'm not disheartened. I know I've made a difference that helps others and I hope that my contributions, suggestions, feedback, and support will continue to have a broader impact in the future.


Keep showing up.

Let's make a difference together.



Saturday, October 24, 2020

Rethinking open-source priorities - what is my time worth to me?

One day into trying to fix an issue I wondered if I was using my time wisely. Two days after that, and when I'd finally found the solution, I'm certain I hadn't been using my time wisely.

⏰⏲⏱

Cliche
Photo by CharClarPhoto - https://www.flickr.com/photos/charclarphoto/42437342612/

One of the things I like about contributing to open-source projects is that I can choose my priorities.

My thinking goes or rather went, that if I'm giving my time for "free" I should get to choose what I work on. I'm starting to think this isn't the best for me, or the projects I'm contributing to.

Back to the scenario, I started with.

One day into debugging the issue (an automated UI test that would fail periodically for no obvious reason) and I considered giving up. There were two things that kept me going:

  • I was really keen to understand the underlying issue.
  • I'd committed to fixing the bug. 
The bug was reported by a member of the project's core team and I'd created the test originally. I felt a personal responsibility to get it working. The bug was also something I (originally) thought I could fix quickly. Having the core team (who are paid to work on the project) spend their time on this didn't feel like a good use of their time.

Reflecting back on this, I was making a few (common?) false assumptions:
  • My time was worth less than those people paid to work on the project.
  • My time doesn't matter as it's just an open-source contribution. (I'm not being forced to do this.)
  • Because I'd started it I need to finish it.
  • Any external contribution to an open-source project is valid.
If this had been paid work, I would have stopped before the end of the first day working on this and said it wasn't worth the effort. If this had been my own open-source project I would probably have stopped then too. It wasn't worth the effort to spend more time trying to fix the issue. Having to occasionally rerun a test because of a false negative wasn't worth spending multiple days of effort. That time could have been used on something much more productive.
I would have been appalled to hear of someone being paid to work on the problem keep going for so long. So, why did I think it was ok for me to keep spending my unpaid time on it?

If you've read this far and think I was foolish and should have known better and stopped sooner. I agree.
Clearly, I need to reflect on this and better prioritize what I work on.

However, I think this highlights some important questions for people who maintain, lead, manage. or otherwise, influence people who contribute to projects. I'm thinking particularly of open-source projects but I suspect the same applies to closed projects within an organization too.
  • How do you ensure that all contributors are making the best use of their time?
  • How do you ensure an external contributor is doing something that is a good use of their time?
  • How do you prevent external contributors from becoming demoralized when stuck on tricky problems?
  • If you want external contributors, what are you doing to attract and keep them?

I think these questions matter because:
  • For paid workers, you want to ensure that the money spent on their time is being used effectively and efficiently.
  • For volunteers, you want to value and respect the gift of their time and ensure it is being used wisely.
  • For everyone, you want to make sure that no-one is stuck on something they should re-evaluate, abandon, or ask for help with.
    Previously I would have relied on people to speak up when they're stuck but this experience demonstrates that I don't always do this. So I shouldn't expect this from others.
  • For everyone involved, you want them to feel valued, appreciated, and that they're making valuable useful contributions.
    Some paid contributors will be happy to turn up, do something, and get paid without thinking about what they're doing and the wider consequences. But I expect having such people on a project that seeks open-source contributions can be a turn-off for would-be volunteer contributors.

Managing projects with both paid and volunteer contributors can be very tricky. I wonder if there are lessons from charities or other organizations that have both paid staff and volunteers which would be useful for those creating software this way?

If you have any thoughts on this, I'd love to hear them.
They could be on how you prioritize and know when to stop, re-evaluate, and when to keep going. Or maybe you have some thoughts about how project leaders/maintainers/managers can ensure that all contributors (paid or not) are making the best use of their time. Both personally and with regards to contributing to a project.

For me, the lesson I'm going to try and take forward is to think about giving my time to an open-source project and then focusing on what the best thing is I can do with that time. I'm going to try and put that time decision before I commit to fixing a bug or adding a feature.

post-script.
Yes, I did finally solve the issue. It was a timing issue (as they often are) relating to a light-dismiss dialog not always being closed. It's interesting, to me, to know this but was it worth two days of my time to find this out? Probably not. Would I have felt bad charging for my time to fix this if I was being paid? Yes.

Friday, October 09, 2020

6 tips for contributing to Open Source

 The following is based on a presentation I gave on the September 2020 WinUI community call.


Here are my tips

  1. Don't start with a Pull Request
  2. Follow the project's conventions
  3. Assume positive intentions
  4. Explain why. Don't say "should"!
  5. Focus
  6. Everything helps


Don't start with a Pull Request

If you're doing anything more complicated than fixing a typo or small spelling mistake, don't start with a pull request.
Engage with the project maintainers before you start doing any work.

You don't want to spend time on something that isn't wanted or that someone else is already working on. Nor do you want to build a solution that doesn't fit with what else is going on with the project.
It may also be beneficial to discuss possible ways to make the change, fix the bug, or add the proposed feature. You'll want to make the best use of your time, and maintainers or other people working on a project may have ideas and suggestions to help you.

You can "engage" with the appropriate people by creating an issue (if it's something new), commenting on an issue (if there is already on related to the work you want to do), commenting on a discussion, message board, email list, chatroom, or wherever else is appropriate for that project.
Aim to try and work the same way as others on that project already do.

Follow the project's conventions

Most projects include a document on how to contribute. Most of them include a note about not starting with a pull request. But there's more in there too. If a project has one, be sure to read the contributing.md document and follow what's written there.
If a project doesn't have a guide to contributing, ask how to get involved. And, maybe suggest a guide to contributing too.

As a general rule, code is easier to understand (and therefore review and maintain) if consistent in style, structure, and conventions. Anything you contribute should look like it belongs with the rest of the codebase.
Consistency applies to documentation too. It can be distracting for the reader when documentation uses differing tenses, styles, terminology, etc.

Many projects also use templates and checklists when creating issues and submitting pull requests. Always strive to provide the information and complete the desired tasks.

This isn't being done to be difficult.

Assume positive intentions

Projects ask for information because it helps. They're not asking for it to be difficult.
 
Project maintainers don't want you to waste your time. Also, they want to make the best use of their time. They ask for specific information to evaluate and accept a change or understand an issue. They don't do it to waste your time.

This point goes both ways.
Project maintainers need to remember that when an issue is raised with minimal details, it's not because someone is being difficult or lazy. They may not have been able to provide more information. They may not even speak the same language. 
Be kind.

Explain why. Don't say "should"!

If raising an issue, explain why you want a change, or how a new feature will help you. This helps others understand and allows appropriate prioritization.

Never say, "you should make it do X" without explaining why. 
I'm sure your opinions and ideas are great, but you need to do more than state them.
Is this currently causing you a problem? Or is it just something you think would be a "nice to have"? Why you're asking for or suggesting something can be essential to know.

Focus

And if you're raising issues about problems or suggesting new features, create separate issues for each problem or idea.

Breaking work down into discrete areas can help with understanding, prioritization, and associating changes.

It's much easier to triage and manage work when an issue only lists one problem.
It's easier to review a change that fixes one bug or adds one feature.

It's also useful when discussions remain focused.
Depending on the project, it may or may not be appropriate to have side discussions in issues or comments. I want to be more involved with several open-source projects, but I can't filter out all the seemingly unrelated discussions and so am unable to follow all the relevant discussions that occur.
Follow the conventions of the project regarding side discussions. 

Everything helps

The success of very few projects is predominantly decided by the code. Many other factors play their part, and you can contribute to these too.


This includes writing, expanding, or translating documentation. - There are projects I contribute to where they don't need other people writing code, but I can make a valuable contribution by writing docs.

The same goes for testing. - There are projects where others are paid to write code, but I can come in as an external contributor and make significant, valuable contributions by creating tests.


Again, there are projects where I add value by asking questions.

  • What about people who are using this for the first time?
  • Did you consider X?
  • Why did you do it that way?

This can be informal or as part of a code review.


Bringing different perspectives and experiences helps create something useful to more people and a wider variety of people.


Everything helps.


You can also support projects in other ways. For examples, see https://rapidxaml.dev/support


Financial support can be great if you can provide it, but not every project needs it.

Even if you can't provide a financial contribution, there are ways to support projects you use and value.

  • Leave a star on GitHub.
  • Leave a review or a star rating.
  • Spread the word through a tweet, blog post, stream, video, or whatever you use.


Feedback can be really encouraging for people investing in the creation of open-source projects and is a reminder that their effort is valued and appreciated.


Show you care. Show your support.




Monday, September 28, 2020

Living the open-source Utopian dream

With everything going on in the world, I thought it would be worth sharing a positive story about working on open-source projects and a Utopia where everyone works together to make software that benefits the people who use it.

This story relates to the Rapid XAML Toolkit. If you're not familiar with the project, it's is a collection of tools to help developers building apps with XAML inside Visual Studio.

Recently (a Friday), I discovered that the functionality that works with files being dragged from Solution Explorer and dropped in the editor had stopped working in the latest versions of Visual Studio.

I raised an appropriate bug report and posted a few messages to people who may be able to help and/or who use the same functionality too.

By Wednesday morning my time (noting that Monday was a public holiday in the USA) a member of the Visual Studio team had explained that what I was seeing was a deliberate change in behavior. They added public documentation justifying the change and why it had been made. They also gave details of an alternative approach to get the same underlying behavior. Best of all, they raised a PR against my repository, which included the change in approach to get the same result.


Separately, I have a GitHub action that checks all the URIs in documentation (and elsewhere) are correct and are not "dead links". Over the same weekend, this started failing in an inconsistent way that I could not explain.

I then raised an issue on the repository of the action but wasn't overly confident about anything happening.

My Wednesday evening the author of the action had fixed the problem, released a new version, and created a PR for my repository to switch to the new version.



These two instances demonstrate and reinforce my idea of open source being about "everyone working together, so the world gets better software."  The other two people didn't have to make changes and create Pull Requests, but by doing so they've helped me and the people who use the toolkit.


Monday, June 08, 2020

The idea that making code open-source won't cost a company anything

It’s been a while since I’ve heard the idea that “making {some software} open source won’t cost {company} anything,” but I did today.

Not being able to find an existing list of reasons why this isn’t the case, here are a few quick thoughts:

  • Any change in ownership requires people to make decisions and take action. Doing so requires more time than it takes to open a repository, copy some files, and push the commit. Time takes money, and so has a cost to the company.
  • The code must first be checked for the risk of revealing any potential security holes. Detailed code reviews take time from experts, and so aren’t free.If the released code risked showing a potential vulnerability to existing users of the software, that’s something the company will need to address. It might be easier/cheaper not to release the code.
  • The code must first be reviewed for IP and licensing issues. Does the company want all the code released under an open-source license? If not all of the source code (and assets) can/should be released, what should they do about the parts that can’t?Or what if the code depends on libraries or other licensed resources from elsewhere?
  • The ongoing management of an open-source project takes time (and therefore money.) If the intention is to create an ongoing, community-driven project, it will need (at least initially) some leadership and guidance. Releasing the code under an opensource license and then leaving it for anyone to do with it as they wish, is less likely to lead to a single release that continues the legacy of the original.
  • If releasing the code for use as anyone wishes, then pre-existing branding, trademarks, names, etc. must be removed or changed. If not performing such modifications before the code is released, it may be necessary to verify that anything released based on the original source has such identifying elements removed. 




“Cost nothing” is not the same as “won’t cost much.” If you’re trying to persuade someone to do something, being specific, and understanding what matters to them and how they make decisions can help build a persuasive argument.



An additional nod to Sébastien for pointing me to this explanation of turning Windows Live Writer into Open Live Writer as an example of the steps/processes involved that must have cost effort/time/money.

Thursday, April 09, 2020

Navigate between files of different languages in Visual Studio

Visual Studio has great tooling for navigating within code when it is in the same (programming) language.
However, if your solution contains code in more than one language and you want a quick way to navigate between files you're out of luck. Until now!

Presenting: Comment Links
Yes, it's (another) new Visual Studio 2019 extension. This one lets you put links between files anywhere in your code. In theory, this could be anywhere in your code, but in comments makes the most sense. Just include the text `link:` (case-insensitive) followed by the file name.


A green button with an arrow on it will, when clicked, open the named file.

You can also have the file open on a specific line by including the line number after `#L` at the end of the file name.

// link:mapManager.js#L25

 Or you can jump to the first occurrence of a specific piece of text

// link:mapManager.js:UpdateLocalData

For compatibility with text fragment anchors you can also use `#:~:text=` after the file name to specify the text.

// link:mapManager.js#:~:text=UpdateLocalData


Version 1.0 is in preview and available from the Visual Studio Marketplace now.
Please give it a try and tell me what you think or suggest new features on GitHub.


This project was the result of a comment from one of my GitHub sponsors. If you join them I'm likely to take any suggestions you make more seriously. ;)

Tuesday, December 03, 2019

Rapid XAML in the future

This
Rapid-XAML-Toolkit forked from the Microsoft organization
Before
has become this
Rapid-XAML-Toolkit repo now in my org
After

Yes, ownership of the repository has transferred to me.

Background

A little under two years ago, I was thinking about how more can be done to help developers building software. I was contributing to Windows Template Studio, which is a great way to get started in creating an app but wondered what could be done after that. I saw that there was a big gap in the tooling for developers working with XAML, and I had several ideas about ways this could be improved.

Skip forward a couple of months, and I had a proof of concept that I showed to some people in Redmond.
I received a positive response.
They asked what I wanted to do with it, and the conclusion we came to was to make it an "official" Microsoft open source project. And so, open-sourcing processes were followed (Yes, Microsoft has such things), a repository was created, and I began working away in my "free" time.

Fast forward to earlier this year.

I reached the point where it became realistic, practical, and necessary to start getting the functionality out to people who could use it.
In a case of bad timing, the primary advocate for the project within Microsoft left for another job.
The person who took over responsibility for the project within Microsoft then faced several months of me asking them questions. Questions like:

  • When can we get this in the marketplace?
  • What do you need from me to help this progress?
  • What progress is happening?
  • What can I do to help this progress?
  • Etc...

To try and encourage things along and provide a way for people to see what I'd been working on, I released a preview via my own publishing account.
I did a small amount of extra work in response to feedback from the preview, but the uncertainty of the project meant progress on the project slowed.

Eventually, I got an answer. This wasn't going to be something Microsoft would publish.

Not totally dejected (or surprised--given how long things had taken), I asked about my continuing the project away from Microsoft. Primarily, this meant transferring the ownership of the repository to me. As there were only minor contributions from other people and I had no plans on changing the licensing, this was agreed to, in principle, subject to approval from legal.

Cue several months of me repeatedly asking, first, "Have you asked legal yet?" and then "Have you heard from legal? Can you follow up with them?"

Until.

Yesterday I received an email that the legal department had no objections and so I made the transfer.


I've definitely learned a lot from this process.


What's next?


  • Time for me to get to work.
    While work had stalled concerning development, I've been keeping track of more and more ideas for what could be done to help developers and features to be added to the product. More details to follow...

  • Get a "proper" version released.
    I'm also going to revisit how it's packaged, so developers need only install the bits they want.

  • It will remain free and open source! An original goal was to gain experience in managing such a project, and that's still possible. While the direct Microsoft association would undoubtedly have helped, I still believe this can be a valuable tool for developers working with XAML. While Microsft continues to focus their effort on improving tooling within the visual designer, that leaves a lot of opportunities to offer tools to help within the editor.
    And, free because of not being a name that can sell the tool, I'd instead gain experience and knowledge from having a lot of people use it rather than make a small amount of money from a few users. Having spent the last 7-8 years doing work under NDA, it's getting harder to find work without any portfolio. Hopefully, this will start to show what I'm technically capable of and my knowledge of what developers want and need. This may aid in securing future consulting/contract work. I'm also hopeful the lessons and experience here may allow me to create other, paid, tools in the future.
    In a moment of what's hopefully excellent timing, I've also been approved for the GitHub sponsors program, so you can financially support this project too.

  • A new website - probably.

  • Merch/SWAG - eventually?

exciting times!




Thursday, November 21, 2019

Make the repository public - no-one cares about your code

Just make the repository public (assuming it contains no Publicly Identifiable Information or embedded secrets.)
If it does, you should remove them anyway.

The 'make repository public' setting in GitHub

There are common fears about making code public.

  • What if someone takes it and makes something with it that they start selling or otherwise competing with my project?
  • What if someone laughs at it?
  • What if someone copies something?


So what? No-one is paying attention to what you put on-line. (If they were I doubt you'd have nothing better to do than read my blog.)

  • Use an appropriate license to address possible competition concerns.
  • Ignore the haters.
  • Assume that something will be copied.


I've heard it said many times (sorry, I can't attribute the original source) that "any code on the internet will eventually end up in production."

And if it does, that's ok. I don't feel responsible for someone else's codebase if they copy something I wrote (possibly many years) previously and use it differently without understanding the nuances and possible consequences.

Searching GitHub is now my default for working out how to use an undocumented API.

By searching for uses of the method/class/whatever, I can see how/if someone else has made it work. Not in a contrived example. But, in a real (hopefully) production code-base. If they hadn't made their code public I would have been stuck. I see making as much code as possible public as a way of paying it forward to other developers.

Seeing that an API has been used successfully by someone else (and how) is incredibly valuable and has helped unblock me from many coding challenges in the last year.
If I can make my code public and potentially help others in the future, then I'm all for it. I'm sure that the only reason someone else will look at my code is if they find it as the result of a search.



While I was sitting on the draft version of this post, I received this message.
"You can't just create a blank repo and leave me hanging!"
"Oh, no!" I thought. "This contradicts what I wrote in that (this) blog post."
I'm not sure it does, though.
This was a question about a name. The name of a repository.
(I find creating empty repositories for possible future projects cheaper than buying a domain and never doing anything with it.)

The name of the repository sparked interest, and they wanted to know more of what I intended for something with that name. (Hopefully, this suggests it's a good name.)

However, with more than 100 public repositories in my GitHub account, I can't recall ever having a random email asking about any of the code they contain.

I think my point still stands.